Publish a template as a new immutable version
Snapshots the working copy into a new immutable version and points the template at it. This is what makes a template sendable, and it is the ONLY route that does. IT ANSWERS THE VERSION, NOT THE TEMPLATE, because a version is what it creates. Pin the id in the response if you are recording what a send used. APPEND ONLY. The new snapshot never replaces an old one, so every campaign that pinned an earlier version keeps resolving to exactly the copy it sent. Nothing the merchant had before this call is different afterwards except which version is current, and the next publish moves that again. An email template with no subject is 400 subject_required and a template with no body at all is 400 empty_body, because a snapshot no campaign could send is worse than a refusal.
Authorizations
A secret API key. Publishable keys cannot reach this API. A key may carry an expiry, and an expired key is refused exactly like an unknown one, with a 401 that names no reason; check the key's expires_at in the dashboard rather than inferring it from a response. When a merchant rolls a key's secret they choose a grace window of up to 3 days, and for its duration BOTH the new secret and the one it replaced authenticate, so an integration moves over on its own deploy schedule instead of at the instant the button is pressed. Move before the window closes: after it, the old secret is refused. Nothing else about this contract moves with a roll. The key keeps its id and its scopes, so the only thing an integration updates is the credential itself.
Headers
A unique key per logical write. Replaying a request with the same key returns the first response byte for byte instead of applying the write twice.
Path Parameters
Body
Takes no parameters, and an empty body is expected. What is snapshotted is whatever the working copy holds right now, so write the copy with the replace first and publish it second; there is no way to hand content to this route.
Response
Created
