> ## 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: Sender-ID registration rejected or expired

> A country entry on your Sender ID shows rejected or expired, traffic to that market is blocked, you need it back to approved. Find the cause, fix the submission, and resubmit — either re-enters review as pending without losing the approvals you already hold.

# Troubleshooting: Sender-ID registration rejected or expired

Traffic to a destination country is gated, and the country entry on your
Sender ID reads `rejected` or `expired` instead of `approved`. Both states
are terminal: nothing moves the entry back to `approved` except a new
review. The fix for each is the same shape — find the cause for `rejected`
or time the window for `expired`, then re-submit — because the
`POST /compliance/sender-id-registrations` call is an upsert that resets
either state to `pending` without touching the approvals you already hold.
Registering in the first place is covered by
[Sender-ID Registration](/compliance/sender-id-registration); this page
picks up where it stops, at "fix the issue and re-submit."

<Note>
  Approvals and rejections are decided by the carrier or regulator in each
  country — Orbit submits your filing, syncs the verdict, and enforces what
  comes back. Lead times below are expectations, not guarantees.
</Note>

## How the statuses move

Each country entry on a Sender ID walks one path:

**`pending` → `approved` → (`rejected` | `expired`) → re-submit → `pending`**

| Status     | Where you are                                                                                   |
| ---------- | ----------------------------------------------------------------------------------------------- |
| `pending`  | Submitted and waiting on review. Do not treat a long wait as a rejection.                       |
| `approved` | Traffic is allowed. The entry carries `registered_at` and `expires_at`.                         |
| `rejected` | The reviewer declined the filing. Only a re-submission moves it — back to `pending`.            |
| `expired`  | The registration's validity window closed. Only a re-submission reopens it — back to `pending`. |

Two properties of the upsert make re-submission safe at any point:

* **Approved countries stay approved.** Re-submitting an `approved` country
  keeps the approval and only refreshes the documents, provider reference,
  and notes on file.
* **Scope is per country.** Re-submit the entry that needs it and nothing
  else: the call keys on `sender_id`, so include only the country entries
  you mean to change, or none at all to leave a registration untouched.

## Rejected — find the cause, fix, resubmit

A rejection is per country: a multi-country registration can hold
`approved` on one market and `rejected` on the next. Rejections typically
land on the identity or the evidence, not the mechanics of the call —
reviewers decline a filing for what it says. These are the causes that
account for nearly every rejection:

| Symptom                                       | Cause                                                                                                                                                                                                                                                                               | Fix                                                                                                                                                                                                                                                            |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sender ID refused for length or format        | The value breaks the 3–11 character rule or carries characters outside letters, digits, space, `-`, `_`. Regulators — ANATEL (Brazil), OFCOM (UK), AGCOM (Italy), BTRC (Bangladesh) — refuse sub-3-character senders outright; the 11-character ceiling is the GSM 7-bit hard limit | Re-submit with a corrected Sender ID. Anything over 11 characters, or carrying symbols like `&`, `<`, or accented letters, registers as a new `sender_id` row — the old entry stays on file and expires on its own                                             |
| Brand ownership questioned                    | The evidence does not prove the Sender ID is yours — a brand you own, or one the brand owner authorized you to use (common for agencies and resellers filing on a client's behalf)                                                                                                  | Upload a trade-name registration, trademark record, or a letter of authorization through the [document library](/compliance/documents-kyc), and re-submit with the new `doc_…` ID in `document_refs`                                                           |
| Use case or character set mismatched          | The declared use case in `notes` contradicts the sample content or the traffic pattern the carrier expects for that Sender ID — for example, a promotional filing on an ID that reads like a customer-care label                                                                    | Rewrite `notes` to describe the traffic you actually send (transactional, OTP, or marketing, naming the audience), and re-submit. Keep the Sender ID itself consistent with that use case across countries                                                     |
| Wrong or stale documents                      | The referenced documents have expired, name a different legal entity than the registration, or omit a document the market requires                                                                                                                                                  | Check the market's document list against [Country Compliance Requirements](/compliance/country-requirements), upload the replacement through the document library, and re-submit with the new `doc_…` IDs                                                      |
| Country asks for a pre-registered sender type | The market does not accept an alphanumeric sender for your sender class at all, or only accepts pre-registration from local entities                                                                                                                                                | Review the market's sender-type grid in [Country Compliance Requirements](/compliance/country-requirements). If alphanumeric is not accepted for your traffic, the fix is a different sender type — registering the same value again will not move the verdict |

### The resubmission, step by step

1. **Read the rejection against the failing country**, not at the
   registration level. List your registrations to confirm which country
   entry holds `rejected`:

   ```bash theme={null}
   curl https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \
     -H "Authorization: Bearer $ORBIT_API_KEY"
   ```

   Locate the entry by `sender_id` and `country` in the response. A
   `rejected` entry looks like:

   ```json theme={null}
   {
     "country": "BR",
     "status": "rejected",
     "document_refs": ["doc_abc123def456"],
     "registered_at": null,
     "expires_at": null
   }
   ```

2. **Fix the item the reviewer named.** Replace stale documents (upload
   the new file through `/compliance/documents` first — files are not
   uploaded here, only referenced), correct the Sender ID text, or rewrite
   the use-case `notes`. The table above maps cause to fix.

3. **Re-submit the corrected entry.** Same endpoint as the initial filing
   — it is an upsert keyed on `(sender_id, country)`, so send only the
   country entries you corrected:

   ```bash theme={null}
   curl -X POST https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \
     -H "Authorization: Bearer $ORBIT_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "sender_id": "MyBrand",
       "countries": [
         {
           "country": "BR",
           "document_refs": ["doc_9f8e7d6c5b4a"],
           "notes": "Retail brand, transactional + OTP use case — corrected brand-authorization evidence attached"
         }
       ]
     }'
   ```

4. **The entry re-enters review at `pending`.** Expect the same lead time
   as the original filing. Your other countries — including Brazil if it
   was approved on a different `sender_id` — do not move.

<Warning>
  Resubmitting a rejected body unchanged earns a faster second
  rejection. The fix has to land somewhere — the Sender ID value, the
  `document_refs`, or the `notes` — before the re-submit is worth the
  review cycle.
</Warning>

## Expired — renew before the window closes

An `approved` entry carries an `expires_at` timestamp. When that window
closes the entry flips to `expired` and send-time gates start blocking
traffic to the country within the next moments after expiry — there is no
grace period, and the renewal is the same upsert as a fresh submission.

1. **Read the expiry before it lands.** List your registrations and sort
   the `approved` entries by `expires_at`:

   ```bash theme={null}
   curl https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \
     -H "Authorization: Bearer $ORBIT_API_KEY"
   ```

   An entry nearing its window close reads:

   ```json theme={null}
   {
     "country": "BR",
     "status": "approved",
     "registered_at": "2026-06-05T00:00:00.000Z",
     "expires_at": "2027-06-05T00:00:00.000Z"
   }
   ```

2. **Start the renewal with the registry's lead time in mind.** Regulator
   and carrier queues that took days to weeks on the original filing take
   the same time on a renewal — begin while `expires_at` is still that
   lead time away, not the week of. If the market's rule level is
   `required`, an unrenewed expiry does not just risk blocking — traffic
   is held by the send-time gate until a new approval lands.
   [Country Compliance Requirements](/compliance/country-requirements)
   marks each market's level.

3. **Re-submit to renew.** The same call resets an `expired` entry to
   `pending`. Renewal is a good moment to attach current documents —
   reviewers can and do decline renewals on evidence that was valid when
   first filed but has since aged out:

   ```bash theme={null}
   curl -X POST https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \
     -H "Authorization: Bearer $ORBIT_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "sender_id": "MyBrand",
       "countries": [
         {
           "country": "BR",
           "document_refs": ["doc_abc123def456"],
           "notes": "Retail brand, transactional + OTP use case — renewal"
         }
       ]
     }'
   ```

4. **A renewal is a new review.** Treat it like the original: expect the
   same lead time, and do not assume approval is a formality because the
   first filing passed.

<Note>
  The `expires_at` value belongs to the country's registration entry,
  not to a global deadline. Entries expire independently per market and
  per Sender ID — a registration that covers BR and DE can renew one
  while the other still has months to run.
</Note>

## Track more than one Sender ID

Registrations are keyed on `(organization, sender_id)`, so your account
typically holds several — a renewal queue of markets for the brand ID,
plus older IDs still on file. A few practices keep that row set readable:

* **List first, per problem.** Use the list endpoint above and filter to
  the `sender_id` and `country` you are working before you re-submit. It
  catches the case where a second, forgotten registration holds the
  traffic gate you expected this one to hold.
* **Keep the Sender ID text consistent.** Re-submitting a country on
  `MyBrand` at a different length or casing — `My-Brand`, `MYBRAND` —
  creates a new registration with its own pending review, it does not
  correct the old one. Fix the text by naming the same `sender_id`
  verbatim.
* **Retire IDs you no longer use.** A `sidreg_…` row whose brand you have
  outgrown does not block traffic on its own — but leaving it unresolved
  means every [Sender-ID Registration](/compliance/sender-id-registration)
  read-back carries stale entries that make the active set harder to scan.

## When to escalate

Escalate to [support@devotel.io](mailto:support@devotel.io) when you have
fixed the item the rejection named and the next verdict still fails on
the same finding, or when an `expires_at` window is inside two weeks and
no renewal has finished review. Attach:

1. Your **tenant ID** (dashboard → Settings → Organization, or
   `organizationId` on `GET /api/v1/me`).
2. The `sender_id` and the failing **country code**.
3. The exact prior status response — the entry's `status`, `registered_at`,
   and `expires_at` from the list call — and what you changed on re-submit.

## See also

* [Sender-ID Registration](/compliance/sender-id-registration) — the
  lifecycle: register, list, and read the status per country
* [Country Compliance Requirements](/compliance/country-requirements) —
  which markets gate on registration and what documentation they expect
* [KYC Documents & the Compliance-Profile Lifecycle](/compliance/documents-kyc)
  — upload the `doc_…` IDs your registrations reference, and renew them
  before they age out
* [Troubleshooting: 10DLC campaign rejected](/troubleshooting/10dlc-campaign-rejection)
  — the US 10DLC equivalent, where the verifier is a registry rather
  than a carrier queue