Agents

On RCS the thing your message comes from is an agent — a verified entity with a name, a logo, a colour and a bot id, approved by us, by the provider, and by the carriers. It is what the recipient sees at the top of the conversation.

There is no sender ID on RCS. That is an SMS concept: a string you register and put in the source address. Passing a name RCS has never heard of does not produce an unapproved message, it produces no message at all.

Do not reuse your SMS sender ID here

They are separate identities, registered and approved separately. An SMS sender ID that has been live for years grants nothing on RCS, and the reverse is also true. If your brand sends on both channels you need both, and they may not even be spelled the same.

What you send under

The agent field on every send is the name of an agent allocated to your account. Two things have to be true for it to work:

Allocated to you

An agent is assigned to your account. One verified agent can be shared by several accounts — that is normal, and how OTP agents are usually run.

Approved and live

Its status is approved. Anything else — registered, pending, rejected — cannot send, whatever else is configured.

Allocation is the permission. There is no second approval step and no separate name to register: if an approved agent is allocated to you, you can send as it; if not, you cannot. A send naming an agent you do not hold is refused before you are billed.

See what you can send as

GET/ng/v1/rcs/agents

The cheapest pre-flight check there is — every agent on your account and where it stands:

curl https://api.9bits.net/ng/v1/rcs/agents \
  -H "Authorization: Bearer $NINEBITS_RCS_KEY"

Anything whose status is not approved will be refused at send time, so this is the list to check before wiring a name into your code.

Onboard a new agent

POST/ng/v1/rcs/agents/onboard

curl -X POST https://api.9bits.net/ng/v1/rcs/agents/onboard \
  -H "Authorization: Bearer $NINEBITS_RCS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "brand_name": "First Digits",
    "bot_name": "FirstDigits",
    "bot_summary": "Order and delivery notifications for firstdigits.com customers.",
    "agent_msg_type": "TRANSACTIONAL",
    "billing_category": "BASIC_MESSAGE",
    "lang_supported": "en",
    "region": "NG",
    "agent_color": "#0B5FFF",
    "privacy_url": "https://example.com/privacy",
    "term_and_condition_url": "https://example.com/terms"
  }'

The agent comes back registered. It becomes approved — and therefore sendable — only once the provider and the carriers have cleared it, which is a human process measured in days, not minutes. Poll GET /ng/v1/rcs/agents, or watch it in the portal.

Write a real `bot_summary`

A reviewer reads it. “Order and delivery notifications for firstdigits.com customers” gets approved; “test” and “notifications” invite questions and delay.

1. Onboard the agent with a clear summary and your real privacy and terms URLs.

2. Poll GET /ng/v1/rcs/agents until its status is approved.

3. Send a test to your own handset before you wire it into anything — an agent’s colour and logo are worth seeing on a real screen.

Agent replacement

Some accounts are configured so that the agent you name is substituted for a network-appropriate one at send time. If that is on for your account, the agent you send as may not be the one that arrives.

Both are recorded — the one you asked for and the one actually used — so the reports and the delivery webhook show what really went out. You need do nothing differently; just do not be surprised by a name you did not pass.

Your agent name is your consent key

An opt-out is recorded against the agent’s brand slug — FirstDigits becomes first-digits — so the agent you send as is the one people unsubscribe from.

Moving to a different agent later means starting that consent record from scratch: the people who opted out of the old one are not carried across, and the people who opted in are not either. See Consent & opt-out.