Sandbox and Your First Request: Testing an Integration Without Charges

The first request to an unfamiliar API is almost always written by trial and error: a wrong header, a typo in a parameter, a stray space in a key. On a live environment, any of those can cost a charge or a wasted number. A test environment exists so trial and error costs nothing — here is the right order to check an integration, which requests are free, and the mistakes that ruin day one.

Why a test environment matters before live requests

Integrations rarely work on the first try, and that is not about skill — any unfamiliar system has details that only show up in practice: a date format, the case of a parameter, the order of arguments. A test environment grants the right to be wrong: a bad request there returns an error code instead of charging the balance or tying up a needed resource.

There is a separate reason: trust in the response format. Until a developer has seen a real server response — field nesting, data types, how errors are marked — code written from documentation alone is still a guess, and a test request turns that guess into a verified fact.

The right order for the first integration steps

A sensible sequence does not skip levels of complexity. Step one is getting an access key and confirming it is active, enough to isolate a key problem from a logic problem later. Step two is a simple request checking only authorization: a call to a reference method that needs no country, service, or amount. Success means the key and headers are correct, and the next question is content, not access.

Step three is looking at the actual response format: which fields come back, what each status code means, what an error looks like. This step is often skipped in favor of trusting the docs — a mistake, since a real response sometimes differs from the example in details that matter for your handling logic. Only once all three are done should you move to methods that spend money: requesting a number, buying an activation, reserving a channel.

Which requests are free and which get billed

Reference methods — the list of countries, available services, current prices per direction — are usually free and unlimited within reason: a catalogue, not an action. Checking an activation's status or the account balance also costs nothing — reading state, not changing it. Charges happen where the system reserves a resource: a number request, an activation, a rental extension, a channel purchase — money leaves the balance regardless of the outcome. Check the free-versus-billed boundary against the API documentation before the first live call, rather than discovering it through accidental charges.

Typical day-one mistakes

The most common and expensive mistake is a live key that ends up in the test environment by accident: a developer copies the docs example, swaps in their own key without a second look, and the first test run charges the live balance. Separating keys between environments is covered in test data: how to avoid creating live accounts on staging.

The second mistake is requesting a number again in a loop with no delay: poorly designed logic requests a new number immediately instead of pausing and limiting retries. Each attempt on a bad direction gets billed again, and the total cost climbs far above a single attempt's price — covered in hidden costs: cancellations, retries and idle time.

The third mistake is missing failure handling: code written only for the happy path cannot tell "the code has not arrived yet" apart from "this direction is unavailable" or "the key is blocked," and either hangs or bombards the API with repeated requests instead of branching on the failure type.

What to write down before going live

Before the first live call, write down four things: which key belongs to test and which to production, confirmed not to overlap; which methods are billed, based on your own verification, not memory; a reasonable pause and retry count between failed attempts, not an endless loop; and a spending cap on the key in case retry logic still fails somewhere. Setting a daily and monthly cap is covered in team limits: how to cap spending.

Frequently Asked Questions

Can the whole flow be tested without spending money?

Checking the key, authorization, and the response format — yes, entirely free. Getting a number requires at least one billed call, worth taking only once everything else is checked.

What is the fastest way to tell a key is pointed at the wrong environment?

Make one simple, free request and compare the balance before and after: if it changed, the key is pointed somewhere unexpected, and further calls should stop.

How many times should a request be retried if the code never arrives?

A reasonable default is one retry after a pause, not an endless loop after the first timeout: a second attempt smooths over a one-off delay, while a consistent failure means the direction is the problem, not bad luck.

The full list of methods, response codes, and limits is in the API documentation on turbon.rent, along with which calls are free and which draw from the balance.