Subscribe to brand status events instead of polling

The requirementstatement

Brand status changes should be received as events on a webhook rather than discovered by polling.

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: the webhook configuration
Where it liveslayer: BrandBRAND
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: 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: TCRTwilioTelnyx
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

Brand verification is asynchronous and can take days, and the event carries the granular failure reason that the status field alone does not — so a poller sees a state change with no explanation and has to guess at the cause. It also determines how quickly the campaign goes in behind it: an event-driven flow submits the moment the brand is ready, and a nightly poll can waste most of a day.

How to fix itremediation

Subscribe to the brand identity status event and read the failure reason from its payload. Wait for the event before making the next call rather than polling on a timer. Done when a brand state change arrives as a webhook carrying the reason.

Check this yourselfattestation

Ekas flags this from what you submit, but the fact that settles it sits somewhere only you can reach.

Are brand status changes arriving on a webhook that carries the failure reason, rather than being discovered by polling?

1Subscribe to the brand identity status event and read the granular failure reason from its payload — the status field alone does not carry it.
2Wait for the event before making the next call rather than polling on a timer.

What wrong looks like: A poller sees a state change with no explanation and guesses at the cause, and a nightly poll wastes most of a day before the campaign goes in behind it.

Notesnotes

Absorbs BRD-193, which names the webhook carrying the granular failure reason, and OPS-347, which adds waiting for the event before the next call. The webhook belongs to the integration rather than to a registration, so where it is not reported this is undecided rather than passing — the product should ask rather than assume.

Rules you will hit next

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

BRD-006Submit every name line above the address on a multi-line IRS recordHighHIGH BRD-007TCR takes only the first line of the IRS-registered nameHighHIGH BRD-010Take the legal name from the CP-575 or 147C, never a W-2 or W-9HighHIGH BRD-014An acquired business registers the details it filed taxes underHighHIGH BRD-027EIN must be old enough to have propagated to IRS recordsHighHIGH BRD-034Validate a non-US identifier against its home register before submittingHighHIGH

All brand rules

BRD-194 is one of 196 brand rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.