# BRD-194 — Subscribe to brand status events instead of polling

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

- **Rule ID:** BRD-194
- **Layer:** Brand (`BRAND`)
- **Checks:** `the webhook configuration`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** Deterministic (settled in code from the submitted values)
- **Fix type:** Wait on an external system or a required interval
- **Required by:** TCR, Twilio, Telnyx
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-194/

## Why this rule exists

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 it

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 yourself

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

1. Subscribe to the brand identity status event and read the granular failure reason from its payload — the status field alone does not carry it.
2. Wait 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.

## Notes

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.