Skip to main content

​
Troubleshooting: Türkiye SMS with a URL arrives stripped or empty

A recipient on a +90 number reports receiving nothing — or an empty message — while your send still reports submitted. Until 1 April 2026 that combination looked like a carrier-side anomaly; since Türkiye’s BTK Decision 2025/DK-YED/412 took effect it is a predictable, policy-driven strip: A2P SMS bodies that carry a URL, sent from a sender not registered domestically in Türkiye, have the entire payload stripped at delivery by the TR carrier. The send succeeds, the carrier accepts the traffic, and the handset gets nothing. This page matches the two markers Orbit surfaces for that gate — the tr_url_strip_warning advisory stamped on current message metadata, and the historical 422 MESSAGING_TR_URL_STRIP_VIOLATION reject older integrations may still reference — and ends each triage in one of the two workarounds you own as a tenant: move the link-bearing content onto MMS, or register a domestic TR sender.

​
What the failure looks like

  1. You send an SMS to a +90 destination whose body contains a URL — an http(s)://… link, a www. domain, or even a bare brand.com.
  2. POST /api/v1/messages/sms accepts the request and the status webhooks report submitted.
  3. The TR recipient’s handset receives an empty or missing message — the carrier stripped the payload in flight because the sender is not registered domestically in Türkiye.
The strip is a carrier-side delivery policy applied after the message leaves the platform, so nothing downstream of the send recovers it. The gate also never fires on TR-registered senders — a domestic TR sender clears the BTK check and the same body delivers intact.

​
Identify which marker you are seeing

Current integrations get a non-blocking advisory: the send proceeds, and the response stamps the advisory on the message metadata so your application can react to it:
The advisory fires only when all three hold: the destination resolves to TR (+90), the body contains something that looks like a URL, and the sender’s registered country is not TR. Read it on the send response (or the message’s later GET) — do not wait for the recipient complaint. Older integrations may instead reference the historical 422 reject MESSAGING_TR_URL_STRIP_VIOLATION, which refused the send outright. That fail-closed posture was replaced by the advisory above — if an older handler still hard-fails on this code, treat it as the same diagnosis and migrate the check to the metadata advisory.

​
Workaround A — move link-bearing content to MMS

The BTK rule targets SMS payloads. MMS bodies carry links differently, so moving the URL-bearing content onto the MMS channel clears the gate:
  • Send the message as MMS (with or without an attachment) instead of SMS for +90 destinations that must carry a link.
  • Keep plain-text SMS for +90 traffic without links — no domestic sender registration needed as long as the body carries no URL-like string (http(s)://…, www.…, or a bare brand.com-style token).

​
Workaround B — register a domestic TR sender

Register a sender domestically in Türkiye and the same SMS body delivers intact — the advisory stops stamping because the sender’s registered country is TR:
  1. Register the sender ID for Turkish destinations — the sender-identity flow on Register the sender ID covers the registration path.
  2. Once the sender’s registered country resolves to TR, +90 traffic from it clears the BTK check and URL-bearing SMS delivers intact.
Until either workaround lands, keep links out of SMS bodies destined for Türkiye.

​
What not to do

  • Do not keep burning SMS spend into stripped payloads. A submitted status on TR traffic whose body carries a URL is a spend sink, not traffic — the recipient never sees it. Treat an unexpected tr_url_strip_warning as a reason to stop and reroute, not to retry.
  • Do not assume carrier-side delivery when the status is submitted. submitted means the carrier accepted the message — it says nothing about handset delivery, and on this gate the strip happens after acceptance. Watch the metadata advisory on every +90 send.
  • Do not try to “disguise” the URL. The detection is deliberately permissive — www. prefixes and bare brand.com tokens count as URLs. Obfuscating the body buys a false positive the other way: the strip is still carrier-side, and the recipient still gets nothing.
  • Do not treat the older 422 reject as a current gate. The current send never hard-fails on this rule — it proceeds and stamps the advisory. Fix detection by reading metadata, not by catching MESSAGING_TR_URL_STRIP_VIOLATION.

​
Escalation bundle

Open a support ticket only when the advisory fires on a setup you believe is registered domestically, or the strip persists after both workarounds. Include:
  1. The message id of a stripped send and its full metadata.
  2. The destination number (E.164) and the sender ID sent.
  3. The sender’s registered country as it shows under Settings → Channels → SMS (or on the sender-registration record).
  4. Your organization ID (Settings → Organization, or organizationId from GET /api/v1/me).

​
See also