Twilio Error 30034: Why Voice Agent Texts Fail Silently

Last verified November 5, 2026, against Twilio's own error 30034 page, changelog, support and developer docs, each linked where used below. Not legal advice. This post does not cover evading carrier filtering. The fix for 30034 is registration.

Your voice agent books the table, says "you'll get a confirmation text in a moment", and ends the call. The booking is real. The text never reaches the phone. Nothing on the call looks wrong, and no one sees it until a customer calls to ask where it is.

Twilio error 30034 is one way to produce that failure. Searches for "Twilio 30034" usually end at a list of Twilio SMS blocked fixes. For a voice agent text confirmation, the fix is only half the job. This post covers what Twilio's pages say about it, why a voice agent hits it silently, how to catch it from status callbacks, and what the agent should say when the text fails. For the full set of systems a voice agent writes to, see our integrations pillar. This post stays on one boundary: the confirmation text.

What Twilio error 30034 means

Twilio's error page is titled "US A2P 10DLC - Message from an Unregistered Number". It describes a block on messages to US numbers sent from a +1 10DLC number that is not tied to an approved A2P 10DLC Campaign.

The page lists four causes, which I restate here:

1. The sending number is not associated with an approved Campaign.

2. Brand or Campaign registration is incomplete.

3. The number is not in the Sender Pool of the Messaging Service linked to the approved Campaign.

4. Several +1 10DLC numbers were added to a Sole Proprietor Campaign, and only one can be registered.

Twilio's A2P 10DLC overview states the rule plainly: "Anyone sending SMS/MMS messages over a 10DLC number from an application to the US must register for A2P 10DLC." A text that a voice agent sends after a call is application-generated traffic. It falls inside that rule.

Three terms matter for the rest of this post.

• Brand: who is sending. Carriers use it to check the sender is legitimate.
• Campaign: the use case, plus how users opt in, opt out and get help. Twilio's onboarding guide gives order confirmations as an example use case.
• Messaging Service and Sender Pool: the container that links your numbers to one Campaign. A number outside the pool is outside the registration.

When the block started

This is not a new rule. Twilio's July 5, 2023 changelog announced gradually increasing blocking of unregistered traffic. Its September 1, 2023 changelog says: "Messages sent to the U.S. using unregistered +1 10DLC numbers will be blocked." Twilio's support article says unregistered messages "will be fully blocked effective September 1st, 2023".

That history matters for one reason. If your team inherited an unregistered 10DLC number, or built the agent after the cutover, a missing registration is a setup gap. It is not a Twilio outage.

What Twilio's pages say about cost and workarounds

Two statements from Twilio's support article change how you plan.

• "Twilio messaging rates will still apply to blocked messages."
• "There will not be a way to prevent the full block on unregistered traffic."

The same article says "'In Progress' Campaign registrations will be included in the blocks". A Campaign that is merely submitted does not protect you.

So a blocked confirmation still costs money, and you cannot talk your way past it at send time. Twilio's error page does name sender types outside A2P 10DLC (a Toll-Free number, a short code, or Twilio Verify for verification use cases) as options if you must send before registration finishes. I did not open the requirements for those, so check each before you plan around one.

Why a voice agent fails silently on this error

A voice agent is not a form. The caller is still on the line when the text tool runs, and the agent speaks before the outcome is known.

Twilio's Message resource page describes `queued` as the state where a message waits to go out, and `delivered` as the state where Twilio got delivery confirmation from the carrier. A message therefore passes through several states before an outcome exists. Twilio's status callback guide says callbacks are separate HTTP requests whose order is not guaranteed. The pages I opened do not say whether 30034 shows up at send time or only in message status. Design for the later case.

Put those together and the failure path looks like this:

1. Caller finishes booking. The agent calls your `send_confirmation_sms` tool.

2. The tool calls Twilio and returns "ok" because the request was accepted for sending.

3. The agent says "I've sent your confirmation". The call ends.

4. The message is blocked with error 30034. A callback reports it, if you set one up.

5. Your record still says `confirmation_sent = true`.

Step 5 is the damage. The write-back recorded an intent as an outcome. Our post on post-call write-back testing covers that class of bug in general. This is a concrete case of it.

What Twilio does not tell you

I could not find a Twilio page that says which terminal status a 30034 message ends in. The Message resource page says ErrorCode appears when the status is `failed` or `undelivered`, and the status callback guide says the same for callbacks. So treat both as failure. Per the same page, `undelivered` means Twilio received a delivery receipt saying the message was not delivered.

The Message resource page also carries a warning. It says the value for a given cause "is subject to change as Twilio improves errors" and that "Users should not use the `error_code` and `error_message` fields programmatically." Your design should respect both halves:

• Decide success or failure from `MessageStatus`.
• Use `ErrorCode` for alert routing and for the human who debugs, and store the raw value.

Do not branch your call logic only on the string "30034".

How 30034 differs from 30007 and 21610

Three codes get confused in support threads. They have different owners, so they need different fixes.

The 30007 page tells you to gather three or more Message SIDs with `undelivered` status and error 30007 before contacting Support. The error 21610 page lists the recipient replying with STOP or another opt-out keyword as a cause. Twilio's Advanced Opt-Out tutorial says later sends to that user fail with 21610, returned asynchronously.

A registered number can still hit 30007 or 21610. A 30034 means the registration chain itself has a gap. Do not use one fix for all three.

What A2P 10DLC registration status means for your numbers

Twilio's onboarding guide gives the chain: a Customer Profile, a Brand, a Messaging Service holding at least one 10DLC number, then a Campaign. A Messaging Service links to only one Campaign at a time. A Brand can have up to five Campaigns.

Timing matters for a launch plan, per the same guide:

• Brand registration review can be manual and takes seven business days or more.
• Standard use-case Campaigns take up to five business days, and Twilio says to contact Support if one is still in progress after 10 days. (Twilio's 2023 support article said review took at least three weeks. The pages disagree, so plan on the slower figure.)
• Some Campaign use cases need an extra carrier review before approval, and a number's own registration can still take several days after that.

Twilio's phone-number troubleshooting page lists number statuses. As of November 2026 they include `REGISTERED`, `PENDING_REGISTRATION`, `UNREGISTERED`, `FAILURE` and `PENDING_DEREGISTRATION`. It says a number must be in a Messaging Service linked to a verified Campaign to register. It also says registration of a number can take several days.

For a voice-agent team, the lesson is blunt. Registration is a release dependency, not a back-office task. A new customer's number is a new thing that must pass before the text feature works for them.

The multi-tenant trap

Many multi-tenant teams do not run one number. A vertical SaaS vendor may give each customer location its own. Three of Twilio's four causes become tenant-onboarding bugs at that scale:

• The new location's number was bought but never added to the Sender Pool.
• The Campaign was approved for the old numbers only.
• A Sole Proprietor Campaign was reused, and only one number registered.

On that last one, Twilio's troubleshooting page says that if the Messaging Service holds several numbers, Twilio registers one at random. To pick a specific number, it says to "remove ALL numbers in the Messaging Service" and add back only the one you want. The other numbers show as `UNREGISTERED`.

A worked example: why the global rate hides the problem

This is an illustrative example, not data from any company. Assume a platform with 120 customer locations, each with its own number. Each location sends 30 confirmation texts a day.

• Daily confirmations: 120 x 30 = 3,600.
• Assume 9 numbers were never added to the Sender Pool.
• Blocked per day: 9 x 30 = 270.
• Global failure rate: 270 / 3,600 = 7.5%.

A 7.5% blended rate can look like noise. On those 9 numbers the rate is 100%. Every one of their callers was told a text was coming. Alerting on the blended rate misses it. Alert per sending number, and alert when any number has zero `delivered` callbacks over a window you choose.

Twilio's pages add a limit to watch separately. Its A2P 10DLC overview lists daily segment limits by Brand type, and the only carrier it names for those figures is T-Mobile. For Sole Proprietor Brands it gives 1,000 SMS segments and MMS per day to T-Mobile. Segments, not messages, are the unit. The pages I opened do not say which error code appears when a cap is hit, so do not assume it is 30034.

How to detect and handle 30034 in your voice agent

Twilio's status callback guide says to pass a `StatusCallback` URL on each message, or to set a Delivery Status Callback on the Messaging Service. It lists these form fields: `MessageSid`, `MessageStatus` and `ErrorCode`. It also says your endpoint should return HTTP 200 and that you should use the SDK's signature validation rather than writing your own.

Below is simplified pseudocode. The field names come from the guide. The store and framework calls are placeholders you adapt.

# Simplified pseudocode. Not SDK syntax: adapt to your framework and
# validate X-Twilio-Signature with your Twilio SDK before trusting the form.
FAILED = {"failed", "undelivered"}
RANK = {"queued": 1, "sending": 2, "sent": 3, "delivered": 4,
        "undelivered": 4, "failed": 4}

def on_status_callback(form):
    sid, status = form["MessageSid"], form["MessageStatus"]
    code = form.get("ErrorCode")          # present on failed/undelivered
    row = store.by_message_sid(sid)       # saved when the send tool ran
    if row is None:
        return 200
    if RANK.get(status, 0) < RANK.get(row.status, 0):
        return 200                        # callbacks can arrive out of order
    store.update(sid, status=status, error_code=code)
    if status in FAILED:
        store.mark_call(row.call_id, confirmation_sent=False)
        alerts.fire("confirmation_text_failed",
                    number=row.from_number, code=code, call=row.call_id)
    return 200

The `RANK` guard exists because Twilio says callback order is not guaranteed. The `confirmation_sent=False` write fixes the record that step 5 above left wrong.

The steps

1. Store the message SID at send time. Save `MessageSid`, the sending number, the call ID and the tenant. Without the join you cannot tell which call a failure belongs to.

2. Set a Twilio status callback. Use the message parameter or the Messaging Service setting. Pick one place and test it, because Twilio sends to the message-level URL if both exist.

3. Write intent, not outcome. Store `confirmation_requested` at send time. Set `confirmation_delivered` only on a `delivered` callback.

4. Classify on status, label on code. Any `failed` or `undelivered` is a failure. Route `30034` to the registration owner, `21610` to opt-out handling and `30007` to content review.

5. Alert per number. Page when a number has sends but no deliveries in your window.

6. Run a registration pre-flight on every new number. Check the Sender Pool and Campaign link before the number takes calls. Block the text tool for numbers that fail the check.

7. Give the agent a fallback script. See the next section.

What the agent should say when the text fails

A text can fail after the call ends, so the agent often cannot know. Two rules fix most of the damage.

Do not claim delivery you cannot see. Say "I'm sending a text to the number ending in 4-2" instead of "I've sent your confirmation". If your tool waits a short, tested interval for a first status, the agent can speak after it. Choose that interval from your own measurements. Twilio publishes no delivery time you can rely on in the pages I opened.

Carry the essential detail on the call itself. For a booking, read back the date, time and place before hanging up. If there is a code, read it with the pacing from our alphanumeric capture post. A text should be a copy of what was said, not the only record.

When a failure is known during the call, the agent needs a short path:

For opt-in language, remember the Campaign describes how users opt in and out. Twilio's overview says a Campaign describes how end users opt in, opt out and get help. Our recording consent post covers the separate question of what the agent must say about recording.

What to test before every release

This is where the voice agent and the SMS pipeline meet. The generic method is in our integration testing and workflow testing posts. Here is the 30034-specific list.

• Per-number send test. For each production number, send a test text through the same path the agent uses. Assert a `delivered` callback arrives for a handset you control. Run it after every change to the Messaging Service or Campaign.
• Unregistered-number test. In a non-production environment, use a number you know is not in the Sender Pool. Assert the agent does not say the text was sent and that the record stays `confirmation_delivered = false`.
• Slow-callback test. Delay the status callback in your test harness. Assert the agent's wording is still true when the call ends.
• Out-of-order callback test. Send `delivered` before `sent`. Assert the record keeps `delivered`.
• STOP test. Reply STOP from a test handset, then trigger another confirmation. Assert the agent and record handle the opt-out path, with no repeat sends.
• Cap test. Count segments, not messages, against the limit for your Brand type. Note that the pages I opened do not name the error for a cap.
• Tenant onboarding test. Provision a new tenant number in staging and assert the pre-flight blocks the text tool until registration passes.

Where Evalgent fits

Evalgent tests voice agents from the audio. It generates scenarios from your agent's prompt and flows, covering states, branches and policies, and runs simulated callers over phone, SIP or WebRTC. It can judge what the agent actually said after a failed text, such as whether it still claimed the message was sent.

It does not read your Twilio message logs. The delivery check stays in your own callback pipeline, and you force the failure with a stub of your send tool in a test environment. In production, Evalgent call monitoring flags tool-call failures and policy failures in the recordings you push to it, which can surface calls where the confirmation tool errored.

Work with Evalgent on your first agent setup if your team has no QA function today. Pair it with the registration pre-flight above, which only you can run. For the blast radius of a bad change across tenants, see voice agent blast radius. If texts are one of several external calls competing for limits, see voice agent API rate limits.

Related reading for reminder and confirmation agents

Confirmation and reminder flows hit this error more than most, because the text is the product. If you run them, see our posts on appointment reminder vendor evaluation, HVAC reminder calls and vet reminder calls. If your agent runs on Twilio telephony, LiveKit and Twilio outbound calling covers the voice side. Voice and messaging are separate Twilio products with separate registration rules.

Frequently asked questions

What does Twilio error 30034 mean?

Twilio blocked a message to a US number because it was sent from a +1 10DLC number not tied to an approved A2P 10DLC Campaign. Twilio's error page lists incomplete Brand or Campaign registration, a number missing from the Messaging Service Sender Pool, and multiple numbers on a Sole Proprietor Campaign as causes.

Does Twilio charge for blocked messages?

According to Twilio's support article and its September 2023 changelog, messaging rates still apply to blocked messages. So a voice agent that keeps sending confirmations from an unregistered number pays for texts nobody receives. Check your own Twilio billing for current rates, because this post does not cover pricing.

How to fix Twilio error 30034?

Complete Brand and Campaign registration, then add the sending number to the Sender Pool of the Messaging Service linked to the approved Campaign. Check the number's registration status afterwards. For a Sole Proprietor Campaign, keep only the one number you want in that Messaging Service. Twilio's error page gives these steps.

Twilio error 30034 vs 30007: what is the difference?

Error 30034 means the sender is not tied to an approved Campaign. Error 30007 means Twilio or a carrier filtered the message, often over content. 30034 is a registration gap you fix on your side. For 30007, Twilio suggests gathering several Message SIDs and contacting Support if you believe the message complies.

Why does my voice agent say the text was sent when it was blocked?

Twilio accepts a message into a queue and reports the outcome later through status. If the agent speaks and the record is written when the tool returns, both reflect intent, not delivery. Store the message SID, write delivery only on a `delivered` callback, and phrase the agent's line as "I'm sending" instead of "I've sent".

How to detect Twilio error 30034 on a live call?

Set a StatusCallback on each message, or a Delivery Status Callback on the Messaging Service. Twilio sends MessageSid, MessageStatus and ErrorCode, with ErrorCode present on failed or undelivered. Join the callback to the call by message SID, treat failed or undelivered as failure, and alert per sending number.

Can I send texts while 10DLC registration is pending?

Twilio's support article says "'In Progress' Campaign registrations will be included in the blocks", so a submitted Campaign does not protect you. Its error page names Toll-Free, short code and Twilio Verify as options if you must send before registration finishes. Check each option's own requirements first, as I did not open them.

What should a voice agent say when the text fails?

Say the text did not go through, then read the key details aloud, such as date, time, place and any code. Offer another channel your product supports. Do not blame the caller's phone. If the failure surfaces after the call, mark the record and start your own follow-up.

The bottom line

Twilio error 30034 is a registration failure that a voice agent can experience as silence, because the call often ends before the block is reported. Store the message SID, write delivery only on a `delivered` status, and give the agent honest wording for the case where the text never arrives.