> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: Türkiye SMS with a URL arrives stripped or empty > Diagnose the Türkiye BTK URL-strip gate — the `tr_url_strip_warning` metadata advisory and the older `422 MESSAGING_TR_URL_STRIP_VIOLATION` reject — and fix it with one of the two tenant-owned workarounds: move link content to MMS, or register a domestic TR sender. # 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: ```json theme={null} { "metadata": { "tr_url_strip_warning": "Türkiye BTK 2025/DK-YED/412 — TR carrier may strip the URL when sender is not TR-registered." } } ``` 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](/troubleshooting/sender-id-not-registered) 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 * [Error code reference](/reference/error-codes) — the full `MESSAGING_TR_URL_STRIP_VIOLATION` row. * [SMS channel guide](/channels/sms) — the SMS send surface and status webhook shape. * [FAQ: Türkiye destination flagged with `MESSAGING_TR_URL_STRIP_VIOLATION`](/reference/faq) — the short-form answer this page expands. * [Register the sender ID](/troubleshooting/sender-id-not-registered) — the sender-registration flow workaround B depends on.