OpenAPI specification
Fetch the machine-readable OpenAPI document for v3 here:
https://docs.sent.dm/api/openapi/v3No API key needed. Use it to generate a client, validate a wrapper you maintain, or diff the API surface between releases.
The document is generated from the deployed API rather than maintained by hand, so it describes the surface that's live. Every page in this reference section is rendered from the same document.
Pin a revision
The document carries no version number of its own. info.version is the string v3 and doesn't increment, so use the SHA-256 digest of the body to identify a revision.
Every response carries it two ways:
| Header | Value |
|---|---|
ETag | The digest, quoted |
x-sent-spec-sha256 | The digest, bare |
Record the digest alongside your generated client:
curl -sS https://docs.sent.dm/api/openapi/v3 -o openapi.json
shasum -a 256 openapi.jsonTo check for a change without downloading the document again, send the digest back:
curl -sS -o /dev/null -w '%{http_code}\n' \
-H 'If-None-Match: "<digest>"' \
https://docs.sent.dm/api/openapi/v3304 means the surface hasn't changed. 200 means it has, and the body is the new document.
HEAD works the same way and returns the digest without a body, so use it when you only want to know whether to re-download:
curl -sSI -H 'If-None-Match: "<digest>"' https://docs.sent.dm/api/openapi/v3Check the digest in CI to catch an API surface change before it reaches your users. A 200 where you expected a 304 is the signal to regenerate and review.
Why the digest is stable
Response examples in the document are built when the API generates it, and the timestamps inside them reflect that moment. Hashing the generator's output directly gives a different digest on every request even when nothing about the API has changed.
The document served here pins every example timestamp to a single value, so the digest tracks the API surface instead of the clock. Nothing else is altered: no field is added, removed, renamed, or restructured.
If you fetch from api.sent.dm/swagger/v3/swagger.json yourself, pin the timestamps before you hash or diff, or you'll see changes that aren't there.
What the document covers
Every v3 endpoint: its path, method, request body, response bodies, error shapes, and the headers Sent returns.
It also carries the schemas for the events Sent POSTs to your webhook endpoint, so you can generate types for the payload your handler receives rather than writing them by hand. Those schemas sit in components/schemas without being attached to an endpoint, because your endpoint receives them and ours doesn't serve them. Point your generator at the components directly.
For the event catalogue with a worked example of each payload, see Events Reference.
What it doesn't cover
- Retry and signature behaviour. How Sent retries a failed delivery, and how to verify a signature, are described in Handling retries and Signature verification.
- Rate limits. See Rate limits for the quotas that apply to your plan.
- The v2 API. v2 has its own document at
https://api.sent.dm/swagger/v2/swagger.json. It's maintained for backward compatibility, and new integrations should use v3. See Migrating from v2 to v3.
Working with strict validators
The document is OpenAPI 3.0.
Some validators reject nullable where it appears without an accompanying type, which this document does in a few places on composed schemas. If your generator stops there, drop nullable: false and rewrite nullable: true as a union with null. Both edits are safe because neither changes what the schema accepts.
Sent publishes the document without those rewrites. If you're checking a client against the real API, an artifact that restructures schemas would send you looking for bugs that aren't there.