Sandbox Development

Atlas API sandbox development guide for building, testing, and validating booking workflows before UAT.

💬 Need help? If you're stuck, ask Eva in the Help Center for instant diagnostics.

Ask Eva

Use this page to build and validate the full Atlas integration in sandbox.

For first-time integrations, settlement currency may not be configured in Atlas yet.

In sandbox, add "currency":"USD" manually in the Search request until the account setup is complete.

Before you build the integration, run the Sandbox Validation Test Kit.

Use it to confirm credentials, network access, and the core happy path without writing code.

Start here when you need to:

• build the full sandbox booking flow

• validate webhook handling and follow-up logic

• confirm the integration is ready for UAT

FAQ

What should be working before sandbox development starts?

Sandbox credentials should work first.

Headers, request format, and gzip handling should also be ready.

What proves sandbox development is complete?

The full booking flow should run end to end in a stable way.

Your team should also be able to reproduce expected success and failure paths.

Goal of this phase

Build the end-to-end integration flow in sandbox.

This phase should cover both API execution and webhook follow-up.

Fast setup check

Use the Sandbox Validation Test Kit before full development work.

It validates Search, Verify, Order, and Pay.

If the final retrieve step times out, treat that as expected during ticketing polling.

What sandbox can validate

Use sandbox to validate:

• request format and headers

• search, verify, order, payment, and query flow

• webhook handling and follow-up logic

• failure handling and edge cases

• UAT readiness

What sandbox does not prove

Sandbox does not prove:

• live inventory quality

• production pricing accuracy

• real card charging behavior

• final airline-side behavior in all cases

Treat sandbox fares and outcomes as test-only.

Before you start

Make sure you already have:

• sandbox credentials from ATRIP

• the sandbox base URL: https://sandbox.atriptech.com/

• request headers configured

• a basic server-side integration ready to test

Use MCP during development

Use MCP-Assisted Development when you need help finding the right flow, page, or next API step.

It works well for:

• mapping Search to Pay

• checking which identifier to keep and reuse

• routing errors to the right troubleshooting page

Development checklist

Complete these items in sandbox:

• configure authentication and headers

• point your client to sandbox

• implement search, verify, order, payment, and query

• register and validate webhooks

• test failure handling and edge cases

During this phase, keep and reuse:

• routingIdentifier

• sessionId

• orderNo

Recommended build order

1

Confirm sandbox setup

Make sure credentials, headers, gzip handling, and the sandbox base URL are working.

2

Build the booking flow

Implement search, verify, order creation, payment, and order query.

3

Add webhook handling

Register the webhook endpoint and validate event delivery and processing.

4

Test expected failures

Simulate payment and flow failures and confirm error handling works as expected.

5

Prepare for UAT

Keep traceable test orders and confirm the full sandbox flow is stable and repeatable.

Test mode

In test mode:

• bookings are simulated

• tickets are not issued with live airlines

• fares are sandbox fares

• test credentials only work in sandbox

• live credentials only work in production

Use test mode to validate:

• request construction

• booking state transitions

• payment and ticketing logic

• expected error handling

• webhook and follow-up behavior

Sandbox fare behavior

Sandbox search results come from Atlas sandbox data.

Coverage and pricing are not the same as production.

Do not use sandbox prices for commercial comparison.

Payment failure simulation

You can trigger common VCC error paths in pay.do.

Trigger payment decline

Use:

• Cardholder first name: Reject

Expected result:

• 604 — Payment declined by airline

Trigger 3DS error

Use:

• Cardholder first name: Three DS

Expected result:

• 616 — 3DS Authentication

Any card number and last name can be used for this specific failure simulation.

Reference data for sandbox

Use these shared reference pages when you need published sandbox inputs:

• Booking Overview

• Webhook Overview

• Sandbox Test Routes

• Sandbox Test Cards

• Integration Reference

Complete this phase when

You can do all of these reliably in sandbox:

• run the booking flow end to end

• keep and reuse routingIdentifier, sessionId, and orderNo

• validate the required payment path

• receive and process the required webhook events

• reproduce expected success and failure cases

Output of this phase

• stable sandbox booking flow

• validated webhook handling

• evidence ready for UAT

Next step

Move to UAT Validation after the sandbox flow is stable.

Related pages

• Quick Start

• Sandbox Access

• Sandbox Validation Test Kit

• UAT Validation

• Webhook Overview