The registry has API rate limits of its own

The requirementstatement

Integrations must stay within the registry's published API rate limits.

Severityseverity: MediumMEDIUMUsually survives review, but lowers your trust score or invites a manual look you would rather avoid.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: API request rate to the registry
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: External recordEXTERNAL_DATA; The fact that settles it lives in a register we cannot query, such as the IRS file, a postal database, or another provider’s tenant. Reported as a warning with the evidence to check, not as a pass.
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: TCR
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

A polling integration built without regard to the limits will hit them during exactly the operations that matter — a bulk registration, a status reconciliation after an outage — and the failures look like registry problems rather than client ones. The fix is architectural rather than a retry, which is why it belongs before the integration is written.

How to fix itremediation

Back off on rate-limit responses, and replace polling with the status webhooks the registry publishes. Done when a bulk operation completes without a single rate-limit error.

Check this yourselfattestation

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

Does your platform poll the registry for status, rather than consuming its webhooks?

1Ask, or read the integration. Most poll, and it is the usual cause.
2Back off on rate-limit responses and replace polling with the published status webhooks.
3Done when a bulk operation completes without a single rate-limit error.

What wrong looks like: The limits are hit during exactly the operations that matter — a bulk registration, a reconciliation after an outage — and the failures read as registry problems rather than client ones.

Notesnotes

Integration behaviour at the registry. What the user has to establish is whether their platform polls — most do, and it is the usual cause. OPS-347 covers the webhook alternative.

Rules you will hit next

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

OPS-032A help request containing a stop-word is not an opt-outMediumMEDIUM OPS-042Somebody has to own revocations that arrive in conversationMediumMEDIUM OPS-050The opt-out confirmation is worth sending inside five minutesMediumMEDIUM OPS-051Only ask which messages to stop when there is more than one kindMediumMEDIUM OPS-057Log the sends you did not makeMediumMEDIUM OPS-062An opted-out consumer must be able to come backMediumMEDIUM

All operational rules

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