Delete all mappings for a brand
/v1/brandAddresses/brand/{brandId}org.permission.apps.deleteorg.admin.apps.writeThe API key or user must hold at least one of them. Legacy roles still work; prefer the others for new keys.
Brands
A brand represents one of the companies, products or storefronts you support from a single Kustomer org. Brands let each one have its own name and icon, chat widget settings, knowledge base and email addresses.
Many businesses run more than one brand out of one support team, for example a retailer with two storefronts. In Kustomer each of these is a brand. Admins manage brands in the admin settings, and other configuration hangs off them: chat settings (colors, greeting, business hours and assistant) are set per brand, each knowledge base belongs to a brand, and the web chat SDK takes a brandId to choose which brand's widget to load. Every org starts with one brand, created when the org is registered and marked default: true. Chat uses the default brand when it starts without a brandId.
Brand fields
A brand is small: name and iconUrl are the only fields you write, and both are required when you create or update one. default tells you whether it's the org's default brand. The public API has no endpoint for deleting a brand.
Brand address mappings
A brand address mapping links an email address to a brand, so Kustomer knows which brand an address belongs to. One address can be mapped to several brands, and each brand can mark at most one of its mapped addresses with isDefault: true. Addresses are matched case-insensitively.
These endpoints behave differently from most write endpoints:
POST /v1/brandAddressesis idempotent. Posting an address and brand pair that already exists returns the existing mapping with200instead of creating a duplicate. A new mapping returns201.POSTaccepts an optionalallBrandsflag. Whentrue, the address is shared across every brand, and Kustomer syncs the flag onto every mapping for that address. If you leave it out on create and another mapping for the same address is already shared, the new mapping inheritstrue.PATCHchanges onlyisDefaultandallBrands, and needs at least one of them. SettingisDefaulttotruemoves the default from the brand's previous default address. Deleting the default mapping leaves the brand with no default; Kustomer doesn't promote another address automatically.- Deleting all mappings for an address first checks whether the address is still connected to an email account in Kustomer. If it is, nothing is deleted and the response reports
live: true. If Kustomer can't confirm either way, it deletes nothing and returns503.
Which endpoint to use
| To | Call |
|---|---|
List brands, for example to find a brandId for chat |
GET /v1/brands |
| Get the org's default brand | GET /v1/brands/default |
| Create, read or update a brand | POST /v1/brands, GET or PATCH /v1/brands/{id} |
| See which brands an email address is mapped to | GET /v1/brandAddresses, with address to look up one address |
| Map an address to a brand | POST /v1/brandAddresses |
| Make a mapped address the brand's default, or clear it | PATCH /v1/brandAddresses/{id} |
| Remove one mapping | DELETE /v1/brandAddresses/{id} |
| Remove every mapping for an address, or for a brand | DELETE /v1/brandAddresses/address/{address} or DELETE /v1/brandAddresses/brand/{brandId} |
Brand reads are available to most users. Writing brands needs brand write permission, and brand address mappings use the apps permissions. A brand can have only one default address at a time, so if two requests try to set different defaults for the same brand at once, one of them can fail with 409 Conflict. Read the mappings again and retry.
Path parameters
Responses
OK
No response body.