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

# Mexico NOM-184 Consent Posture

> The disclosure language Mexican subscribers must see before you collect SMS opt-in, how to record NOM-184 consent artifacts in Orbit, and how the consent gate keeps promotional sends compliant.

# Mexico NOM-184 Consent Posture

Mexico's **NOM-184-SCFI** standard — the enforced compliance guideline
for Mexico's SMS industry by the Secretaría de Comunicaciones y
Transportes (SCT) and the carriers that move A2P traffic — requires
every promotional SMS sent to a Mexican subscriber to be backed by
explicit, time-stamped opt-in consent. The disclosure language goes on
your opt-in surface; the consent record goes in
[Consent Management](/compliance/consent-management); Orbit's Mexico
send gate enforces the pairing at dispatch.

<Note>
  The MX gate is a **tenant-owned control**, off by default. It runs
  only on Mexico-bound destinations and only when your organization has
  opted in via the `regional_send_gates.MX.enabled` settings key (see
  [Gate scope](#gate-scope-the-mx-toggle)). With the toggle off, sends
  are unchecked regardless — Mexican carriers and the regulator enforce
  NOM-184 anyway, so the toggle-off path is a carrier-side risk, not a
  workaround.
</Note>

***

## Why NOM-184 matters

Two carrier-side realities shape what "compliant" means in Mexico:

* **Disclosure at opt-in.** Each opt-in surface (SMS keyword answer,
  web form, paper form) must tell the subscriber what they are agreeing
  to — the brand, the kind of messages they will get, the cadence, and
  the opt-out path. Carriers reject promotional A2P traffic whose
  upstream opt-in did not carry that language.
* **Time-stamped consent records.** A consent claim you cannot tie to a
  time, a purpose, and the disclosure version the subscriber saw does
  not survive an audit — carriers and the SCT will ask for the record,
  not the assertion.

Orbit's gate (`422 MESSAGING_MX_NOM184_CONSENT_MISSING` on violation,
see [Troubleshoot Mexico NOM-184 consent gate 422
rejects](/troubleshooting/mx-nom184-consent)) enforces the second
bullet at dispatch. The posture you assemble in this page feeds the
first.

***

## The NOM-184 disclosure block

Carriers expect this disclosure at every opt-in point. Assemble it once
and reuse it across surfaces:

> **Ejemplo:** "Al registrarte, aceptas recibir mensajes SMS
> promocionales de \[Tu Marca] sobre ofertas y novedades, hasta 4
> veces al mes. Puedes darte de baja en cualquier momento respondiendo
> ALTO o desde nuestro centro de preferencias. Aplican tarifas estándar
> de mensajería. Consulta términos en \[URL de tu política de privacidad]."

Adapt the cadence line and the opt-out verb to your own agreements, but
do not drop the four elements the standard expects:

| Element     | What the carrier looks for                                                        |
| ----------- | --------------------------------------------------------------------------------- |
| **Brand**   | The business the subscriber is opting into, by name (`[Tu Marca]`).               |
| **Purpose** | What they will receive (`mensajes SMS promocionales… sobre ofertas y novedades`). |
| **Cadence** | How often (`hasta 4 veces al mes` — a concrete cap, not a hedge).                 |
| **Opt-out** | How to revoke (`respondiendo ALTO`) plus where terms live.                        |

For a back-office transcription of paper-form consent the disclosure is
the paper the subscriber signed; ensure the signed copy goes to
`consent_proof_url` alongside the record below.

### Recording the consent artifact

With the disclosure shown, stamp the artifact on Orbit with
`POST /compliance/consent`. The fields below are what turns a consent
claim into a defensible record:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": "+525512345678",
    "channels": ["sms"],
    "opt_in": true,
    "consent_type": "nom184",
    "lawful_basis": "consent",
    "purpose": "Promotional SMS the recipient agreed to receive",
    "consent_text_version": "mx-promo-sms-v3",
    "consent_proof_url": "https://signup.example.com/consent/evt_9f3a2c"
  }'
```

| Field                  | Notes                                                                                |
| ---------------------- | ------------------------------------------------------------------------------------ |
| `identifier`           | E.164 phone number the subscriber opted in on.                                       |
| `channels`             | `["sms"]` for NOM-184 traffic.                                                       |
| `consent_type`         | `nom184` — the gate filters on this value.                                           |
| `purpose`              | Free text naming the purpose; empty strings do not survive audit.                    |
| `consent_text_version` | The version tag of the disclosure the subscriber saw. Bump it when the copy changes. |
| `consent_proof_url`    | Evidence artifact — web-form event, signed paper scan, keyword receipt.              |

Verify the record reads `opted_in` with
`GET /compliance/consent/lookup?identifier=%2B525512345678&channel=sms`
before your next campaign. The full field contract is in
[Consent Management & Receipts](/compliance/consent-management).

***

## Where disclosures live in Orbit

Three surfaces carry disclosure copy; all three wire back to the same
consent records the gate reads:

* **Public consent form** — the hosted preference centre you enable per
  tenant (Settings → Compliance → Public consent form). Customize the
  Headline/Body/Footer fields with your NOM-184 block so recipients
  opting in via the URL see the disclosure before they consent. See
  [Public consent form](/guides/public-consent-form).
* **Keyword auto-replies** — your SMS keyword configuration (Messages →
  SMS, Opt-out Rules) answers `ALTO`/STOP and reinforces data-theft
  guard copy. The opt-in confirmation you send back when a subscriber
  texts a keyword should carry the full disclosure block above so the
  keyword-opt-in is signed with the language carriers expect.
* **Templates** — bake the disclosure into the first message of every
  campaign template that opens an opt-in conversation (transactional
  sends can carry `metadata.nom184_exempt=true` instead, per below).

Orbit stamps whichever surface was used with the same `consent_type:
nom184` record, so the disclosure copy only differs in location, not in
artifact shape.

***

## Example: assembling a Mexico + US dual posture

A tenant planning both Mexican promotional SMS and
parallel US transactional SMS assembles the following:

1. **Enable the MX gate** in the production organization
   (`regional_send_gates.MX.enabled = true`) and keep a dedicated
   sandbox organization with the key off for gate-free test traffic.
2. **Publish the disclosure block once** in the public consent form and
   reuse it in your keyword-reply template and the first template
   message.
3. **Tag US traffic differently:** US-destined OTP and account alerts
   carry `metadata.nom184_exempt=true`, so the gate never asks for a
   NOM-184 record on genuinely transactional traffic (and US TCPA
   windows apply separately — see
   [Send Gates](/compliance/send-gates)).
4. **Verify per recipient** with the consent lookup endpoint before
   the campaign goes out.

***

## Gate scope: the MX toggle

The gate guards the organization settings key:

* Path: `regional_send_gates.MX.enabled`
* Default: **off** — Mexico-bound sends are unchecked until you opt in.

Toggle it on in your production organization only. Keep the dedicated
sandbox organization (where the key stays off) for synthetic test
traffic so developers do not need staged consent artifacts to
exercise send code paths.

***

## Symptom → fix mapping (operational half)

This page documents the posture; the operational half — diagnosis,
reject response, corrective retry — lives in
[Troubleshoot Mexico NOM-184 consent gate 422
rejects](/troubleshooting/mx-nom184-consent). Read the mapping there
before you open a support ticket.

***

## Country requirements reference

The per-country row for MX (sender types, registration, content
limits) with the full `GET /compliance/country-rules` row contract
lives in [Country Compliance
Requirements](/compliance/country-requirements). Filter the endpoint
with `region=LATAM` or `country_code=MX` to read the live row.

***

## Related references

* [Consent Management & Receipts](/compliance/consent-management) —
  the consent API contract, evidence fields, and proof-of-record
  export.
* [Troubleshoot Mexico NOM-184 consent gate 422
  rejects](/troubleshooting/mx-nom184-consent) — the operational
  diagnosis page this page is paired with.
* [Public consent form](/guides/public-consent-form) — hosted
  preferences page where the disclosure block goes.
* [Send Gates](/compliance/send-gates) — other send-time gates
  (quiet-hours, DNC, RND, rate windows).
* [Country Compliance
  Requirements](/compliance/country-requirements) — the curated
  per-country reference behind the send gates.
* [Opt-out and suppression](/compliance/opt-out-suppression) — what
  happens to the consent record when a subscriber texts ALTO/STOP.