Production and tooling
Go-Live Checklist
Use this checklist before a customer integration moves from test data to live operations. It is written for B2B clients connecting catalog, user, billing, branding, or reporting workflows.
Access and ownership
| Check | Why it matters |
|---|---|
| Enterprise Delivery API is active for the organization. | Protected API endpoints require the product to be enabled. |
| API credentials are owned by an accountable admin. | Credentials must be rotated without breaking unrelated systems. |
| Separate credentials exist for each integration. | One compromised integration should not affect every workflow. |
| Required add-ons are active. | Members, Smartlinks, Theme Editor, and other modules can be product-gated. |
| Acting-for-user behavior is tested only on supported endpoints. | X-User-Id should not be treated as universal impersonation. |
Environment and data
| Check | Why it matters |
|---|---|
Staging tests use https://staging.spacemedia.uk. | Integration rehearsals should not use live catalog or payment data. |
Production cutover uses https://enterprise.spacemedia.uk. | Live automation should target the documented production host only after sign-off. |
| Credentials are separate per environment. | A staging client should not be able to affect production records. |
| Sample data is fictional and clearly marked. | Test releases should not leak real artist, customer, or payment data. |
| Staging submission and terminal simulated delivery are tested. | Staging follows the public lifecycle but cannot send a release to a DSP. |
The client recognizes delivery_simulated. | A staging terminal state must not be presented as real storefront availability. |
| Expired staging media can be uploaded again. | Staging release files are temporary and automatically removed after retention. |
| Public references are stored in your system. | Follow-up calls need release_id, track_id, artist_id, user_id, and similar public references. |
| Internal numeric references are not stored or shown to operators. | Public integrations must not depend on internal storage references. |
Authentication
| Check | Why it matters |
|---|---|
| Token exchange works in the target organization. | API credentials alone are not sent to protected endpoints. |
| Token expiry is handled before protected calls fail. | Avoid repeated 401 failures in production. |
| Secrets are never logged. | API key, API secret, bearer token, payment tokens, and webhook secrets must stay private. |
| Support screenshots are sanitized. | Operators often paste playground or console output during go-live. |
Catalog workflow
| Check | Why it matters |
|---|---|
| Artist create and list flows are tested. | Release creation depends on stable artist references. |
| Release create uses multipart data when uploading cover art. | Cover upload and metadata must be sent in the correct format. |
Audio upload returns audio_file_id. | Track creation must use the upload reference returned by the API. |
Track creation returns track_id. | Later ordering, attachment, and reporting use the stable track reference. |
| License, territories, and distribution selections are saved. | Delivery cannot be valid without rights and destination data. |
| Readiness checks run before submission. | Blocking issues should be fixed before review. |
| Submission is not automatically retried after timeout. | Fetch state before submitting again. |
| Review and delivery polling is bounded. | Avoid customer systems over-polling during downstream delays. |
Metadata
| Check | Why it matters |
|---|---|
| Titles and versions are clean. | DSPs can reject titles with promo text or duplicated version data. |
| Artist roles are structured. | Artist display and contributor credits depend on role fields. |
| Explicit flags are accurate. | Incorrect explicit metadata can block or misrepresent delivery. |
| Artwork passes size and content rules. | Cover art failures are a common release blocker. |
| UPC, ISRC, and ISWC values are correct when supplied. | Identifier mistakes can cause catalog conflicts. |
| Territories match the customer's rights. | Wrong territories can create rights issues or missed delivery. |
Billing and checkouts
| Check | Why it matters |
|---|---|
Checkout creation stores checkout_id. | Verification and support need the public checkout reference. |
| Embedded checkout data is treated as short-lived. | It is not a durable payment reference. |
| Retry behavior avoids duplicate checkout creation. | Timeouts can otherwise create multiple payment attempts. |
| Failed or expired checkouts show recovery actions. | Operators need a clear path to retry safely. |
SDK and client behavior
| Check | Why it matters |
|---|---|
| Generated client preserves public field names. | SDKs should not rename public references into confusing generic fields. |
Pagination helpers expose meta. | Integrations must know when list sync is complete. |
Error handlers parse errors. | Field-level validation helps operators fix payloads quickly. |
| Retry policy follows the documented table. | Prevent duplicate releases, checkouts, top-ups, and submissions. |
| Unknown status values are displayed safely. | New states should not break customer dashboards. |
Production cutover
- Run the full workflow with fictional records.
- Verify expected records in the dashboard.
- Confirm no internal references or secrets appear in logs.
- Confirm retry behavior with a forced timeout in the customer client.
- Confirm validation error display with an intentionally incomplete draft.
- Confirm checkout failure recovery if the integration uses payments.
- Confirm review and delivery polling does not exceed the agreed operating volume.
- Lock credentials to the production integration owner.
- Archive test data or keep it clearly labeled.
- Switch the customer system to live records only after sign-off.
Support packet
For launch support, prepare:
- Organization name.
- Integration owner contact.
- Endpoint groups used.
- Public references for affected records.
- Timestamp and timezone.
- Sanitized request and response examples.
- Client version or SDK version.
- Steps already retried.
Do not include secrets, payment provider references, raw customer credentials, or private keys.
Common questions
How much of this can I skip if the integration is small? The authentication, retry, and support items apply at any size. Catalog and billing sections apply only if you use those areas.
What proves staging readiness? A complete rehearsal: token exchange, a catalog flow through submission, a simulated review and delivery result, and a deliberate failure you recovered from. See Staging Environment.
Do I need new credentials for production? Yes. Staging and production credentials are separate, and reusing one across environments is the most common way secrets leak.
Who signs off? Name an owner for the credential, the integration, and the escalation path before cutover. An integration nobody owns is the one that fails silently.
Was this page helpful?