Loading documentation…
Loading documentation…
Manage saved-URL lifetime through Customer authorization.
A delivery binding belongs to one Customer and Project. Customer Management uses the signed-in Customer session, not X-API-Key. List and mutate bindings at:
/v2/projects/{project_ref}/image-bindingsCreate a current binding before resolving. Lifecycle actions target /{binding_ref}/disable, /reactivate, /rotate or /retire. Use the returned version for optimistic concurrency and retain the mutation idempotency key while recovering an uncertain response. On a version conflict, reload and review the current state before applying a new command.
| Action | Saved URLs |
|---|---|
| Credential rotation | Preserved: the binding identity is unchanged |
| Disable binding | Subsequent delivery denied; reactivation can restore eligibility |
| Rotate binding | New resolves use the new namespace; old URLs work only until the chosen overlap deadline and while other access remains valid |
| Retire binding | Old namespace permanently unavailable; cannot reactivate it |
Choose an overlap deadline that allows your application to replace stored URLs. Confirm the permanent impact before retirement. A disabled binding does not cancel Billing access; a valid Billing entitlement does not reactivate a disabled binding. Binding lists and status are private workload metadata.
Disabling the current binding disables Images delivery for the entire Project, including a previous binding in rotation overlap. Reactivating the current binding enables Project delivery subject to Billing and Project status. Disabling a previous binding only affects that namespace. Service Accounts in the same Project share the current binding; their API scopes and private request identities remain separate.