​

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; this page picks up where it stops, at “fix the issue and re-submit.”

​

How the statuses move

Each country entry on a Sender ID walks one path: pending → approved → (rejected | expired) → re-submit → 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:

​

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:
   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:
   {
     "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:
   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.

​

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:
   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:
   {
     "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 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:
   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.

​

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 read-back carries stale entries that make the active set harder to scan.

​

When to escalate

Escalate to 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 — the lifecycle: register, list, and read the status per country
• Country Compliance Requirements — which markets gate on registration and what documentation they expect
• KYC Documents & the Compliance-Profile Lifecycle — upload the doc_… IDs your registrations reference, and renew them before they age out
• Troubleshooting: 10DLC campaign rejected — the US 10DLC equivalent, where the verifier is a registry rather than a carrier queue