Amazon Sandbox: Testing Environments for Sellers and Developers

Published: February 27, 2017
Last updated: May 04, 2026

An Amazon Sandbox is a testing environment where sellers and developers can build, test, and debug integrations with Amazon’s marketplace systems without affecting live data, real transactions, or actual buyer experiences. Sandbox environments let you verify that API calls, payment flows, and automated workflows function correctly before deploying them in production.

Amazon currently provides sandbox access through the Selling Partner API (SP-API) - the primary integration framework for Amazon marketplace development. The SP-API Sandbox offers both static and dynamic testing modes for developers building seller tools, order management systems, and catalog integrations.

---

Table of Contents

1. What Is an Amazon Sandbox?
2. Selling Partner API (SP-API) Sandbox
3. How to Access the SP-API Sandbox
4. Static vs. Dynamic Sandbox
5. Amazon Pay Sandbox
6. Sandbox vs. Production
7. Who Needs a Sandbox?
8. FAQs

---

What Is an Amazon Sandbox?

A sandbox is a testing environment that mirrors the functionality of Amazon’s production systems without processing real transactions. In a sandbox:

• No real charges - transactions are simulated; no money changes hands
• No real orders - test orders do not appear in your Manage Orders queue or affect inventory
• No buyer impact - testing does not affect real customers or product listings
• Safe debugging - you can trigger error conditions and edge cases without consequences

Sandbox environments are essential for any seller or developer building custom integrations with Amazon’s marketplace - whether automating order management, syncing inventory across channels, or building custom reporting tools.

---

Selling Partner API (SP-API) Sandbox

The Selling Partner API (SP-API) is Amazon’s current integration framework for marketplace operations. It replaced the older Marketplace Web Service (MWS), which was fully deprecated. The SP-API provides sandbox environments for testing all supported API operations.

What You Can Test

• Catalog operations - adding and updating product listings
• Order operations - retrieving orders, confirming shipments, processing cancellations
• Inventory management - updating stock levels across fulfillment channels
• Feeds - submitting bulk data updates (pricing, inventory, product data)
• Reports - requesting and downloading business reports
• Notifications - subscribing to and receiving event notifications
• Fulfillment - testing FBA inbound shipment workflows

SP-API Sandbox Capabilities

Feature	Sandbox	Production
Real transactions	No	Yes
Actual buyer orders	No	Yes
API call structure	Identical	Identical
Error simulation	Yes	No
Rate limits	Relaxed	Standard throttling
Data persistence	Limited	Full

The sandbox uses the same API endpoints and request/response structures as production, so code that works in the sandbox will work in production with minimal changes - typically just switching the endpoint URL and credentials.

---

How to Access the SP-API Sandbox

Prerequisites

1. Professional selling plan - SP-API access requires a Professional seller account ($39.99/month)
2. Developer registration - register as a developer in Seller Central under Apps & Services > Develop Apps
3. Application registration - create an application in the Developer Central portal
4. API credentials - obtain your Login with Amazon (LWA) credentials (client ID and secret)

Setup Steps

1. Sign in to Seller Central and navigate to Apps & Services > Develop Apps
2. Register your developer profile if you have not already
3. Create a new application or select an existing one
4. Note your LWA credentials (client ID and client secret)
5. Use the sandbox endpoint URLs provided in the SP-API documentation
6. Authenticate using the same OAuth flow as production
7. Make API calls to the sandbox endpoints for testing

Sandbox Endpoints

SP-API sandbox calls use dedicated endpoint URLs that differ from production URLs. The request format, headers, and authentication are identical - only the base URL changes. Consult the SP-API documentation for current sandbox endpoint addresses, as these may be updated.

---

Static vs. Dynamic Sandbox

The SP-API Sandbox offers two testing modes:

Static Sandbox

The static sandbox returns pre-defined responses for specific API calls. You send a request with defined parameters, and the sandbox returns a fixed response.

Use the static sandbox when you need to:

• Verify your code correctly handles API response formats
• Test error handling with known error responses
• Build and validate data parsing logic
• Run automated tests with predictable outputs

Dynamic Sandbox

The dynamic sandbox processes requests and returns variable responses that simulate real API behavior more closely.

Use the dynamic sandbox when you need to:

• Test end-to-end workflows (e.g., create listing → receive order → confirm shipment)
• Validate business logic under varying conditions
• Simulate realistic scenarios with different data sets
• Test notification subscriptions and event handling

Which to Use

Scenario	Recommended Mode
Initial integration development	Static
Unit testing and CI/CD pipelines	Static
End-to-end workflow testing	Dynamic
Pre-launch validation	Dynamic
Error handling verification	Static

Most developers start with the static sandbox during initial development and switch to the dynamic sandbox for integration testing before going live.

---

Amazon Pay Sandbox

Amazon Pay provides a separate sandbox environment for testing payment integrations. This is relevant for sellers and businesses that use Amazon Pay as a checkout option on their own websites or applications.

Amazon Pay Sandbox Features

• Simulated transactions - process test payments without real charges
• Test buyer accounts - create simulated buyer profiles for testing
• Payment flow testing - verify checkout buttons, payment forms, and confirmation pages
• Error simulation - test declined payments, insufficient funds, and other failure scenarios
• Refund testing - validate refund processing workflows

Access

Amazon Pay Sandbox access is available through the Amazon Pay integration portal. Developers register for Amazon Pay, obtain sandbox credentials, and use sandbox-specific endpoints for testing.

---

Sandbox vs. Production

Understanding the differences between sandbox and production environments prevents costly mistakes:

Key Differences

Aspect	Sandbox	Production
Transactions	Simulated - no real money	Real - actual charges and disbursements
Orders	Test data only	Real buyer orders
Inventory	Not affected	Updated in real time
Buyer notifications	Not sent	Sent to real buyers
Performance metrics	Not tracked	Affects Account Health
Rate limits	Relaxed for testing	Standard API throttling
Data	Test data, may reset	Persistent, production data

Best Practices for Transitioning to Production

• Test thoroughly in sandbox first - verify all API calls return expected results
• Use separate credentials - never mix sandbox and production API keys
• Validate error handling - ensure your application handles all error codes gracefully
• Monitor initial production calls - watch for unexpected responses after switching
• Start with low-volume operations - gradually increase API call volume in production

Common Mistake

A critical risk is accidentally running sandbox-configured code in production or vice versa. If your application sends production API calls with sandbox parameters, transactions may fail. If sandbox code accidentally points to production endpoints, it could create real orders or modify live listings. Always use environment variables or configuration files to separate sandbox and production settings.

---

Who Needs a Sandbox?

Not every Amazon seller needs sandbox access. The sandbox is designed for specific use cases:

You Need a Sandbox If You

• Build custom integrations - connecting Amazon to your own systems (ERP, WMS, CRM)
• Develop seller tools - creating software that manages listings, orders, or advertising
• Automate operations - building automated workflows for pricing, inventory, or fulfillment
• Offer third-party services - developing applications for other Amazon sellers
• Manage multi-channel selling - synchronizing Amazon with other sales channels

You Likely Do Not Need a Sandbox If You

• Use only Seller Central - the web portal handles all operations without API access
• Use existing third-party tools - tools like repricers and inventory managers handle their own integrations
• Sell at low volume - manual management through Seller Central is sufficient
• Do not develop software - the sandbox is a developer tool, not a general seller feature

Historical Note

Amazon previously offered a sandbox environment through the Flexible Payments Service (FPS), which allowed sellers to test payment buttons and checkout flows. FPS was discontinued in June 2015 and replaced by Amazon Pay and the Selling Partner API. The SP-API Sandbox provides more comprehensive testing capabilities than the original FPS Sandbox.

---

FAQs

What is the Amazon Sandbox?

The Amazon Sandbox is a testing environment where developers and sellers can test API integrations with Amazon’s marketplace without affecting live data or processing real transactions. The current sandbox is part of the Selling Partner API (SP-API).

Do I need a sandbox to sell on Amazon?

No. The sandbox is a developer tool for building custom integrations. Most sellers manage their business entirely through Seller Central or existing third-party software and never need sandbox access.

How do I access the SP-API Sandbox?

You need a Professional seller account, developer registration through Seller Central, and registered API credentials (LWA client ID and secret). Access the sandbox through dedicated sandbox endpoint URLs using the same authentication as production.

Is the sandbox free?

There are no separate charges for using the SP-API Sandbox. You need a Professional selling plan ($39.99/month) for SP-API access, but sandbox API calls themselves do not incur additional fees.

What is the difference between static and dynamic sandbox?

The static sandbox returns pre-defined responses for predictable testing. The dynamic sandbox simulates real API behavior with variable responses. Use static for initial development and unit tests; use dynamic for end-to-end workflow validation.

What happened to the Amazon FPS Sandbox?

The Amazon Flexible Payments Service (FPS) Sandbox was discontinued in June 2015 when Amazon retired the FPS platform. Current testing environments are the SP-API Sandbox (for marketplace integrations) and the Amazon Pay Sandbox (for payment integrations).

Can I create test orders in the sandbox?

Yes. The SP-API dynamic sandbox allows you to simulate order creation, shipment confirmation, and other order lifecycle events without creating real orders or affecting your seller metrics.

---

Summary

An Amazon Sandbox is a testing environment for building and validating marketplace integrations:

• SP-API Sandbox - primary testing environment for Amazon marketplace integrations (catalog, orders, inventory, feeds, reports)
• Two testing modes - static (pre-defined responses) and dynamic (simulated real behavior)
• No real transactions - sandbox testing does not process payments, create orders, or affect inventory
• Professional plan required - SP-API access requires a Professional seller account ($39.99/month)
• Developer registration - access through Seller Central > Apps & Services > Develop Apps
• Amazon Pay Sandbox - separate environment for testing payment integrations
• Replaces FPS Sandbox - the original Flexible Payments Service Sandbox was discontinued in June 2015
• Not required for most sellers - the sandbox is for developers building custom integrations, not for general selling operations