Production checklist
Use this checklist before connecting a saved API to a scheduled job, customer feature, or downstream data pipeline. Start with the quickstart, then verify the same version, inputs, and credentials your application will use.
On this page
Confirm the contract#
- The build has succeeded and appears as a saved API in your workspace.
- You have recorded the source identifier, definition version, input schema, and output schema.
- Representative records contain the fields your application requires, with the expected types.
- Your request includes
expected_versionso a changed active definition requires review. - Each intended execution has a stored
Idempotency-Key; retries preserve the same key and request. - The selected collection and permitted inputs match your intended use of the source.
A preview demonstrates possible output. Run the accepted definition before relying on it. Pinning its version preserves the contract check; it does not freeze the source website or its data.
Establish a collection budget#
Begin with one page and no detail enrichment where the generated contract supports max_pages: 1 and detail_limit: 0. Increase scope deliberately after checking the result.
Record which outcome your application accepts:
| Outcome | Integration decision |
|---|---|
| Complete within the selected scope | Validate the records and continue if they meet your requirements. |
Bounded with catalog_complete: false |
Use only if your workflow accepts a subset of the source. |
Partial or within_scope_passed: false |
Preserve the response and route it for review or explicit partial-data handling. |
| Unknown execution outcome | Check the existing run before submitting another execution. |
Set a maximum run frequency and an application-level spending budget. Confirm the workspace has sufficient Units and review any enabled auto-reload settings.
Prepare the application#
Keep API credentials in server-side secret storage. Verify access using the credential assigned to this integration, and record its expiry. Test replacement credentials before revoking an in-use key.
Validate records before writing them to your destination. Preserve missing values according to the schema, keep the execution summary with each batch, and use your own stable record identity to prevent unwanted duplicate imports. Repeated source execution can return records you have already processed.
Configure finite timeouts and bounded retry behavior. Persist the execution key before sending the request, then preserve it with the unchanged request when recovering from a timeout. Review idempotency and errors and retries before enabling automatic retries.
Assign operational ownership#
Choose who reviews failed runs, schema changes, expiring credentials, and balance issues. Keep non-secret run identifiers and timestamps with your application logs so incidents can be traced to a specific request.
Verify monitoring against an actual recorded run. Document how to pause your own scheduler, review a changed definition, and resume after a successful bounded check. Keep the support checklist accessible to the people operating the integration.