Developer Platform

Integration go-live checklist

A practical review for credentials, scopes, retries, webhooks, observability, test isolation, and operational ownership.

Use this checklist before an integration handles customer data or performs production mutations. Passing a happy-path request is not enough.

Identity and secrets

• Create a dedicated API client for the integration and environment.
• Remove scopes that the exercised operation inventory does not require.
• Store credentials and connector secret references in an approved secret manager.
• Document rotation and emergency revocation, then test both.
• Verify the returned auth context matches the intended SaaS app during startup.

Requests and recovery

• Bound timeouts, concurrency, pages, and retry attempts.
• Retry only safe or idempotent operations and honor Retry-After.
• Test duplicate webhook delivery, out-of-order events, stale signatures, and dead-letter retry.
• Handle 401, 403/safe 404, 409, 422, 429, and 5xx deliberately.
• Use documented status, retry, recovery, and correlation workflows during an outage.

Compatibility and observability

• Validate examples/SDK calls against the current OpenAPI operation IDs.
• Pin the Developer Kit version and OpenAPI checksum used to generate or validate the integration.
• Log operation, duration, status, app ID, and correlation ID without secrets or raw sensitive bodies.
• Create alerts for sustained authentication failures, rate limiting, webhook dead letters, and failed async jobs.
• Name a human owner and escalation path for each integration, inbound endpoint, webhook subscription, and connector.

Environment proof

Exercise the exact production origin and credential only through an approved deployment check. A successful local or staging contract test does not prove DNS, certificates, rate configuration, external callbacks, or production secret delivery.

Enterprise release evidence

• Prove cross-organization and cross-app denial for both rows and counts, including forged identity selectors, restricted locations, revoked credentials and read-only write denial.
• Pin the kit checksum and app-specific OpenAPI fingerprint; test backward compatibility and contract readiness for every routed database before runtime activation.
• Document durable file/log storage outside release directories, backup ownership, a tested restore procedure, rollback verification and named on-call responsibility.
• Set and measure your required availability, latency, recovery-time and recovery-point targets. A successful battle test is not an uptime guarantee, recovery certification or compliance attestation.
• Confirm retention, deletion, data residency, external-provider handling and incident escalation for your deployment and agreement; do not infer them from an API feature list.
• Track unavailable or planned capabilities explicitly. Installed-service Tasks and Skills are current; workflow/AI-job task projections, Builder Account MCP, Developer VM MCP, MRTR and an MCP OAuth authorization server must not be inferred from those capabilities.

Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.