> ## Documentation Index
> Fetch the complete documentation index at: https://www.courier.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Templates API
> Workspace Notification Templates REST API for listing, creating, updating, and publishing notification templates.
This page documents the **workspace** Notification Templates REST API: list, create, read, replace, archive, publish, and list versions for templates attached to your Courier workspace.
Check out the [Templates API tutorial](/tutorials/content/how-to-use-templates-api) for a detailed walkthrough with code samples.
## Base URL and authentication
All paths are rooted at `https://api.courier.com`. Send your workspace [API key](/platform/workspaces/environments-api-keys) in the `Authorization` header as `Bearer `.
## 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`](/api-reference/notification-templates/list-notification-templates) 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}`](/api-reference/notification-templates/get-notification-template) 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`](/api-reference/notification-templates/create-notification-template) creates a new template; [`PUT /notifications/{id}`](/api-reference/notification-templates/replace-notification-template) fully replaces one. Both expect **`notification.content`** in the Elemental shape (`ElementalContentSchema`): a `version`, `elements`, and **`notification.routing`** settings, with brands, tags, and required fields. See the [Elemental overview](/platform/content/elemental/elemental-overview) for details.
`POST /notifications` and `PUT /notifications/{id}` endpoints only work with templates built in the new Design Studio (Elemental); you can’t use them with older Classic (V1) templates.
### Published and draft content
[`GET /notifications/{id}/content`](/api-reference/notification-templates/get-notification-content) returns **published** content blocks for rendering and inspection. [`GET /notifications/{id}/draft/content`](/api-reference/notification-templates/get-notification-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`](/api-reference/notification-templates/publish-notification-template) 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`](/api-reference/notification-templates/list-notification-template-versions) returns **version history** so you can audit what was published and when.
### Archive
[`DELETE /notifications/{id}`](/api-reference/notification-templates/archive-notification-template) **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`](/api-reference/notification-templates/get-submission-checks), [`PUT /notifications/{id}/{submissionId}/checks`](/api-reference/notification-templates/replace-submission-checks), and [`DELETE /notifications/{id}/{submissionId}/checks`](/api-reference/notification-templates/cancel-submission) are the operations on that path. To understand how submissions fit into review and publish, see [Template approval workflow](/platform/content/template-approval-workflow).
## Common responses
Each **Notification Templates** operation documents its own `responses` in the OpenAPI spec (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](/platform/create/installation)), use `/tenants/{tenant_id}/templates/...`; see the [Courier Create API](/platform/create/courier-create-api) reference for those routes.
## What's Next
Design Studio and Elemental-focused API guidance
List, create, publish, and fetch workspace templates with curl or SDKs
Patterns for `notification.content` and channel-specific blocks
Deliver messages that reference template IDs