From sandbox to production

A plan with a sandbox runs a developer through a review pipeline before production. The developer builds against sandbox credentials, submits the subscription for review, your team approves it, and production credentials unlock. The phases are Sandbox, In Review, and Production.

What are the phases of the pipeline?

A sandbox subscription holds one pipeline phase at a time. The subscription's stepper shows three phases, and a submission that is turned down is marked separately.

When your team requests changes, the subscription returns to Sandbox and is flagged Changes Requested, with your reviewer's notes shown to the developer.

How does a developer get started in sandbox?

A sandbox subscription opens on the sandbox lane. The developer creates sandbox credentials, optionally generates a token, and reviews the provider's sandbox test data, then builds against the sandbox endpoints.

1. The developer opens the subscription and finds the Sandbox Credentials card.
2. They create the credentials. The card shows the full value once, with a warning to save it.
3. They open View Test Data to see the Sandbox Test Data the provider configured.
4. They build and test, using the explorer's sandbox documentation where the plan provides it. See Trying endpoints in the explorer.

The production credential card stays locked through the sandbox and review phases. It explains that production credentials become available once an API provider has reviewed and approved the request.

What is sandbox test data?

Sandbox test data is a read-only set of custom properties the provider configures on the sandbox. The developer opens the Sandbox Test Data view to read them while testing.

Each entry shows a type, a name, a description, and a value. The view is read-only, so the developer copies the values they need rather than editing them.

How does a developer submit for review?

When sandbox credentials exist, the Submit for Review action becomes available. If the plan defines a submission form, the developer completes it first. If not, the submission goes straight through. Either way the subscription moves to In Review.

1. With the subscription in Sandbox, the developer clicks Submit for Review.
2. If the plan has a submission form, a multi-step form opens, ending in a review step before the developer submits.
3. The subscription moves to In Review, and the button reads Submitted for Review.

Submitting requires that credentials were created first. A subscription with no sandbox credentials cannot be submitted for review.

What does your team do with a submission?

Your team reviews the submission and takes one of three actions. Each is recorded on the subscription, and the developer sees the result on the subscription page.

Requesting changes requires notes. The developer reads the notes, adjusts the integration in sandbox, and submits for review again.

How does a developer reach production?

After your team approves, the subscription enters the Production phase and the production credential card unlocks. The developer creates production credentials and switches their integration to them.

1. Your team approves the submission. The subscription moves to Production.
2. The production credential card unlocks. It confirms the integration was approved.
3. The developer creates production credentials. The full value is shown once.
4. On a paid plan, the production card stays locked until payment is complete. See Subscribing to a plan.

See API credentials for the credential types and the difference between Regenerate and Rotate Secret, which apply to both the sandbox and production credentials.

Where to next