QuantaAPIA mock endpoint answers with whatever your response template renders. The status code is the part you can rely on; the body shape is entirely up to you.
Mock endpoint errors
| STATUS | CODE | DESCRIPTION |
|---|---|---|
| 400 | VALIDATION_ERROR | A declared header or body field is missing or out of range. Details are in X-Validation-Errors. |
| 403 | FORBIDDEN | The x-collection-api-key header is missing or does not belong to any collection. |
| 404 | NOT_FOUND | No endpoint matches the path and method. |
| 429 | TOO_MANY_REQUEST | Simulated. Only appears if this entry is in the pool and the roll triggers. |
| 500 | INTERNAL_SERVICE_ERROR | Unexpected server failure, or a simulated pool entry. |
| 502 | BAD_GATEWAY | Simulated pool entry. |
| 504 | GATEWAY_TIMEOUT | Simulated pool entry. |
Simulated statuses are configurableThe 429, 502, 504 entries are defaults. You can replace them with any status between 200 and 599, so the table above reflects a fresh endpoint, not a hard rule.
The response body on 400 and simulated failures is your stored template rendered with {{message}}, {{status_code}}, and {{success}}. Do not rely on a fixed error JSON shape unless your template defines one.
Handling failures in clients
- Treat 400 as a contract problem in your own request, not as a transient failure.
- Treat 403 and 404 as configuration problems: check the key, path, and method.
- Retry only on 429 and 5xx, and use exponential backoff.
- Do not assume 200 always means success. Error simulation is designed to make status checks mandatory.