> ## 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.

# Brazil Anatel Sender-ID Registration Rules

> Brazil's Anatel sender-registration rules expanded from the country-requirements matrix: the required alphanumeric Sender-ID registration, short-code-dominant A2P posture, the LGPD opt-in consent overlay, the Portuguese SAIR opt-out keyword family, and the no-send window vs tenant quiet-hours posture — mapped to the Orbit surfaces you already own.

# Brazil Anatel Sender-ID Registration Rules

Brazil (`BR`) is the largest A2P SMS market in Latin America, and
Anatel — the **Agência Nacional de Telecomunicações** — runs a
sender-registration regime that every carrier in the country enforces at
the edge. An alphanumeric Sender ID reaches a `+55` handset only once
that Sender ID holds a country-level `approved` registration; unregistered
and unmanaged alphanumeric senders are filtered rather than delivered
with a degraded sender. This page expands the BR row of the
[country-requirements matrix](/compliance/country-requirements) so you
can close the Brazil items deliberately instead of re-reading one JSON
blob per launch.

Brazil is a **tenant-owned burden**. Orbit never mandates your posture —
it keeps the [country-rules reference](/compliance/country-requirements)
that feeds the send-time gates, and it gives you the consent ledger,
quiet-hours, and opt-out surfaces below. The legal posture is yours.

<Note>
  This page is documentation, not legal advice. Anatel blocks unregistered
  alphanumeric senders at the carrier edge — traffic on a Sender ID with
  no approved BR entry does not deliver — and the LGPD consent duty is
  enforced against the sender by the ANPD. Have counsel review your
  sender-name choice, your consent capture, and your SAIR handling; Orbit
  supplies the surfaces.
</Note>

***

## How this page differs from the LGPD page

Orbit has two Brazil compliance pages because Brazil's regime runs on two
separate axes:

| Page | What it covers |
| - | - |
| [Brazil LGPD + Anatel Sender Posture](/compliance/lgpd-brazil) | The **privacy posture** under LGPD — lawful bases for processing, the consent-ledger contract, DSAR/erasure and the 15-day clock, data residency, and the WhatsApp WABA / RCS channel-readiness layer. |
| **This page** | The **sender-registration mechanics** and the send gates — which sender types Anatel accepts, the `required` registration level, the short-code-dominant A2P posture, the no-send window, and the Portuguese opt-out keyword family that every BR sender must honour. |

Read both before a Brazil launch: the LGPD page for the consent and
data-subject-rights posture, and this page for the sender-readiness and
send-gate posture.

***

## The Brazil-specific rules

Read the BR row of `GET /compliance/country-rules?channel=sms` (see
[Country Compliance Requirements](/compliance/country-requirements)).
Consolidated:

| Rule | BR value | What it means for you |
| - | - | - |
| Sender types | `alphanumeric`, `short_code`, `long_code` | All three are accepted, but **short codes dominate** A2P in Brazil. Alphanumeric Sender IDs are accepted only once registered with Anatel; long codes and unmanaged alphanumeric senders are heavily filtered at the carrier edge. |
| Registration | `required` (Anatel) | The send-time gate holds A2P SMS to BR on an alphanumeric sender until the BR entry is `approved`. Dynamic alphabetic senders are not accepted — file through [Sender-ID Registration](/compliance/sender-id-registration) and wait for approval before launch. |
| Sender-ID length | 3–11 characters | Anatel enforces the same 3-character floor AGCOM (IT), OFCOM (UK), and BTRC (BD) enforce — Sender IDs shorter than 3 characters are rejected even though the value parses. Pick a brand name of at least 3 characters. |
| Marketing consent | LGPD — opt-in required | Brazilian marketing SMS is opt-in, not opt-out: consent must exist before dispatch. Record it in the consent ledger with `sms` scope. See the [LGPD posture](/compliance/lgpd-brazil) for the lawful-basis contract. |
| No-send windows | No federal SMS quiet-hours statute; carrier-honoured convention | Brazil has no single codified SMS no-send window comparable to France's 20:00–08:00. The practical restraint comes from carrier filtering, Anatel consumer-protection guidance, and LGPD's purpose-limitation principle. Configure tenant quiet hours deliberately — see the next section. |
| Opt-out keyword | Portuguese `SAIR` family mandatory | Every BR marketing message must accept the Portuguese opt-out vocabulary; the alias table maps `PARAR`, `CANCELAR`, `SAIR`, `FIM` to your suppression ledger. See the keyword section and [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table). |
| Two-way / DLR / throughput | `two_way: true`, `dlr_support: full`, `default_tps: 10` | Inbound replies supported, full delivery receipts, 10 messages/sec default ceiling. |

The `registration: required` level is the load-bearing one: BR **does**
gate sends on it. An unregistered alphanumeric sender does not
gracefully fall back — it disappears at the carrier edge. Treat the
registration as a launch prerequisite, not a recommendation.

***

## Anatel's sender-registration regime

Anatel is Brazil's telecommunications regulator, and the three dominant
carriers (Claro, Vivo, TIM) treat A2P SMS as a registered-sender market.
The rules as they apply to your traffic:

* **Pre-registration is required.** An alphanumeric Sender ID on an
  SMPP-routed channel into BR delivers only when the BR entry on your
  registration is `approved`. Before approval the send-time gate holds
  the traffic with `MESSAGING_BR_SENDER_NOT_REGISTERED` (422); see
  [Troubleshooting Compliance Error Codes](/compliance/troubleshooting-compliance-error-codes).
* **Short codes dominate.** Dedicated short codes are the dependable
  A2P sender type in Brazil; long numbers and unmanaged alphanumeric
  Sender IDs are heavily filtered at the carrier edge. Prefer a short
  code for production volume; pair it with a registered alphanumeric
  Sender ID only where your brand needs the name on the `from`.
* **The 3-character floor is regulatory.** Anatel rejects Sender IDs
  shorter than 3 characters, the same floor enforced by AGCOM, OFCOM,
  and BTRC — the format rule is 3–11 characters, letters, digits, space,
  hyphen, and underscore. A two-letter abbreviation is not a viable BR
  sender.
* **Budget the lead time.** Short-code and alphanumeric registration
  with the carriers is not a same-week operation — budget 4–8 weeks of
  lead time before a launch date depends on SMS, the same window the
  [LATAM channels onboarding guide](/guides/latam-channels-onboarding)
  and [Sender-ID Registration](/compliance/sender-id-registration)
  budget for pre-registration markets.

**Tenant-owned controls that map to the Anatel rule:**

| Anatel obligation | Orbit surface |
| - | - |
| Pre-register the alphanumeric Sender ID for BR | [Sender-ID Registration](/compliance/sender-id-registration) — `POST /compliance/sender-id-registrations` with a `country: "BR"` entry referencing your `doc_…` KYC documents; poll until `status: "approved"`. |
| Respect the 3-character floor | Sender-ID format validation on the registration flow — the floor is documented on [Sender-ID Registration](/compliance/sender-id-registration) alongside AGCOM/OFCOM/BTRC. |
| Pre-flight the sender before filing | `GET /compliance/check?sender_id=<id>&country=BR` — answers "can this Sender ID work in BR?" before you file. |

***

## LGPD opt-in overlay on the registration

Anatel's registration is a sender-identity regime, not a consent regime.
The LGPD consent duty applies on top of it — registering the sender never
substitutes for consent. The full consent posture is on the
[LGPD page](/compliance/lgpd-brazil); the send-relevant points:

* **Marketing SMS into BR is opt-in.** Consent must exist before
  dispatch; record it with `sms` scope per `(contact, channel)` through
  [Consent Management](/compliance/consent-management), with
  `lawful_basis` set (`consent` for promotional traffic).
* **Evidence and withdrawal.** The consent ledger is your proof-of-record
  — exportable through
  [Export Consent & Suppression Records](/compliance/consent-suppression-export) —
  and withdrawal lands on the suppression list every send reads.
* **Register and posture together.** A fully-registered Anatel sender
  with no consent records is still a non-compliant BR posture; consent
  with an unregistered sender never delivers. Both surfaces close the
  BR row.

***

## No-send windows vs tenant quiet hours

Orbit's tenant quiet-hours feature
([Quiet-Hours Configuration](/guides/quiet-hours-configuration)) and the
Brazilian marketing no-send convention are different things:

| | Tenant quiet hours | BR no-send convention |
| - | - | - |
| Whose rule | Yours — an opt-in tenant control | The market's — carrier filtering, Anatel consumer-protection guidance, and LGPD's purpose-limitation principle |
| Default | **Off / fail-open** — unresolvable recipient timezone never blocks a send | Reference data — surfaced in the BR `content_restrictions`, not enforced as a platform gate |
| Enforcement | Your send-time configuration | Orbit documents it; enforcement of the legal posture stays with you |
| Configured via | [Quiet-Hours Configuration](/guides/quiet-hours-configuration) | Nothing to configure — honor it at the campaign level |

Brazil has no single federal SMS quiet-hours statute comparable to the
US TCPA calling window; the practical restraint comes from carrier
filtering and LGPD's purpose-limitation principle — sending marketing
at 03:00 São Paulo time is a complaint magnet even where no statute
forbids it. If you market into BR, configure tenant quiet hours that
cover a conservative window (a common posture is 21:00–08:00
America/Sao\_Paulo recipient time) so the opt-in control enforces what
the convention asks for. That is a deliberate opt-in — default tenant
quiet hours on, BR window set — not a flip Orbit makes for you.

Use the local recipient timezone (São Paulo time for the bulk of
Brazilian traffic) set deliberately per campaign; the resolver maps the
`+55` country prefix unless you override it. Validate the window before
a campaign with [Quiet-Hours Preview](/compliance/quiet-hours-preview).

***

## Portuguese opt-out keyword handling

The [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)
includes the Portuguese opt-out vocabulary: `PARAR`, `CANCELAR`, `SAIR`,
`FIM`, matched with locale-insensitive case-folding and Unicode
normalisation — a recipient replying `sair` or `Sair.` matches the same
opt-out rule. The Portuguese opt-in counterpart (`INICIAR`, `SIM`,
`COMEÇAR`, `ASSINAR`) re-subscribes after a prior opt-out.

When a Brazilian opt-out fires, the suppression entry it writes is
channel-scoped to `all`, not `sms` — the same propagation behaviour as
the English `STOP` alias. A recipient's `SAIR` knocks that contact off
SMS, WhatsApp, and RCS simultaneously: the opt-out is a request to stop
being contacted, not a request to stop SMS. If you have pruned the seeded
Portuguese rules in the dashboard, re-add them under
**Messages → SMS → Opt-out Rules** before launching BR traffic.

***

## Where each BR obligation maps in Orbit

| BR obligation | Orbit surface |
| - | - |
| Sender types — alphanumeric / short\_code / long\_code | [Country Compliance Requirements](/compliance/country-requirements) sender-types matrix + [Sender-ID Registration](/compliance/sender-id-registration) |
| Registration — `required` (Anatel) | [Sender-ID Registration](/compliance/sender-id-registration) submit-and-track flow; the [send-time gate](/compliance/send-gates) returns `MESSAGING_BR_SENDER_NOT_REGISTERED` until the BR entry is `approved` |
| Marketing opt-in (LGPD) | [Consent Management](/compliance/consent-management) — a consent record with `sms` scope before dispatch; posture in the [LGPD guide](/compliance/lgpd-brazil) |
| No-send windows | [Quiet-Hours Configuration](/guides/quiet-hours-configuration) opt-in tenant control (deliberate, not default) |
| SAIR keyword family | [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) — `PARAR`, `CANCELAR`, `SAIR`, `FIM` land on the suppression ledger |

***

## BR launch checklist

Narrowed from the generic launch checklist in
[Country Compliance Requirements](/compliance/country-requirements) to
the BR row:

<Steps>
  <Step title="Look up the BR row">
    Call `GET /compliance/country-rules?channel=sms&country=BR` and read
    the BR row's `sender_types`, `registration`,
    `content_restrictions`, and `stop_requirement`. The BR row reports
    `registration: required` — the send-gate holds BR traffic until an
    `approved` sender is attached.
  </Step>

  <Step title="Pick a sender type">
    Prefer a dedicated short code for production volume; pair it with a
    registered alphanumeric Sender ID only where your brand needs the
    name on the `from`. If you choose an alphanumeric Sender ID, pick a
    brand name of at least 3 characters.
  </Step>

  <Step title="Pre-flight then file the Sender ID">
    `GET /compliance/check?sender_id=<id>&country=BR` to confirm the
    sender is viable, then `POST /compliance/sender-id-registrations`
    with a `country: "BR"` entry referencing your `doc_…` KYC documents.
    Budget 4–8 weeks of Anatel lead time. See
    [Sender-ID Registration](/compliance/sender-id-registration).
  </Step>

  <Step title="Capture marketing opt-in first">
    Record a consent entry with `sms` scope before any BR marketing
    send; BR is opt-in under LGPD, not opt-out. See
    [Consent Management](/compliance/consent-management) and the
    [LGPD posture](/compliance/lgpd-brazil).
  </Step>

  <Step title="Cover the no-send window deliberately">
    If you run BR marketing traffic, turn on tenant quiet hours covering
    a conservative window (a common posture is 21:00–08:00
    America/Sao\_Paulo) — Orbit defaults this off. Validate the recipient
    timezone resolution with [Quiet-Hours Preview](/compliance/quiet-hours-preview).
    See [Quiet-Hours Configuration](/guides/quiet-hours-configuration).
  </Step>

  <Step title="Wire the Portuguese opt-out family">
    Confirm `PARAR`, `CANCELAR`, `SAIR`, `FIM` are mapped into the
    alias table and write the suppression entry at scope `all`. See
    [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table).
  </Step>

  <Step title="Verify before first send">
    `GET /compliance/sender-id-registrations` shows BR `approved`;
    `GET /compliance/consent/lookup` returns the recipient's consent
    row; the quiet-hours preview resolves the recipient timezone
    correctly. Then send.
  </Step>
</Steps>

***

## Related references

* [Country Compliance Requirements](/compliance/country-requirements) —
  the full matrix this page expands one row of.
* [Brazil LGPD + Anatel Sender Posture](/compliance/lgpd-brazil) — the
  privacy posture (lawful bases, DSAR, data residency) this page's
  sender-registration mechanics run on top of.
* [Sender-ID Registration](/compliance/sender-id-registration) — the
  submit-and-track flow for the BR `required` registration, the 3–11
  character format rules, and the lead-time table.
* [Send Gates](/compliance/send-gates) — the send-time enforcement the
  BR `required` registration feeds.
* [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) —
  the Portuguese `SAIR` family and the custom-rule extension path.
* [Consent Management](/compliance/consent-management) — where the BR
  marketing opt-in record lives.
* [Quiet-Hours Configuration](/guides/quiet-hours-configuration) — the
  tenant-owned opt-in control you use to honor the BR no-send convention.
* [Quiet-Hours Preview](/compliance/quiet-hours-preview) — validate the
  recipient timezone resolution before you go live.
* [LATAM Channels Onboarding](/guides/latam-channels-onboarding) — the
  step-by-step sender-readiness playbook for Brazil and the region.
* [Troubleshooting Compliance Error Codes](/compliance/troubleshooting-compliance-error-codes) —
  the regional-gate error surface the BR row lands in
  (`MESSAGING_BR_SENDER_NOT_REGISTERED`).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.