A forwarding deployment publishes a reviewed configuration to the assigned HTTP or mail runtime. Keep configuration, deployment and public verification as separate states in your integration. A saved rule can exist before any runtime is ready to serve it.
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
POST |
/v2/forwarding/domains/{domainId}/deploy |
forwarding:deploy |
Required |
GET |
/v2/forwarding/deployments/{deploymentId} |
forwarding:read |
Not required by this route |
POST |
/v2/forwarding/deployments/{deploymentId}/rollback |
forwarding:deploy |
Required |
IN THIS ARTICLE
01 Prepare and deploy
- Read the forwarding domain and resolve pending DNS ownership verification, hosting or mail conflicts and service restrictions.
- For HTTP, inspect the enabled rules, priorities and tested destination transformations. For mail, confirm that each intended destination has completed verification.
- Record the currently working deployment generation and its important tests. Preserve enough evidence to recognise a rollback target.
- POST to the domain's
deployendpoint with the deployment scope and an idempotency key. - Store the returned deployment or job reference. Read the deployment state until it either completes or reports a failure that needs attention.
- Test the public hostname through the configured runtime. Verify both apex and www when enabled, HTTPS certificate presentation and the final redirect destination. For mail, send a controlled message to the intended alias.
02 Roll back deliberately
If a new generation causes a problem, inspect the recorded deployments and identify the retained deployment relevant to the recovery. Request its rollback through the supported endpoint. Keep the returned reference and verify the active generation and public behaviour afterward.
A rollback depends on retained deployment evidence and runtime availability. It cannot make an unreachable cluster respond, restore expired third-party credentials or undo unrelated registrar nameserver changes. If DNS now sends traffic elsewhere, repair the delegation or record change as part of the recovery plan.
Common questions
Should I submit deploy repeatedly while it is pending?
Follow the existing operation first. A transport retry should use the same idempotency key and identical request; an intentional new deployment is a separate action after you understand the previous result.
Will rollback reverse mail already delivered?
No. It changes the applicable runtime configuration. Messages already accepted or delivered and external recipient data have their own outcomes.
What evidence should I give support?
Provide the forwarding-domain ID, deployment ID, relevant generation, request time and a failing sample URL or redacted mail trace. Include the expected destination and observed behaviour without exposing verification codes or runtime credentials.