# BRD-189 — A failed brand can be updated by API and not in the console

> Remediating a failed brand differs by interface: the API permits an update in place, while the console requires delete and recreate.

- **Rule ID:** BRD-189
- **Layer:** Brand (`BRAND`)
- **Checks:** `the remediation path`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **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:** Twilio
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-189/

## Why this rule exists

The same brand, the same fix, and two different procedures depending on where you are standing — so a team that reads the API documentation and works in the console concludes the update is broken. Deleting and recreating is also the more expensive of the two, because a new brand starts its verification from the beginning and takes its campaigns with it.

## How to fix it

Fix a failed brand through the API, where an update in place is accepted, rather than deleting and recreating it in the console. Note that the update is accepted only while the brand is in a failed state — a brand that has not failed cannot be updated this way at all.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio | `30793` | yes |

## Check this yourself

**If this brand has failed, are you fixing it through the API rather than deleting and recreating it in the console?**

1. Use the API update in place — the console path requires delete and recreate, which restarts verification and takes the campaigns with it.
2. Note the update is accepted only while the brand is in a failed state; a brand that has not failed cannot be updated this way at all.

*What wrong looks like:* A team reads the API documentation, works in the console, and concludes the update is broken — then rebuilds a brand that could have been edited.

## Notes

Absorbs OPS-345, which states which brand states accept an update at all. Conditional on the interface rather than on the provider, so it is not `providers`-tagged. What the user has to know is that the console path is not the only one available: an API update avoids the rebuild entirely.