How to manage your customers’ brands in an AI product

Start with the customer-to-brand record

Your server needs to know which customer may use each brand before generation starts. A domain lookup, such as Brandfetch's onboarding example, can prefill company information but does not establish that permission.

Tie the customer to the saved brand's identifier, or Brand ID:

Customer or tenant ID:
Project ID, if the customer has several brands:
Brand ID:
Credential or OAuth connection reference:
Account or team holding the brand:
Last observed brand version:
Lifecycle state: setting up / active / deleting / deleted

This is your application's record, not a Rainbrand request schema. Keep credentials in server-side secret storage, with references here.

Save the Brand ID when creation starts, resolve it for every job and block new work during deletion. Several brands require separate authorised mappings.

Decide which account holds the brand

Rainbrand maintains brand context your product can retrieve and update. Its authentication guide supports two arrangements:

Platform-key usage belongs to the account or team doing the work. OAuth uses the connected person's resources under Rainbrand's ownership and plan checks. Keep the chosen connection with the mapping for setup, usage and cleanup. Your product owns customer signup, permissions and task execution; the embedding guide covers the integration.

Resolve access before every brand operation

Rainbrand checks the credential's access, not your customer's membership. Resolve the signed-in customer's project and permitted Brand ID on your server, following the object-level access checks described by OWASP and AWS:

• A browser may select a project, but your server verifies access to that project and resolves its brand.
• A model may request a task, but your tool adds the authorised Brand ID before calling Rainbrand.
• A queued job keeps its customer and project association, and checks that work is still allowed when it runs.
• A request for saved task guidance, brand-check findings or an edit proposal verifies that the resource belongs to an authorised job or brand before returning it.
• A role allowed to generate work is not automatically allowed to apply a brand change or delete the brand. Enforce the permissions your product actually defines.

Keep platform credentials out of browsers and customer-controlled agents: a direct MCP connection could list and use the account's accessible brands. OAuth still needs an authorised project-to-brand selection. Separate customer-derived examples, prompt material and cached files too; a correct outgoing ID does not remove another customer's content from them.

Create the brand without losing the mapping

1. Collect sources. Add the brand from a website, Instagram account, linked files or completed uploads, with written direction.
2. Choose its account or team. workspaceId names the team; omitting it uses the caller's personal account. A team does not isolate your application's customers.
3. Persist immediately. Save the returned Brand ID with the setup attempt. Read status and failure details until ready; never fall back to another customer's brand.
4. Handle duplicates deliberately:

Queue large backfills and honour retry delays. Brand-start limits and the API-key request budget apply separately.

Prepare corrections, then apply them

Offer a correction route for outdated guidance instead of repeatedly fixing outputs:

1. Prepare a Brand Edit with instructions, exact values or new sources. It does not change the active brand yet.
2. If more information is requested, continue the edit with the answer.
3. Inspect the proposal, then refine, apply or discard it through the permissions your product defines. Recheck permission at application time.

If another edit changed the active version, prepare a new proposal; the stale one cannot be applied.

Use the current version for new work

• Request a Brief with the task, audience, copy and constraints. Pass its guidance and assets to the creation tools; keep temporary campaign directions with that job.
• After an applied brand change, request fresh context. Completed Briefs retain their original guidance.
• Keep Review findings with the same authorised job. Your creation tools make corrections.
• For cached Brand Skills, compare the saved version with activeSkill.id. Include customer, brand and version in cache keys; preserve original inputs for completed work.

Use the runtime example only after resolving the authorised mapping. Its environment variable does not replace per-request customer checks. For revisions, record whether to retain the original guidance or adopt the changed brand.

Retire access and finish deletion

Stop new and scheduled work first. Disable the mapping for normal use while retaining cleanup identifiers, so a failed deletion can be retried without restoring access.

For brands held by your platform:

1. Inventory any saved media covered by your deletion policy and retain its identifiers for cleanup. Export a Brand Skill first if your agreement includes giving the customer a copy.
2. Delete the brand. This removes it from the account and cancels its running tasks; the operation cannot be undone.
3. Complete any stored-media cleanup your deletion policy requires, using the retained identifiers with the separate operations for images, video and audio.
4. Remove your own cached context, exports and customer-derived prompt examples, and handle copies in past jobs according to your retention policy.
5. Record cleanup completion before retiring the operational mapping.

For a customer's own OAuth account, remove your tokens and copies. Disconnection does not authorise deleting their brand.

Test two customers before release

Use two test customers to check isolation and recovery:

To find the places your implementation needs those checks, ask your coding agent:

Find every place our code sends a brand ID to Rainbrand or returns a saved Brief, Review or Brand Edit. Include reads, writes, background jobs and deletion. Show how each operation resolves the signed-in customer's authorised project, brand and connection. Flag identifiers accepted without that check, and show what happens when the mapping is missing or disabled. Propose an isolation test for each gap.