# Production checklist

Use this checklist before connecting a saved API to a scheduled job, customer feature, or downstream data pipeline. Start with the [quickstart](/docs/quickstart/), then verify the same version, inputs, and credentials your application will use.

## 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_version` so 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](/docs/billing/).

## 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](/docs/idempotency/) and [errors and retries](/docs/errors/) 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](/docs/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](/docs/support/) accessible to the people operating the integration.