A Developer's Guide to Automating SMS Verification with the Connect369 API

If you're integrating phone verification into your own product or internal tooling, the Connect369 dashboard is the wrong interface — you want the API. Here's the shape of a real integration, start to finish.

1. Get the right kind of key

Create a full-access API key for the one server-side process that actually purchases numbers, and a separate read-only key anywhere you only need to check balance or order status — a leaked read-only key physically can't spend your balance. Never embed either key in client-side or browser code.

2. Build and test against sandbox first

A sandbox key simulates the entire purchase-and-verify flow with a deterministic test code, no real wallet spend, and no dependency on live upstream stock. Write your integration end-to-end against sandbox before it ever touches a live key — this is also exactly what your CI pipeline should run against, so tests stay fast and free.

3. The core request flow

curl -X POST https://connect369.store/api/v1/numbers \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"country":"US","app":"whatsapp"}'

This returns an order with an assigned phone number. From there you have two options for getting the SMS: poll, or webhook.

4. Prefer webhooks over polling

Polling /api/v1/numbers/{id}/sms in a loop works, but it wastes requests and adds latency. Registering a webhook endpoint means you get pushed a signed payload the moment a code arrives — better latency, fewer requests, and it scales cleanly if you're verifying many accounts in parallel.

5. Always verify the webhook signature

Every webhook delivery includes an HMAC-SHA256 signature header computed over the raw request body using your endpoint's own secret. Recompute it on your end and compare before trusting the payload — this is the only thing standing between your system and a spoofed callback claiming a code arrived that never did.

6. Clean up after yourself

Cancel numbers you no longer need rather than letting them sit — unused balance on a cancelled order is automatically refunded to your wallet, so there's no cost to being tidy, and it keeps your active-orders list meaningful if you're building any kind of dashboard on top of the API yourself.

7. Respect rate limits

Each key tier has its own per-minute rate limit, returned via a Retry-After header on a 429 response. Back off and retry rather than hammering the endpoint — a sustained flood doesn't get you numbers faster, it just risks the key getting throttled harder.

That's the whole shape of it: sandbox first, full-access key server-side only, webhooks over polling, signature verification always, and let auto-refund and cancellation keep your wallet clean. From there it's just wiring the response into whatever your product actually needs to do next.