For API teams who want plain-text request checks they can read, review and run again.
Your setup
- A REST API on staging, with a bearer token for a test user.
- A GitHub repo for the checks, or no repo at all.
- You want fixed checks for key endpoints, run after each deploy.
Say this to Certyn
Write Hurl checks for our orders API on staging: create, read, list, and a 404 for an unknown id. Put them in acme/api under api-checks/ and run them after each deploy.
What Certyn does
-
For an API-only service, sets the project type to
api(you approve). The environment's URL is the API base URL. -
Opens the sign-in form for the token, saved as
API_TOKEN. If needed, a form forGH_TOKEN(Contents and Pull requests read/write on that repo). -
Reads the OpenAPI spec if there is one (
api.spec.get), and writes one.hurlfile per flow:GET {{baseUrl}}/orders/999999 Authorization: Bearer {{token}} HTTP 404 -
Runs them on its Machine, where Hurl is installed. The secret goes in from the shell, never in the file:
hurl --test --variable baseUrl=$TARGET_BASE_URL \ --variable token=$API_TOKEN api-checks/*.hurl -
Fixes a check that is wrong. A real API bug stays failing and becomes an issue.
-
Opens a PR with the files on a
certyn/branch. -
Creates an agent process with the same command as its goal, and a trigger after each deploy (you approve).
What you get
- Hurl files your team owns and can also run in its own CI.
- After each deploy: a run report, and one issue per real API bug with the request and response. Secrets show as
[REDACTED].
Limits
- Certyn has no Hurl suite. Without a repo, Certyn saves each flow as a test case with a
hurlblock, and a suite by tag runs them. In a test case, only{{baseUrl}}is filled for you; a block that needs a token must run in the shell as above. - One
api.hurl.runcall stops after 300 seconds. Long suites run in the shell (30 minutes per command). - The API must be reachable from the Machine. For a private API, use a self-hosted runner.