Errors

How error responses are shaped across services

Every service in this reference returns errors in the same shape:

{
"code": "FILTER_NOT_SUPPORTED",
"message": "createdAfter is not supported until Teflon adds date-range filtering.",
"details": "optional additional context"
}
FieldRequiredDescription
codeyesA stable, machine-readable error code
messageyesA human-readable explanation
detailsnoExtra context, when available

Rejected-but-documented parameters

A few operations document filters or fields that the contract accepts but the backing service currently rejects with a 400 — these are called out explicitly in the operation’s own description (search for “Phase 2” or “backlog”). They’re kept in the contract so integrations written against them today don’t need a breaking change once the backing service catches up; until then, expect a 400 with a code that names the specific rejection.