STOP must never come back as an error

The requirementstatement

A consumer who sends STOP must never receive an error message in response.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: STOP response handler
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: Post-submissionUNDETECTABLE_PRE_SUBMISSION; The subject does not exist yet at submission time: a reply window, an expiring PIN, a queue position. Reported with its deadline.
What the fix involvesfailureClass: Wait on someone elseTERMINAL_EXTERNAL; Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities: CTIAMMA
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

An error reply tells the consumer their opt-out failed, so they try again, then complain — and the carrier sees a subscriber who asked to stop twice and got told the system was broken. It is almost always accidental: STOP arrives on a number whose auto-reply is misconfigured, or outside the hours a handler runs, and the platform returns its generic failure text instead of the confirmation.

How to fix itremediation

Make the opt-out path independent of everything else in the handler: suppress first, then reply with the confirmation, and never let a downstream failure produce an error to the consumer. Done when STOP is answered correctly even with the campaign paused, the API key rotated or the CRM unavailable.

A compliant exampleexample

Acme Coffee: you have been unsubscribed and will receive no further messages. Reply HELP for help.

Check this yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

Is STOP still answered correctly with the campaign paused, the API key rotated, or the CRM unavailable?

1Test the failure paths, not the happy path: send STOP while the campaign is paused, and again outside business hours.
2Confirm the handler suppresses first and replies second, so no downstream failure can produce an error to the consumer.

What wrong looks like: The platform returns its generic failure text. The consumer believes their opt-out failed, tries again, and complains — and the carrier sees somebody who asked to stop twice and was told the system was broken.

Notesnotes

Not observable from a registration. The user has to test the failure paths themselves — send STOP while the campaign is paused, and again outside business hours — because the correct response in the happy path proves nothing about the ones that matter.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

OPS-026The universal opt-out keyword set must be declaredBlockingBLOCKING OPS-027Opt-out keyword handling must be declared, not assumedBlockingBLOCKING OPS-029A revocation must survive punctuation, case and surrounding wordsBlockingBLOCKING OPS-031A plainly-worded opt-out counts even with no keyword in itBlockingBLOCKING OPS-037On a shared address, STOP must stop everythingBlockingBLOCKING OPS-038Opt-out must not be reduced to one prescribed methodBlockingBLOCKING

All operational rules

OPS-033 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.