CoinAPI previously discontinued its sandbox environments. Today, testing is done directly against production APIs using separate API keys, credits, and usage controls.
The change simplifies the testing process while giving developers access to the same endpoints and data structures they will use in production.
So, what does this mean if you're building or testing a CoinAPI integration today?
What Was the CoinAPI Sandbox Environment?
A sandbox API environment is a separate testing environment that lets developers test integrations without affecting production usage or live systems.
CoinAPI previously maintained separate sandbox environments for API testing. Maintaining parallel testing infrastructure, however, added operational complexity while many customers ultimately needed to validate their integrations against real production data and endpoints.
CoinAPI therefore moved away from separate sandbox APIs.
The recommended approach today is to use CoinAPI production endpoints with a separate API key for development or staging, while controlling and monitoring usage through the API BRICKS platform.
Why Did CoinAPI Discontinue the Sandbox?
The primary motivation was the complexity of maintaining separate infrastructure solely for testing purposes.
Running an independent sandbox alongside production APIs requires additional infrastructure, maintenance, monitoring, and product synchronization. At the same time, many customers preferred to develop and validate integrations using the actual production environment.
Using production endpoints also means developers test against the same API behavior, schemas, and market data they will eventually use in their applications.
This doesn't mean development and production workloads should be mixed.
Instead, use CoinAPI production endpoints for realistic API testing while keeping your own development or staging environment isolated.
How Should You Test CoinAPI APIs Today?
The recommended setup is straightforward:
CoinAPI production endpoints → real API testing
Separate API key → development/staging workload
API BRICKS Console → usage and account monitoring
Spend Management → budget controls and alerts
Customers can create separate API keys for development and testing, making it easier to separate these workloads from production integrations.
Use the API BRICKS Console to manage API keys, billing, Usage Credits, subscriptions, quotas, usage metrics, notifications, and other account settings.
Start With $25 in Free Credits
CoinAPI no longer uses a traditional free Market Data API plan.
Instead, new users can start with $25 in free credits to test supported API workflows before committing to larger usage.
A verified payment method and API key are required to unlock the credits.
Once those credits are used, you can continue with PAYG Usage Credits or move to a committed plan depending on your workload.
This makes it possible to test real production endpoints without maintaining a separate sandbox API.
Remember: Production API Testing Can Consume Credits
Because testing now happens against production APIs, your requests can consume credits according to the pricing rules of the product you're using.
That makes usage monitoring particularly important during development.
Start with small requests and gradually increase the workload once you understand its consumption.
For Market Data REST, for example, if an endpoint uses the limit parameter, every 100 returned data points generally counts as 1 REST Credit. If limit isn't used or isn't available, the API call generally counts as 1 REST Credit.
During testing, log the x-credits-used response header when available to understand how different requests affect your usage.
You can then monitor broader account usage through the API BRICKS Console.
Use Spend Management to Control Testing Costs
Testing against production endpoints doesn't mean development workloads should have uncontrolled spending.
API BRICKS Spend Management can help you control usage with tools such as:
- Daily credit tracking
- Customizable daily budgets
- Email threshold alerts
- Webhook notifications
- Automated enforcement of configured budget limits
This is particularly useful when testing automated applications that can generate requests without direct user interaction.
For example, a bug in a polling loop can create significantly more API traffic than expected. Budget controls and alerts give you another layer of protection while you develop.
How to Test CoinAPI Safely
A few simple practices make production-endpoint testing easier to control.
1. Create a Separate API Key
Use a dedicated API key for your development or staging integration rather than sharing the key used by a production application.
This makes workloads easier to separate and monitor.
2. Start With Small Requests
When working with REST endpoints that support limit, start with a small value.
Test your parsing, authentication, pagination, error handling, and storage logic before requesting large datasets.
3. Monitor x-credits-used
Log x-credits-used when the header is available.
Usage headers may not appear on every endpoint or response, so don't make your application dependent on them.
4. Monitor Usage in the API BRICKS Console
Use the Console for account-level visibility into usage, quotas, billing, API keys, and credits.
5. Configure Spend Management
Set appropriate budgets and alerts for your testing workload.
This is especially important when running unattended scripts, automated data pipelines, or applications with retry logic.
6. Cache Static Metadata
Don't repeatedly download assets, exchanges, symbols, and other relatively static metadata if your application can safely cache it.
This reduces unnecessary API usage during development.
7. Scale Only After You Understand Usage
Once you've measured how your integration consumes data and credits, you can decide whether PAYG or a committed plan is the better fit for production.
What About Creating Your Own Sandbox?
You can still isolate your application, but this is different from having a separate CoinAPI sandbox API.
For example, your development code can run inside:
- A local development environment
- A staging server
- A virtual machine
- A cloud development environment
- A separate containerized application
That environment can then connect to CoinAPI's production endpoints using a dedicated testing API key.
This isolates your code and development workflow while still letting you test against the real CoinAPI API.
The important distinction is that a VM or staging server does not create a separate CoinAPI API environment. API requests still reach production endpoints and can consume credits.
Transitioning an Older Sandbox Integration
If you have an older integration that previously relied on a CoinAPI sandbox, the current approach is to move testing to the corresponding production endpoints.
A practical migration process is:
- Create a dedicated development API key.
- Update your integration to use the current production endpoint.
- Start with small requests and limited datasets.
- Confirm authentication and response handling.
- Monitor credit consumption.
- Configure appropriate budgets and alerts.
- Increase request volume gradually once the integration behaves as expected.
Don't assume old sandbox behavior, URLs, limits, or test data exactly represent the current production API. Use the latest CoinAPI documentation when updating an older integration.
Moving Forward
For new integrations, start small.
Create a separate testing API key, use your $25 in free credits, monitor consumption in the API BRICKS Console, and configure Spend Management before increasing your workload.
Once you understand how your application uses CoinAPI, you can scale with PAYG Usage Credits or choose a committed plan that better matches your production requirements.
