Base URL and authentication
All paths are rooted athttps://api.courier.com. Send your workspace API key in the Authorization header as Bearer <token>.
Endpoint guide
The sections below describe the Notification Templates routes in the API Reference. Each one links to the matching operation for schemas, query parameters, and status codes.List templates
GET /notifications returns a paginated catalog of every notification template the workspace can see in the Studio list. The list is not split by editor type: Classic (V1) and Elemental (V2) rows can appear together. Inspect each item (or filter client-side) before you assume a uniform shape.
Get a template
GET /notifications/{id} loads one template by ID. Responses default to the published view; use the operation’s query parameters when you need the draft view instead. Use this when you already know the template ID and want settings and metadata without walking the full list.
Create and replace
POST /notifications creates a new template. PUT /notifications/{id} replaces an existing template in full (all required fields on each call). For both, notification content uses the Elemental shape (ElementalContentSchema). Build the same JSON you would derive from the Elemental overview: a version, an elements array, plus routing or channel data when your template needs it. That keeps API-driven drafts aligned with Design Studio.
Published and draft content
GET /notifications/{id}/content returns published content blocks for rendering and inspection. GET /notifications/{id}/draft/content returns the draft body. Use these when you need the actual block payload rather than only top-level template metadata from GET /notifications/{id}.
Publish and versions
POST /notifications/{id}/publish moves a draft toward what recipients see, either from the latest draft or from a specific version in the request body. GET /notifications/{id}/versions returns version history so you can audit what was published and when.
Archive
DELETE /notifications/{id} archives the template so it no longer appears in normal catalog flows.
Submission checks
Template approval flows attach checks to a submission.GET /notifications/{id}/{submissionId}/checks, PUT /notifications/{id}/{submissionId}/checks, and DELETE /notifications/{id}/{submissionId}/checks are the operations on that path. To understand how submissions fit into review and publish, see Template approval workflow.
Common responses
Each Notification Templates operation documents its ownresponses in openapi-specs/openapi.documented.yml in the mintlify-docs repo (paths under /notifications). Typical codes across those routes:
| Status | Meaning |
|---|---|
| 200 | Success with a JSON body (for example list, get, create, replace, version list, content reads, submission checks read/update) |
| 204 | Success with no body: POST /notifications/{id}/publish, DELETE /notifications/{id} (archive), DELETE /notifications/{id}/{submissionId}/checks |
| 400 | Bad request / validation error |
| 404 | Template or version not found (where that operation defines it) |
Workspace Templates vs Courier Create
These routes apply to your workspace notifications: one list per Courier account, aligned with what you see in the Studio template list and the dashboard. They use paths under/notifications/... and are not tenant-prefixed.
If you instead manage templates per tenant (for example with Courier Create), use /tenants/{tenant_id}/templates/...; see the Courier Create API reference for those routes.
What’s Next
How to Use the Templates API
List, create, publish, and fetch workspace templates with curl or SDKs
How to Build Notifications with Elemental
Patterns for
notification.content and channel-specific blocksSend API
Deliver messages that reference template IDs
Design Studio overview
Edit templates in the Studio UI