SMS Verification API Guide
By SMSOTPS Support Team
This guide is a starting checklist for the SMSOTPS developer API, not a replacement for the current endpoint reference. Use the linked API documentation for provider-specific fields and responses. Ordering numbers can spend account balance, so start with read-only checks and review the request before creating an order.
1. Start with the current documentation
Open API documentation and select the provider you intend to use. The published reference uses the base https://api.smsotps.com/api/ and the developer header X-API-KEY. Do not substitute an undocumented /v1/activations route or assume a dashboard session token is the same as a developer key.
2. Keep the developer key on your server
Treat the API key as a secret. Do not put it in a public frontend bundle, repository, screenshot, support message or URL. Load it through your server's secret configuration and redact it from logs. Use the documented key-management controls if it needs to be replaced.
3. Begin with a read-only balance request
The reference documents GET /api/balance with X-API-KEY. Use a placeholder in shared examples and your own key only in your server environment. A successful read checks that request, not the full order lifecycle; this article does not claim an authenticated end-to-end test.
4. Inspect offers before creating an order
Use the provider's current country, service and offer references. Do not hard-code an illustrative country or service ID as a universal value. Confirm availability, provider, selected offer and the displayed cost before using the documented POST /api/order-number route. Order creation is not a harmless connectivity test.
5. Track the returned order, not an invented ID
Keep the actual order identifier returned by the API. The reference documents GET /api/number-status/{id}. Follow the documented response for your provider, use bounded retries and stop at a terminal state. Do not invent a polling interval, webhook contract or idempotency guarantee that the reference does not provide.
6. Handle failures without duplicating paid requests
Separate validation and authentication errors from network timeouts. A timeout after submitting an order leaves the outcome uncertain; inspect order history or ask support before blindly repeating creation. Keep safe diagnostic details such as the request time and order ID, but redact keys and received codes.
7. Review cancellation separately
Cancellation and resend routes are not permission to assume an order is refundable or eligible for another code. Check the current FAQ, refund policy and provider-specific API instructions before acting. This guide does not change order rules or promise a refund.
Integration handoff checklist
Before production use, confirm the selected provider, request and response fields, secret storage, spending controls, timeout handling and terminal-state behavior. For help, contact support with a redacted error and order ID. Never include a real API key or OTP.
Common questions
Which authentication header does the published developer reference use?
The SMSOTPS API reference uses X-API-KEY for developer requests. Follow the current documentation rather than copying a dashboard session token.
Can I test integration by repeatedly creating orders?
No. Order creation may spend balance. Start with documented read-only checks, and inspect uncertain outcomes before retrying a paid request.
Does this guide promise a working webhook or fixed polling interval?
No. Use only the contracts documented for the selected provider. This article does not claim an authenticated end-to-end order test.
Related articles
E.164 Phone Number Format Explained For number formatting: country codes and common E.164 input mistakes. 
What Is an OTP? One-Time Passwords Explained For first-time readers: verification codes and their expiry timers. 
How to Find a Phone Number's Carrier For checking a number: carrier lookup, network information and line type.