Reset a branded string to its original
Takes away a branding's override of one customer-facing string, so that the wording falls back to whatever the branding inherits: the parent branding, the default language, or the wording Shuttle ships. It is what an operator does after changing a label and wanting the original back. The change is scoped to one branding and one language; the wording itself is never chosen by the caller.
Where you can do this
- Merchant View: Localisation editor (reset)
Before you start
- The branding named by
brandingexists.defaultmeans the client's own top branding. - The part of
idbefore the first dot is a strings mapping declared by one of the provider integrations installed on the client, and the part after it is a key in that mapping. - There is something to take away only when the string is overridden for that branding and language. Merchant View offers the control only then; the API accepts the call either way and the effect is different (see Rules).
Rules
Checked by the API means Shuttle refuses the request however it is sent; a screen name means only that screen refuses it, and a direct API call would be accepted.
| Rule | Checked by | What you see |
|---|---|---|
branding, language and asset_key must be sent as query parameters. A body sent with the delete form is dropped before the request leaves Shuttle and would be ignored anyway, so a caller who puts them in the body silently resets the default branding and the default language instead | The API | accepted; the wrong branding or language is reset |
The part of id before the first dot must match a strings mapping declared by one of the provider integrations installed on the client | The API | VALIDATION_ERROR: "strings mapping not found" (HTTP 400) |
| The reset is applied to every provider integration that declares that mapping key, for the one branding and language named | The API | (behaviour, not an error) |
| Resetting a string that is not overridden is accepted and changes no wording, but still rewrites the branding's record of that attachment, creating an empty one where there was none, and raises the configuration version | The API | (none; 204) |
| Resetting every string of a language does not remove the language: the record stays behind, empty, and the language is still listed | The API | (none; 204) |
| Merchant View offers the control only on a string that is overridden and whose inherited wording differs from it, and after a reset offers an undo that writes the old wording back. The API applies neither condition | Merchant View screen | control not shown |
What happens
- The string goes back to the wording it inherits: the parent branding's, the branding's own default language, or the wording Shuttle ships. Customers see it on the hosted checkout and in the emails and receipts that use that string from the next time one is built.
- Only the branding and language named change. Other brandings, other languages and the wording of every other string are untouched, and brandings that inherit from this one pick the new wording up as well.
- The delete form answers 204 with no body, so nothing tells the caller which wording now applies: read the string, or the list of strings, back to see it. The update form answers 200 with the string as it now reads.
- Nothing is sent to the customer, no webhook is raised, and the change is not recorded in any history an operator can read: the only trace is the wording itself.
- In Merchant View the inherited wording is shown beside the string, and after a reset the screen offers an undo that puts the old wording back (Override a branded string).
Who can do this
- Roles: Admin only. Support holds no branding key, and principle 1 keeps screen terminology out of Support.
- Permission keys (for clients managing permissions directly):
brandingor*on the branding, or on the branding's division as a whole, checked once for each provider integration, after the API has resolved the mapping; without it NO_PERMISSION: "apiValidation.error.permissions", naming the branding (HTTP 403). Merchant View opens the localisation screen, and with it this control, only to a session holding a permission that both names one of its brandings and lists the keybrandingitself; the Admin team is created with*over the division's brandings rather than that named key, so the screen is normally reached through a deep link, which grants access on its own. - App options: none. The control sits beside the inherited wording on the localisation screen.
Related
Updated 30 minutes ago
Did this page help you?