Going to Production: A Checklist

You've tested with sandbox credentials, made successful API calls, and your integration is working. Before you go live with real users, walk through this checklist to make sure everything is production-ready.

• Configure your own OAuth apps

• Use real consumer IDs

• Set up webhooks

• Implement error handling

• Handle rate limits

• Monitor with logs

• Secure your API keys

• Test the end-to-end user flow

• Quick reference checklist

This is the most important step. For some connectors, Apideck provides sandbox OAuth apps so you can test authorization flows without any setup. When you enable a connector in the dashboard, you'll see an option to "Use Apideck credentials", this lets you start testing right away. However, these are intended for development only.

In production, you'll need your own OAuth credentials. How you get them depends on the provider:

• Some providers let you register a developer app and get credentials in minutes.

• Others require a formal partnership agreement, app review, or certification process that can take several weeks.

Check the connector-specific guide in the Apideck developer portal or the provider's developer documentation early to understand their requirements and avoid delays. Once you have your credentials, add them per connector in the Apideck dashboard under Configuration.

During testing, you likely used test-consumer or similar placeholder IDs. In production, each consumer ID should correspond to a real user or account in your system.

Ensure that:

• Consumer IDs are unique and stable - don't use values that might change (like email addresses).

• The same consumer ID is used consistently between Vault sessions and API calls.

• You have a clear mapping in your system between your user/account records and their Apideck consumer IDs.

For more on how consumer IDs work, see Understanding API Headers, Consumers, and Service IDs.

Webhooks let you react to events in real time instead of polling. The Webhooks section of this help center covers setup in detail, but at minimum you'll want to subscribe to:

Vault events (connection lifecycle):

• vault.connection.created - A user connected an integration.

• vault.connection.updated - A connection's settings were changed.

• vault.connection.disabled - A connection was disconnected.

• vault.connection.revoked - An access token was revoked.

Unified API events (data changes):

• Events for creates, updates, and deletes on the resources you use.

Configure webhooks from the Webhooks page in your dashboard.

Verify webhook signatures to ensure events genuinely come from Apideck. All events include a x-apideck-signature header. See the webhook signature verification guide for implementation details.

Your app should gracefully handle these common scenarios:

401 Unauthorized - The user's access token has expired or been revoked. Apideck handles token refresh automatically in most cases, but if a user revokes access from within their provider's settings, you'll get a 401. Prompt the user to reconnect via Vault.

402 Payment Required - Your plan's usage limits have been reached. See Unify API Usage Counting Explained for how usage is calculated.

404 Not Found - The resource doesn't exist, or the consumer/connection wasn't found. Double-check your consumer ID and service ID.

422 Unprocessable Entity - The request body failed validation. Check the error response for field-level errors.

429 Too Many Requests - You've hit the downstream provider's rate limit. Implement exponential backoff. See Is there a rate limit for Unify?.

ConnectorExecutionError - The downstream provider returned an error. The downstream_errors array will contain the provider's original error message.

For the full error reference, see developers.apideck.com/errors.

Each downstream provider has its own rate limits. Apideck passes these through via standardized headers (x-downstream-ratelimit-limit, x-downstream-ratelimit-remaining, x-downstream-ratelimit-reset).

Best practices:

• Read these headers on every response and track remaining quota.

• Implement exponential backoff when you receive a 429 response.

• Pace bulk operations to stay within limits.

• Use updated_since filters to minimize API calls for incremental syncs.

For more on pagination and filtering strategies that reduce API usage, see How Pagination, Filtering, and Sorting Work.

The Apideck dashboard includes a Logs section where you can inspect every API call. In production, regularly check for elevated error rates, failing consumer connections, and unexpected response shapes.

For a walkthrough, see How to see the log of a request.

Before going live, verify that:

• Your API key is only used in server-side code. Never expose it in frontend JavaScript or mobile apps.

• Vault sessions are created server-side. The session token (JWT) is safe to pass to the client, but the creation call must happen on your server.

• Your API key is stored in environment variables or a secrets manager, not hardcoded.

• You have a process for rotating your key if compromised (regenerate from the API Keys page).

For more on Apideck's security approach, see Security and Encryption Practices.

Before launch, walk through the complete journey:

1. A new user in your app opens Vault (via Vault JS, Hosted Vault, or your custom UI).

2. They select and authorize a connector.

3. Your app detects the new connection (via webhook or polling).

4. Your app makes its first API calls on behalf of that user.

5. Data flows correctly into your system.

6. The user disconnects the integration, and your app handles it gracefully.

Test with at least one real connector (not just the sandbox). If you're supporting multiple connectors, test the most critical ones - different providers can behave differently.

• Custom OAuth apps configured for all enabled connectors

• Real consumer IDs mapped to your user/account model

• Webhooks configured for connection lifecycle events

• Webhooks configured for data change events (if applicable)

• Webhook signature verification implemented

• Error handling for 401, 402, 404, 422, 429, and ConnectorExecutionError

• Rate limit handling with exponential backoff

• API key secured (server-side only, stored in env vars or secrets manager)

• Logs monitored in the Apideck dashboard

• End-to-end user flow tested with a real connector
  
  
  Related resources:

• Account Management section

• Webhooks section

• Security and Encryption Practices

• Error reference

• Unified Rate Limits guide

• Webhook signature verification guide

• Apideck status page