Assert on status codes, response time, keywords, and JSON values, so a broken endpoint is caught before it reaches the customers who depend on it.
GET https://api.genius.ly/v1/orders→ 200 OK · 3,840 msassert response < 800 ms ✗ (3,840 ms)assert json body.status == "ok" ✓verifying · re-checking before alerting…second check agrees · incident opened
What it checks
Any HTTP method against any endpoint. Assert the status code, set a response-time threshold, and require a keyword or a JSON value in the body.
What failure looks like
An endpoint that returns 200 with an empty body. A payment API that slows from 180 ms to 4 seconds. A deploy that quietly renamed a field.
What Fajita does
Every assertion failure is treated like downtime: verified first, then routed to your team with the failing check and the response that broke it.
Why it matters
Your API is the product your integrations buy. The customers it fails do not file tickets. They leave.
In practice
Fair questions
Yes. Add request headers, including authorization tokens. Credentials are encrypted at rest and never shown back in full.
Tokens are stored encrypted and used only to make the checks you configured. Use a scoped, read-only credential where your API supports one.
Yes. Response-time thresholds, keyword assertions, and JSON value assertions all count as pass or fail conditions.
Related