For teams with a Postman collection who want it run against staging and want real API bugs tracked as issues.
Your setup
- A Postman collection (and Postman environment) exported as JSON in a repo.
- A staging API on the internet.
- An API key or test account for staging.
- You want failures that are real API bugs filed, not every red assertion.
Say this to Certyn
Run our Postman collection (postman/api.json in acme/api) with Newman against staging, and file the real API bugs.
What Certyn does
-
Opens a form for
GH_TOKEN(Contents: Read on that repo). -
Opens a form for the staging credentials: the sign-in form, or an
env_varform for one key, for exampleSTAGING_API_KEY. Secrets never go in the chat. -
On a Machine (Node is there), runs Newman with the staging URL and the saved secrets passed as Postman variables:
npx newman run postman/api.json -e postman/staging.json \ --env-var baseUrl=$TARGET_BASE_URL --env-var apiKey=$STAGING_API_KEY \ --reporters cli,junit -
Runs one folder first (
--folder), then the whole collection as a run. -
Reads each failed assertion and decides: an API bug, an out-of-date assertion in the collection, or a setup problem such as a wrong token.
What you get
- A run report with failures grouped by cause.
- One issue per real API bug, with the failing requests as evidence. A known bug is not filed twice, and it is retested after a fix.
- If you ask: the same goal as an agent process, every night or after each deploy.
Limits
- A collection that lives only in Postman's cloud: export it to your repo first.
- Keep secrets out of the exported Postman environment. Save them as Certyn variables, and restart the Machine after you save a new one.
- Collections that create or delete data: run them on staging. On production, Certyn asks before it changes real data.
- Newman checks only the requests in your collection. For endpoints it does not cover, an
apirun tests your API from its OpenAPI spec URL.