SendrixAPI
Keys

Reference

Versioning

What we may change under a running integration, and what we will not. Written down because an API you cannot rely on is not worth building against.

The version is in the path

Every endpoint lives under /v1. There is no version header to set and no default that shifts beneath you. Every response also carries Sendrix-Version: 1, so you can assert on it if you want to.

What can change within v1

Only additions. Specifically, we may:

  • Add new endpoints.
  • Add new optional fields to a request.
  • Add new fields to a response.
  • Add new values to a documented enum, such as a message status or an error code.
  • Reword any error message, or any prose.

What will not change

  • No field is removed from a response.
  • No field is renamed.
  • No field quietly changes meaning or type.
  • No error code is removed or repurposed.
  • No endpoint disappears.

The one exception

Requests reject unknown fields rather than ignoring them. That is a deliberate asymmetry: being strict about what we accept and generous about what you must accept is what makes a misspelled variable a 400 instead of a message with an empty slot in it. Since we only ever add optional request fields, this can never break existing code.

When something must break

It becomes /v2. When that happens:

  • /v1 keeps working for at least twelve months.
  • Every /v1 response carries Deprecation and Sunset headers for that whole period, so your monitoring can see it coming without anybody reading an email.
  • We write down what changed and what to do about it, before the clock starts.
http
Deprecation: true
Sunset: Sat, 29 Aug 2026 00:00:00 GMT
Link: <https://sendrix.in/integrate>; rel="deprecation"

Nothing is deprecated today

/v1 is current and carries no sunset date. If you are reading this and your responses have no Deprecation header, there is nothing to do.

Meta's own changes

Some things are not ours to hold still. Meta owns the vocabulary for template categories, quality ratings and the error codes on a failed send, and adds to all three. We pass those through unchanged rather than mapping them to a list of our own that would be permanently out of date.

That is the practical reason for the “treat unknown values as something else” rule above: the field is stable, the vocabulary is not. See Errorsfor which codes are ours and which are Meta’s.