How to manage your customers’ brands in an AI product

Start with the customer-to-brand record

A logo upload and a few colour fields can get a customer's first task started. They don't answer what happens when the customer corrects the logo, runs two brands, or leaves your product.

Brandfetch's onboarding guide shows a useful way to prefill a profile from a work-email domain. That lookup supplies company information. Your application still needs to decide which customer may use and change the resulting brand.

Make that relationship explicit before connecting generation. Tie your customer ID to the saved brand's identifier, or Brand ID. A practical application record might contain:

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 an illustrative application record, not a Rainbrand request schema. Store a reference to the credential, with the credential itself in your server's secret storage. A customer with several brands needs several authorised mappings; a matching company domain is not enough to create one.

The rest of the lifecycle follows this record. Creation fills it in, each job resolves it, corrections change the referenced version, and deletion disables use while cleanup finishes.

Decide which account holds the brand

You can maintain the brand data yourself or use a service that maintains guidance and files for your product. With either approach, decide whether brands belong to your platform's account or to accounts customers connect. That determines the credential on each request and what your product may delete later.

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

With your platform's key, usage belongs to the account or team where the work runs. With OAuth, requests use the connected person's resources under Rainbrand's ownership and plan checks. Keep the account choice with the mapping so that setup, usage and cleanup use the same connection. Current costs and request budgets are in Credits and limits.

Your product continues to own customer signup, permissions, task execution and the experience around these calls. The embedding guide shows where Rainbrand fits in that workflow.

Resolve access before every brand operation

When your platform holds many brands under one credential, Rainbrand can check whether that credential may access a brand. It cannot infer which of your customers is behind the request. Your server must make that decision first.

OWASP's object-level authorization guidance calls for checking the requested action on the requested object at every endpoint that uses an object identifier. AWS's SaaS Lens makes the same requirement concrete for shared infrastructure: each attempt to access a tenant's resource must respect the tenant boundary.

For a brand task, resolve the signed-in customer's membership and project on your server, then load that project's authorised Brand ID. The Brand ID is Rainbrand's identifier for the brand. Never treat possession of it as permission to read or change the brand.

Apply that check throughout the flow:

• 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 the browser and customer-controlled agent environments. A direct MCP connection using that credential could list and use brands the credential can access. OAuth narrows access to the connected person's resources, but your application still needs to select the authorised brand for each project.

Keep customer-derived examples separate too. A post copied into a shared prompt, an exported brand folder in a shared cache, or a reusable generation reference can carry another customer's material even when the outgoing Brand ID is correct.

Create the brand without losing the mapping

Ask for the sources the customer already uses: a website, guidelines, logos, fonts and representative work. Adding a brand combines those sources with written instructions. The API accepts website and Instagram sources, linked files and completed uploads. Use the upload workflow when files need to leave the customer's device.

Choose the account or team deliberately. The API's workspaceId field identifies the team; omitting it creates the brand in the caller's personal account. A team can keep your platform's customer brands together, but it does not enforce separation between the customers in your application.

Creation runs in the background. Persist the returned Brand ID against the customer's setup record immediately, then show progress until the brand is ready. Get a brand supplies its status and a failure reason when setup fails. A failed or unfinished setup should stay visible as such, rather than falling back to another customer's brand.

There are two different duplicate problems to handle:

A retried request. Send an idempotency-key and persist it with the setup attempt. Reuse that key with the same request to recover the original Brand ID if the response is lost. Use a new key for a new creation.

A matching source. Rainbrand normally rejects creation when a website or Instagram source matches an existing brand in the selected account or team. That is a setup conflict, not proof that the customer owns the existing brand. Reuse the match only after checking your own ownership mapping. If a separate brand is intended, allowDuplicate: true explicitly permits creation from the matching source.

Queue large backfills. Rainbrand limits brand starts per account or team, while API-key requests have a separate shared budget. Honour the returned retry delay rather than allowing every customer job to retry together. The limits guide carries the current quotas.

Prepare corrections, then apply them

Give customers a route to correct a missing colour, an old logo or a naming rule. Otherwise your product will keep fixing outputs while retrieving the same incorrect guidance.

Rainbrand's Brand Edit prepares proposed changes without changing the active brand. Your product can send an instruction or exact profile values, with new sources as evidence. If the edit asks for more information, expose that request through your workflow and continue the edit with an answer.

When preparation finishes, inspect the proposal, including changed guidance and profile values. Your product can present it to the customer or handle it through an authorised automated workflow. Refine, apply or discard it according to the permissions and interaction your product defines.

An edit is based on a particular brand version. If another edit changes the active version first, a stale proposal cannot be applied. Prepare a new edit from the current version instead. Check your application's permission to apply the change at that point, even if the caller was allowed to start preparation earlier.

Use the current version for new work

For each new task, request a Brief: the relevant guidance and assets selected from the brand for that task. Supply the deliverable, audience, required copy and constraints. Pass the returned guidance and assets to the tools making the work.

After applying a brand change, request a new Brief. An earlier Brief records the guidance selected for its earlier task; it does not become a refreshed instruction for later work.

To check finished work, your product can request a Review, which assesses it against the brand and returns findings. The tools making the work perform any corrections. Keep the findings associated with the same authorised customer job.

If your product retrieves or exports a complete Brand Skill, it receives a versioned snapshot of the brand's profile, guidance and asset references. Store its version with your cached copy. Get a brand returns the current version under activeSkill.id, which lets you detect when to refresh. Keep the customer, brand and version in the cache key.

Record the context used by completed jobs so revisions are explainable. A job begun before a rebrand may need to preserve its original direction; a new campaign may need the updated brand. Make that choice explicit rather than silently substituting a cached copy. Runtime retrieval covers this in more detail.

Campaign instructions also belong with the job. A temporary offer or experimental visual direction should not become lasting brand guidance merely because the customer requested it once.

Retire access and finish deletion

When a customer leaves, first stop new work and scheduled jobs. Mark the mapping as unavailable for normal use, while retaining the identifiers needed by your cleanup process. If a remote deletion fails, you need to be able to retry it without restoring customer 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.

Deleting a brand is not a substitute for checking the copies your product holds. Avoid promising a deletion outcome that your cleanup process does not cover.

If the customer connected its own Rainbrand account, disconnecting your product normally means removing the tokens and copies you hold. It does not by itself authorise deleting the customer's brand from that account.

Test two customers before release

A successful generation does not show whether customers' brands stay separate or whether setup, updates and deletion work correctly. Use two test customers to check those operations:

This is a proposed test matrix, not a report of a multi-customer integration run. The workflow above was checked against Rainbrand's documentation and public API contract.

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.