Skip to content
API integration

Plan an API workflow for receiving SMS

The API connects your application to the account’s number-order workflow. It receives verification messages sent by another service; it is not an API for sending your own verification campaigns. Start with the API reference for exact endpoints and request formats.

Keep authentication on a trusted server

Manage API credentials through the account and send them only as documented. Do not embed a secret in a public web page, mobile bundle or source-control repository. Treat logs, screenshots and support messages as possible places a credential could leak.

Use your server to coordinate account operations and return only the information your client needs. If a key may have been exposed, use the account’s available key controls and update the integration before continuing.

Resolve the app, country and current offer

Use the documented catalog to select the exact service and country identifiers. Display names are for people; avoid guessing identifiers from the text shown on a page. Keep catalog discovery separate from the purchase action.

Check the current price and available options before ordering. A cached catalog response is not a reservation, and a prior successful request does not guarantee that the same stock remains available. Handle changed quotes and unavailable routes as expected outcomes.

Treat purchase as a state-changing operation

Save the returned order identifier and associate it with your own workflow before allowing another purchase. Guard your interface against duplicate clicks. Do not automatically repeat a purchase because the browser is slow or a response is ambiguous.

On a timeout or connection error, reconcile the account’s orders and balance using the documented read operations. Confirm whether the first request created an order before retrying a state-changing action. Use only idempotency or retry controls explicitly documented for the endpoint.

Track states until the order is resolved

An accepted purchase is not the same event as a delivered SMS. Track the order through its waiting, delivery or expiry states and show those distinctions in your interface. Stop waiting when the order reaches a final state, and remember the order window is 20 minutes.

Use the supported status-retrieval mechanism in the API reference and respect documented request limits. Customer webhooks are not self-serve, so poll the order status. You can cancel an open order once 2 minutes have passed and no code has arrived, and the charge is credited back to your account balance. Asking for another SMS and finishing an order early are not available.

Reconcile balances and handle codes carefully

After a purchase or a balance credit for an expired order, read authoritative account and order data instead of relying only on a local subtraction. This matters when several purchases or devices use the same account close together.

Keep verification codes out of routine analytics and public logs. Record the order ID and operational outcome for troubleshooting, while limiting access to message content. Test failure states as well as successful delivery before connecting a production workflow.

Take the next step

Compare the listed app and country prices or open the API reference for integration details. For an existing order, contact support with its order ID.

Continue reading