Troubleshoot Mexico NOM-184 consent gate 422 rejects

Mexico’s NOM-184-SCFI regulation requires explicit, time-stamped consent for every promotional A2P SMS sent to a Mexican subscriber. Orbit’s Mexico consent gate runs before the send is dispatched and rejects a violation with 422 MESSAGING_MX_NOM184_CONSENT_MISSING. Because the reject fires pre-dispatch, the message never leaves Orbit, no downstream carrier sees it, and no wallet deduction happens — a rejected send costs nothing, but a blind retry re-burns the same reject. The gate is a tenant-owned control: it runs only on Mexico-bound destinations and only when your organization has opted in via the regional send-gates toggle (see Gate scope). When enabled, each Mexico-bound promotional send checks your consent records for the recipient — an opted-in record stamped with nom184 lets the send through; anything else is refused.

Symptom: a 422 on a Mexico-bound send

A send to a Mexican destination (+52…) returns HTTP 422:

{
  "error": {
    "code": "MESSAGING_MX_NOM184_CONSENT_MISSING",
    "status": 422,
    "message": "destination_country_MX_requires_nom184_consent",
    "details": {
      "destination_country": "MX",
      "regulation": "NOM_184_SCFI",
      "hint": "Record explicit NOM-184 consent for this recipient under Contacts → Consent before sending promotional MX A2P SMS. Transactional sends can pass metadata.nom184_exempt=true."
    }
  }
}

The reject means your consent records carry no opted-in NOM-184 consent for the recipient’s phone number. The gate resolves the recipient by phone number (E.164), so a campaign send that carries no contact id is still matched against the same records.

Symptom → cause

Symptom	Cause	Fix
`422 MESSAGING_MX_NOM184_CONSENT_MISSING` on a promotional send	No opted-in NOM-184 consent record exists for the recipient’s phone number	Record the recipient’s consent (below), then retry
Same 422 after you “added the contact”	Creating a contact does not record consent — the gate reads consent records, not the contact list	Record consent on the contact, not just the contact itself
422 fires on a transactional send (OTP, account alert)	Transactional traffic is not exempt by default	Pass `metadata.nom184_exempt=true` on genuinely transactional sends (see Transactional sends)
Send succeeds for one recipient, 422s for another	Consent is per-recipient — one opted-in record does not cover the list	Record consent per recipient, usually at your signup or import source
Wallet was charged for the rejected send	Does not apply — the gate refuses pre-dispatch, so a 422 here deducts nothing	If you see a deduction on a 422, open a support ticket (below)

Record explicit NOM-184 consent on each Mexican recipient before you send. Two surfaces write the same records:

API — POST /compliance/consent with the SMS channel, the NOM-184 consent type, and the evidence fields that make the record defensible (what the recipient agreed to, the disclosure version, the lawful basis):

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"
  }'

Dashboard — open the contact and use Contacts → Consent to record the same opt-in with the NOM-184 consent type.

Both surfaces stamp the record with the consent timestamp, channel, state, and source. Once the record exists and reads opted_in, retry the send — the same request body now passes. Verify the state first with GET /compliance/consent/lookup?identifier=%2B525512345678&channel=sms if a retry still 422s; the full field contract is in Consent Management & Receipts.

Transactional sends

Verification codes, account alerts, and other strictly transactional messages are not “promotional A2P SMS” under NOM-184-SCFI. Flag those sends with metadata.nom184_exempt=true on the message request and the gate skips them. Use the flag only where it accurately describes the traffic — every exemption is captured in your audit log, and applying it to promotional content undermines the legal position the gate exists to protect.

What NOT to do

Do not blanket-add MX NOM-184 consent to non-promotional traffic. Consent records are legal declarations; stamping transactional-only recipients with a promotional consent you never collected creates a false audit trail and expands your regulatory exposure. Exempt transactional traffic with metadata.nom184_exempt=true instead.
Do not import a consented list without the timestamps and evidence. A consent record you cannot tie to a time, a purpose, and a disclosure version does not survive an audit. Record purpose, consent_text_version, and consent_proof_url on every grant.
Do not retry the identical request in a loop after recording consent elsewhere than against the contact the gate resolved — the gate matches by phone number, so record consent on the number you are actually sending to.
Do not disable the MX gate to work around the 422. The toggle is your opt-in, but Mexican carriers and the regulator enforce NOM-184 regardless — a gate-disabled send that lacks consent shifts the violation from a clean API reject to carrier-side enforcement and possible fines.

Gate scope: the MX toggle

The Mexico gate guards the organization settings key:

Path: regional_send_gates.MX.enabled
Default: off — Mexico-bound sends are not gate-checked until you opt in.

If you see the 422, the toggle is on in your organization. Scope it to your production organization and keep a dedicated sandbox organization with the key off so test traffic skips the gate.

When to escalate

Open a support ticket when any of these are true:

The 422 persists after GET /compliance/consent/lookup returns opted_in for the recipient on the sms channel.
A 422 rejection produced a wallet deduction (rejections are pre-dispatch and must be charge-free).
You need bulk consent recording — importing a large consented list is a contact import plus per-recipient consent write; support can advise on throughput.

Include the recipient’s E.164 number, the consent_type you recorded, and the request id from the 422 response.

Consent Management & Receipts — the consent API contract, evidence fields, and proof-of-record export.
Error codes — the full send-path error table.
Troubleshoot India DLT gate 422 rejects — the sibling regional gate that enforces India’s DLT template regime.
Sender-ID not registered — the BR/SA/AE/SG registration gates; a Mexico send must also satisfy sender-format rules.
Opt-out and suppression — what happens to the consent record when a Mexican subscriber texts STOP.

​Troubleshoot Mexico NOM-184 consent gate 422 rejects

​Symptom: a 422 on a Mexico-bound send

​Symptom → cause

​Fix: record the recipient’s NOM-184 consent, then retry

​Transactional sends

​What NOT to do

​Gate scope: the MX toggle

​When to escalate

​Related references