> ## 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. # Troubleshoot Mexico NOM-184 consent gate 422 rejects > Unstick a 422 MESSAGING_MX_NOM184_CONSENT_MISSING rejection on Mexico-bound promotional A2P SMS — record explicit, time-stamped NOM-184 consent for the recipient, or flag genuinely transactional traffic as exempt. # 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](#gate-scope-the-mx-toggle)). 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: ```json theme={null} { "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](#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) | ## Fix: record the recipient's NOM-184 consent, then retry 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): ```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" }' ``` * **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](/compliance/consent-management). ### 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](/guides/import-contacts) 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. ## Related references * [Consent Management & Receipts](/compliance/consent-management) — the consent API contract, evidence fields, and proof-of-record export. * [Error codes](/reference/error-codes) — the full send-path error table. * [Troubleshoot India DLT gate 422 rejects](/troubleshooting/in-dlt-gates) — the sibling regional gate that enforces India's DLT template regime. * [Sender-ID not registered](/troubleshooting/sender-id-not-registered) — the BR/SA/AE/SG registration gates; a Mexico send must also satisfy sender-format rules. * [Opt-out and suppression](/compliance/opt-out-suppression) — what happens to the consent record when a Mexican subscriber texts STOP.