Buy phone numbers with an API: local numbers for your app

On Ready, you list a sub-account's numbers with GET /v1/numbers Buying one is two calls: POST /v1/numbers/checkout pays the first month on the saved card and returns a payment_intent_id, then POST /v1/numbers with that id provisions the number. Each number costs $2 a month on top of the registration that lets it send. That is the whole buy phone numbers API answer: one read call, two write calls, and a 10DLC registration behind them so the numbers actually deliver.

This post is for the CTO or head of product at a platform (a CRM, a vertical SaaS tool, a scheduling product) whose customers want to text their own customers from their own numbers. The API calls are simple. The parts that cost you time are deciding how many numbers each customer gets, handling the gap between "number bought" and "registration approved", and picking local numbers so local presence works. We cover each one, with the actual request shapes and the monthly math.

What "provisioning numbers for customers" means on Ready

Each of your customers gets a sub-account. A sub-account has its own phone numbers and its own carrier registration (brand plus campaign), so one customer's sending reputation stays separate from another's. You create sub-accounts with POST /v1/sub-accounts and list them with GET /v1/sub-accounts.

The order of operations for a new customer looks like this:

1. Create the sub-account (POST /v1/sub-accounts).
2. Buy one or more numbers for it (POST /v1/numbers/checkout, then POST /v1/numbers, both with the X-Sub-Account-Id header).
3. Submit the brand and campaign registration and poll its status (GET /v1/registration).
4. Send (POST /v1/messages or POST /v1/messages/bulk).

Steps 2 and 3 can overlap, and we explain below why buying the number first is often the better order. If you are earlier in the build and haven't wired sending yet, our SMS API integration walk-through covers auth, retries and webhooks end to end.

The buy phone numbers API: list, then buy

Every request carries your key in the X-API-Key header. For anything that creates or charges, send an Idempotency-Key header with a fresh UUID so a retried request after a timeout doesn't buy a second number.

Listing numbers

curl https://api.tryready.com/v1/numbers \
  -H "X-API-Key: $READY_API_KEY"

Use this to show a customer which numbers they already own, to check before buying (so a double-click in your UI doesn't become two numbers), and to keep your own database in sync with what's on the account.

Buying a number

First start the purchase. This pays the first month on the saved card and returns a payment_intent_id:

curl -X POST https://api.tryready.com/v1/numbers/checkout \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: 6f1c2a9e-4b7d-4e2a-9c1f-0d8e5b3a7c42" \
  -H "Content-Type: application/json" \
  -d @checkout-request.json

Then buy the number with that id:

curl -X POST https://api.tryready.com/v1/numbers \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: 3b8d1f40-7a52-4c19-8e6d-2f9a0c5b1e77" \
  -H "Content-Type: application/json" \
  -d @number-request.json

We're not printing the JSON body here on purpose. The fields for choosing a number (area code and the rest) are documented in the API reference at docs.tryready.com, and that page stays current where a blog post wouldn't. The quickstart walks through the first purchase and first send in order.

Two practical notes for your integration:

• Treat the purchase as billable. It is. Put it behind a confirm step in your UI, not on page load.
• Store the number against your customer record right after the call returns, and reconcile with GET /v1/numbers on a schedule. Drift between your database and the account is the most common source of "which number did this go out from?" support tickets.

One limit worth knowing if you're building agent tooling: Ready's MCP server at https://api.tryready.com/mcp can send texts, manage contacts and campaigns, and read billing, but it has no tools for buying numbers or registering. Number purchase stays in your REST integration, which is probably where you want a billable action anyway.

What a number costs, and what it costs to make it send

A number is $2 a month. A number alone doesn't get you deliverable texting, though. Carriers filter unregistered A2P traffic, so each sub-account also needs a 10DLC brand and campaign:

Replies are billed like sent texts: the same $0.0075/segment plus the carrier fee. Texts we refuse up front (opt-outs, numbers on your Ban list, known landlines) are not charged. A text held for the recipient's quiet hours is charged only when it actually sends. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused with 409 QUIET_HOURS_BLOCK and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.

Worked example: 40 customers, 3 numbers each

Assumptions: your platform has 40 customers, each on its own sub-account with one brand, one campaign and three numbers.

• Numbers: 40 × 3 × $2 = $240/month
• Registration: 40 × ($25 for registration) = $1,200/month
• Fixed monthly before any texting: $1,440, or $36 per customer

Now add texting. Say one customer sends 10,000 single-segment texts in a month. That's 10,000 × $0.0075 = $75 in Ready's rate, plus 10,000 × $0.0045 in carrier fee, itemized separately on the bill. If those texts carry an emoji and run past 70 characters, each becomes 2 or more segments and the cost doubles or more. Segment count is the number to watch in your rebill, not message count.

That per-customer amount is the line most platforms bake into their plan price. If a customer only needs one number, it drops to $27.

Where raw CPaaS is the cheaper route

Plainly: if all you need is the number and the pipe, Twilio's per-segment price (around $0.0083) is well below our $0.0075/segment, and other raw CPaaS APIs sit in similar territory. What you'd build yourself on top of those is the per-customer registration flow, sub-account isolation, opt-out propagation, quiet-hours holds and the number and scrub checks. If your team already has that built, raw CPaaS is a reasonable choice. Our Twilio comparison runs the math both ways.

Registration before sending: how the timing actually works

This is where most provisioning flows get stuck. A customer signs up, you buy them a number, and they want to text today. Registration doesn't finish today. Most approvals take 2 to 7 days.

Here's what Ready does during that gap:

• An account can send up to 500 texts a month before it registers, at its normal per-text rate. After that it has to register.
• An account that bought its number before registering sends on Ready's shared registration at the same per-text rate while its own registration is in review. So buying the number first, then submitting registration, gives the customer a working number during review instead of a dead one.
• The first 20 texts are free, and they're one-to-one sends. A campaign is paid from the first text. The free texts end the moment a registration is paid for, so tell customers to use them before registering, not to count on them afterward.
• To send, you add a card and get a number, which is $2 a month with the first month charged when you get it.

Poll GET /v1/registration to show status in your UI. A "pending, usually 2 to 7 days" banner beats a support ticket asking why nothing has changed in an hour. If a campaign comes back rejected, GET /v1/registration returns the carrier's reasons and a suggested fix. Correct those fields and send POST /v1/registration/:id/resubmit. It's almost always the sample messages or the use case, and this breakdown of approval timelines by step shows where the days go.

Numbers don't buy throughput

A common instinct is to buy more numbers to send faster. On registered 10DLC, the per-second rate is set per campaign: roughly 1 to 4 segments per second for a fresh standard campaign with no vetting, more for higher use-case tiers. T-Mobile's daily cap is set per brand by trust score, starting around 2,000 messages a day at the lowest tier. Adding numbers to the same campaign doesn't raise either. Buy numbers for geography and for separating use cases, not for speed.

Local numbers and local presence

The main reason to buy several numbers per customer is local presence: sending from the number closest to each contact's area code. A contact in Austin sees a 512 number; a contact in Denver sees a 720.

How it works on Ready

Local presence is on for every account by default: Ready texts each contact from the account's number closest to their area code. In the API you don't need to add anything to the send. Leave from out and Ready keeps the number the contact already texts with, otherwise the closest one:

curl -X POST https://api.tryready.com/v1/messages \
  -H "X-API-Key: $READY_API_KEY" \
  -H "Idempotency-Key: 0b9d4f61-2c3e-4a8f-b7d1-5e6a9c2f8e10" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+15125550142",
    "body": "Hi Dana, your cleaning is confirmed for Thursday at 9 AM. Reply C to confirm or R to reschedule.",
    "consent_attested": true
  }'

Pass from_strategy even or random only to spread new conversations across the account's numbers. Or pass from with a specific number to pin it. For bulk sends, POST /v1/messages/bulk takes an array in to with the same body and consent_attested (bulk docs).

On GoHighLevel, the #from:local# tag does the same thing, and #from:rotate# spreads new contacts across numbers inside the local area-code group. Either way, a contact keeps the number it already texts with, so conversations don't jump between senders.

What it costs

Local presence has a listed price of $0.0015 for each segment of a delivered text. Each extra local number you buy a customer is $2/month.

What it doesn't do

Every number still sits on the account's registered 10DLC campaign. Local presence chooses among registered numbers; it doesn't get around registration. We don't publish a measured reply-rate lift from it. It is on by default because a local area code looks like a business the contact recognizes, and that's a reasonable bet, not a guarantee. Rotating many numbers aggressively to dodge filters is a different thing, and it backfires. Here's how that goes wrong.

How many local numbers to buy

A sensible starting rule for a customer: one number per metro where they have a meaningful share of contacts, and no more. A plumber in one city needs one. A multi-location dental group across three states might need three to five. Each costs $2/month, so a quick query of contacts by area code before you buy is worth more than buying ten "just in case".

Sending responsibly from the numbers you bought

The number is yours to provision; the consent is your customer's to collect. consent_attested: true on every send is your promise that the recipient agreed to texts. Ready records that attestation per bulk send and per API send that sets consent_attested (who sent, to how many, when). That's an audit trail of the send, not a per-contact consent record, so your platform or your customer's store needs to keep the opt-in time, wording and page.

Things handled for every sub-account automatically:

• STOP and UNSUBSCRIBE are honored and the opt-out propagates, so that contact can't be texted again across campaigns. Read them with GET /v1/opt-outs.
• Quiet hours hold sends outside permitted local hours, based on the recipient's area. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused with 409 QUIET_HOURS_BLOCK and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.
• Optional checks: GET /v1/validate/:phone for number validation, and GET /v1/scrub/:phone or the scrub setting for TCPA-litigator and DNC screening.

These reduce risk; they don't move compliance responsibility off the sender. Cold contact belongs on phone and mail. SMS goes to people who opted in or replied.

The practical takeaway

Buying numbers by API is the easy part: GET /v1/numbers to see what's there, POST /v1/numbers/checkout then POST /v1/numbers, each with an idempotency key, to buy, $2 a month each. The work is in the flow around it. Create the sub-account, buy the number before registration so the customer can send on shared registration during review, poll GET /v1/registration, and buy extra local numbers only where contacts actually cluster.

If you want to try it, sign up, grab a test key, and run the quickstart against one sub-account before you wire it into your onboarding.

FAQ

Can I buy phone numbers through an API?

Yes. On Ready you buy a number with POST /v1/numbers/checkout then POST /v1/numbers and list existing ones with GET /v1/numbers. The request body for choosing a number is in the API reference at docs.tryready.com.

How much does a business phone number cost per month?

On Ready a number is $2 a month. To send A2P texts reliably it also needs 10DLC registration, which is $25/mo for registration, so one customer with one number runs $27 a month before texting.

Do I need 10DLC registration before I can text from a new number?

Yes, for ongoing sending. On Ready an account can send up to 500 texts a month before registering, and an account that bought its number first sends on Ready's shared registration while its own is in review. Most approvals take 2 to 7 days.

Does buying more phone numbers increase how fast I can send?

No. Send rate is set per 10DLC campaign and daily caps per brand, so adding numbers to the same campaign doesn't raise either. Buy numbers for local coverage or to separate use cases.

What is local presence texting and does it cost extra?

Local presence sends each text from your number closest to the contact's area code. On Ready its listed price is $0.0015 for each segment of a delivered text. Every number still has to be on the account's registered campaign.