How to Test the Twilio API with Postman When You Don't Have a US Phone Number

The Problem

I was integrating Twilio's Verify API into a project — implementing SMS-based two-factor authentication for a client application. The implementation was done. I needed to test it end to end.

Twilio's dashboard and sandbox environment require a verified phone number to send test messages to. I'm based in Germany. I don't have a US number. The numbers I did have weren't being accepted in the verification flow, and Twilio's free trial restricts outbound messages to verified numbers only.

The frontend of the application I was testing had its own phone input that expected a specific format. There were three blockers stacked on top of each other — and none of them were actually about whether the Twilio API integration I'd written was correct.

The solution took about ten minutes once I remembered a principle I've applied repeatedly: the UI is just one way to talk to an API. When the UI has restrictions, the API itself usually doesn't.

What You Need Before You Start

From the Twilio Console you need two things:

• Account SID — visible on the main dashboard, starts with AC
• Auth Token — next to the Account SID, click to reveal

If you're testing Twilio Verify specifically, you also need a Verify Service SID — create one under Verify → Services in the console. It starts with VA.

Twilio authenticates every API request with HTTP Basic Auth. The username is your Account SID. The password is your Auth Token. Postman handles this natively — no custom headers needed.

Setting Up Postman

Open Postman and create a new request. In the Authorization tab, select Basic Auth and enter:

• Username: your Account SID (ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
• Password: your Auth Token

That's the entire authentication setup. Every Twilio REST API request uses this same pattern regardless of which endpoint you're hitting.

Sending an SMS

To test basic SMS sending, set the request to POST and use this URL — replacing the Account SID in the path:

https://api.twilio.com/2010-04-01/Accounts/ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Messages.json

In the Body tab, select x-www-form-urlencoded and add these key-value pairs:

From    +1XXXXXXXXXX          (your Twilio number)
To      +49XXXXXXXXXX         (any number you want to test with)
Body    Your test message here

Hit Send. A successful response returns HTTP 201 with a JSON body containing the message SID and a status of queued. Twilio will deliver the message to the To number regardless of where that number is in the world — the geographic restriction on free trial accounts applies to the Twilio number you send from, not the destination.

Testing Twilio Verify

Verify is a two-step process: send the code, then check the code. Both steps are separate API calls, and both work identically from Postman regardless of your location.

Step 1 — Send the verification code:

POST https://verify.twilio.com/v2/Services/VAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Verifications

Body (x-www-form-urlencoded):

To         +49XXXXXXXXXX    (the number to send the code to)
Channel    sms              (or 'call' for voice verification)

A successful response returns status: "pending". The code will arrive at the destination number via SMS.

Step 2 — Check the verification code:

POST https://verify.twilio.com/v2/Services/VAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/VerificationCheck

Body (x-www-form-urlencoded):

To      +49XXXXXXXXXX
Code    123456            (the code received in the SMS)

A successful verification returns status: "approved". A wrong or expired code returns status: "pending" with an error. This is exactly what your application backend should be checking when a user submits their code.

Inspecting the Response to Validate Your Integration

The real value of running these requests through Postman isn't just that they work — it's that you can see exactly what Twilio returns and verify your backend is handling it correctly.

For a .NET integration using the Twilio C# SDK, the Postman response gives you the exact JSON shape your code will receive. If your application checks verification.Status == "approved" before granting access, you can confirm that string matches what the API actually returns before writing a single unit test.

It also lets you test the failure paths cleanly. Send an incorrect code intentionally. Send an expired code. Send a request without the Auth Token. Each failure mode returns a different error structure — and knowing those structures before they happen in production means your error handling is tested against real Twilio responses, not assumptions.

Using Environment Variables in Postman

Once the requests are working, store the credentials in a Postman environment rather than pasting them into each request. Create an environment with these variables:

TWILIO_ACCOUNT_SID     ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TWILIO_AUTH_TOKEN      your_auth_token
TWILIO_VERIFY_SID      VAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TWILIO_FROM_NUMBER     +1XXXXXXXXXX

Then reference them in your requests with double curly braces:

https://api.twilio.com/2010-04-01/Accounts/{{TWILIO_ACCOUNT_SID}}/Messages.json

This lets you switch between test and production credentials by switching environments, and it keeps credentials out of any collection you might share with a team.

The Broader Point

Twilio's API doesn't know or care that you're in Germany. Neither does any other REST API. Geographic restrictions, phone number requirements, region-locked dashboards — these are frontend constraints. The API itself accepts authenticated HTTP requests from anywhere in the world.

Postman is the fastest way to get to the API layer directly when the application's own interface is blocking you. No US phone number required. No VPN. No waiting for a workaround. Just the Account SID, the Auth Token, and the endpoint from the documentation.

If you're implementing any Twilio product — Verify, Messaging, Voice, or Lookup — test the API calls in Postman first, before wiring them into your application. You'll understand exactly what you're integrating before you write a line of code, and you'll have a set of working requests you can run again any time you need to verify the integration is still behaving as expected.