Number pooling must be declared consistently with the campaign scale
The requirementstatement
The number-pool attribute must reflect whether the campaign will actually send from multiple numbers.
- Severityseverity
- HighHIGHRejected by at least one carrier or provider, and a common cause of failure at the rest.
- When it bitesphase
- Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
- What is checkedobject
- campaign.number_pool
- Where it liveslayer
- OperationalOPERATIONAL
- How Ekas settles itdetectability
- DeterministicDETERMINISTIC
- Settled in code from the values you submitted. No model involved, no judgement call, same answer every time.
- What the fix involvesfailureClass
- Fix the fieldRETRY_FIELD
- A better value in the form fixes it. Ekas can rewrite it and re-check.
- Who requires itauthorities
- TCRT-MobileTwilio
- When it appliesapplicabilityText
- Applies to every 10DLC registration.
Why this rule existsrationale
How to fix itremediation
Set the number-pool attribute true if the campaign will send from more than one number. Never spread similar content across undeclared numbers — that is snowshoeing and it is fined rather than rejected.
A compliant exampleexample
Sending from 5 numbers → number pool: true.
Rules you will hit next
Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.
OPS-POOL-DECLARED is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.