Attach domains to a revision

Bind domains to this revision. Bindings are scoped to this revision only — other revisions keep their existing routing.

Each hostname must fall under a domain your organization has already verified, following the same rule and {variable} template syntax as the domains field on POST /apps/{app}/deploy (see its production/preview documentation).

You can also (re-)attach this revision to the app's default managed domains post-deployment by listing the default-alias template — the same value POST /apps/{app}/deploy accepts (e.g. {deno.app.slug}.<org>.<managed-domain> under production, or the per-revision {deno.app.slug}-{deno.revision.id}.… under preview). Listing it sets the timeline label on the revision rather than pinning a custom hostname: the default production host floats to the latest revision attached this way, while each revision keeps its own default preview host.

Binding the same hostname to this revision again is a no-op. Use DELETE /revisions/{revision}/domains/{hostname} to remove a binding.

A hostname always resolves to exactly one revision. Binding is additive: attaching a hostname to a revision never detaches it from any revision it is already bound to. When a hostname is bound to several revisions, the most recently created revision wins.

Because the newest bound revision always wins, moving a hostname forward to a newer revision is just an attach: bind it to the newer revision and that revision immediately takes over routing — you do not detach the old one. Moving a hostname back to an older revision is different: re-attaching the older revision has no effect while a newer revision is still bound, so you must explicitly DELETE the binding on every newer revision. Detaching the currently-winning revision falls back to the next most recently created revision that is still bound; the hostname only stops routing once its last binding is removed.

Returns 204 No Content on success.

put/v2/revisions/{revision}/domains

Path parameters

revisionstring required

Revision ID (globally unique)

Request body

productionstring[]

Hostnames to bind to this revision under the production timeline. Every entry must fall under a domain your organization has already verified — either the verified domain itself (an apex hostname such as my-domain.com bound against the verified my-domain.com) or a subdomain of a verified wildcard domain (such as my-app.my-org.deno.net bound against the verified *.my-org.deno.net). A hostname that does not fall under any verified domain is rejected. The leading label of a subdomain may contain {variable} template expressions so the hostname resolves to a distinct value per revision. Template variables may appear only in the first label, may be combined with static text and with each other (e.g. pr-{deno.revision.id} or {deno.app.slug}--{deno.revision.id}), and must not contain a dot. The available variables are {deno.revision.id}, {deno.app.slug} (or its opaque equivalent {deno.app.id}), and {deno.organization.id}. A hostname always resolves to exactly one revision: binding is additive, but when a hostname is bound to multiple revisions the most recently created revision wins. To roll a hostname back to an older revision you must explicitly detach the newer revision(s) via DELETE /revisions/{revision}/domains/{hostname}.

previewstring[]

Hostnames to bind to this revision under the preview timeline. Every entry must fall under a domain your organization has already verified — either the verified domain itself (an apex hostname such as my-domain.com bound against the verified my-domain.com) or a subdomain of a verified wildcard domain (such as my-app.my-org.deno.net bound against the verified *.my-org.deno.net). A hostname that does not fall under any verified domain is rejected. The leading label of a subdomain may contain {variable} template expressions so the hostname resolves to a distinct value per revision. Template variables may appear only in the first label, may be combined with static text and with each other (e.g. pr-{deno.revision.id} or {deno.app.slug}--{deno.revision.id}), and must not contain a dot. The available variables are {deno.revision.id}, {deno.app.slug} (or its opaque equivalent {deno.app.id}), and {deno.organization.id}. A hostname always resolves to exactly one revision: binding is additive, but when a hostname is bound to multiple revisions the most recently created revision wins. To roll a hostname back to an older revision you must explicitly detach the newer revision(s) via DELETE /revisions/{revision}/domains/{hostname}.

Response

Changes

No recorded changes to this endpoint across all 1 revision of this API.