IOSOR

IOSOR Learn

Sender ID choice before the first campaign

Pick alphanumeric vs local DID sender before the first campaign brief — so coverage, hold, and failover plans match the identity you will actually send as.

Teams often lock creative and volume before they lock who the recipient will see. That is backwards. Campaign one starts with sender shape: alphanumeric brand string versus a local DID (or toll-free where required). Choose wrong and you burn prepaid on rejects, silent swaps, or registration waits missing from the launch calendar.

This page is the buyer choice before the first campaign — decide from-identity class while the brief is still editable.

IOSOR is white-label prepaid CPaaS. Fund the wallet, hold before debit, assign JIT numbers only when numeric sender is the honest path. Floor USD 20; soft review near USD 1,000/month is when a bad sender choice shows as unexplained burn. Stack: SMS API buyer checklist. Coverage: Check coverage before you quote volume. Money: Prepaid hold before first debit. Rails: Failover gates before any Live badge.

Choose sender type before you write the campaign brief

Before copy and volume annex: list every wave-one ISO; mark alphanumeric open, registration-gated, or blocked for your message class; decide if local DID (or toll-free) is required for two-way or STOP/HELP; only then freeze the visible from-identity. If sales promised one brand string everywhere, reopen the brief. A USD 20 pilot beats rewriting creatives after the first held send rejects.

Alphanumeric vs local DID: decision table for first launch

Need Prefer alphanumeric Prefer local DID / numeric
One-way OTP/alerts brand Open or registered alpha allowed Alpha blocked or silently swapped
STOP / HELP / two-way Corridor supports MO to that alpha Default for true two-way
Registration lead time Budget days/weeks if required JIT assign after hold when numeric

Pick the identity that can pass a held pilot with an honest terminal status.

Coverage and corridor constraints that force the choice

WORLD-only corridors may accept a pilot while alpha registration assumes a named zone. Align from-identity with destinations marked zone / WORLD / setup — Check coverage before you quote volume. If wave one mixes open and blocked alpha markets, split campaigns or senders.

Prepaid hold and failover are not sender decisions

Hold reserves prepaid before debit; it does not invent a registered sender. Failover Live proves ordered backup; it does not waive corridor registration. Keep lanes separate: Prepaid hold before first debit, Failover gates before any Live badge, and this sender choice.

Buyer checklist before the first campaign send

  1. Every wave-one ISO has an explicit alpha vs DID decision?
  2. Registration lead time (if any) written before go-live?
  3. Coverage sheet matches those destinations (Check coverage before you quote volume)?

Start with IOSOR

Open the IOSOR console and audit every target ISO planned for your first campaign wave against destination corridor sender restrictions. Assign either a registered alphanumeric identity or a dedicated local DID to each destination lane before finalizing your campaign brief. Ensure lanes requiring two-way interactions or compliance keywords have active numeric originators configured in route settings. Test routing status across all assigned originators to verify registration approval before triggering live traffic.

IOSOR takeaway

Locking your sender identity before payload creation prevents silent route overrides. Map every ISO to an approved alphanumeric ID or local numeric sender in the console, then export the ledger to confirm UTC timestamps.

Was this guide helpful?

Related guides