Skip to main content
Company endpoints on the Fluid API are authenticated with a bearer token. Fluid provides four token types for integrators — company, partner, public, and droplet installation — each designed for a different trust level and integration pattern. Public storefront read endpoints require no token at all; everything below applies to the token-authenticated company surface.

​
Passing your token

Include your token in the Authorization header, prefixed with Bearer :
A request with a missing, invalid, expired, or revoked token receives a 401 Unauthorized. The 401 body is a bare { "message": "..." } object rather than the wrapped error envelope used by 404 and 422 responses — see Errors for the full envelope contract.

​
Token types

Each token type has a different scope of access and a different lifecycle.

​
Company token

A company token authenticates as your company. By default, a company token carries the Company API Token role, which holds every permission, so it acts like a logged-in admin. A company can narrow that by assigning a different role to its API token, though the dashboard doesn’t offer that setting. Fluid no longer issues company tokens for new integrations, and the dashboard doesn’t create or show them. If you already use one, it keeps working. For new work, create a partner token, or an API client if your company’s API Tokens screen offers one.
Never use a company token in client-side JavaScript or commit it to a public repository. Anyone who obtains a company token gets its access, which by default is full access to your account.

​
Partner token

A partner token provides company-level access for third-party integrations. Partner tokens support an optional expiration and can be tied to a role, making them safer to distribute than a raw company token. They suit agency-built integrations, certified app partners, and automated workflows that need elevated access without sharing your primary company token. Create a partner token under Settings → API Tokens in your Fluid dashboard. The same page is mirrored at Developer Hub → API Tokens. Click Generate Token, then choose a role and, optionally, an expiration date. The dashboard lists partner tokens as API Tokens. See API Tokens for the walkthrough. Give each partner token a role. A partner token with no role still authenticates, but every endpoint that checks a permission refuses it with 403.
If your company’s API Tokens screen has an API clients card and no Generate Token button, your company creates API clients instead of new tokens. Your existing tokens stay listed. Click Create client. A server client gets a client ID and a secret that’s shown only once, so copy it before you close the panel. A browser client gets no secret, can have only the same scopes a public token can have, and has a list of allowed origins.

​
Public token

A public token is designed for client-side use and is scoped to a limited set of read and asset permissions, so it can be embedded in browser code or mobile apps. Every public token is prefixed with pub-, which makes it easy to spot one that has been committed where a private token belongs. Because a public token is exposed to end users, keep its access as narrow as your integration allows. See Working with public tokens for how to create one and how to scope it.

​
Droplet installation token

A droplet installation token lets a droplet call the Fluid API for one company that installed it. Every droplet installation token is prefixed with dit_. Pass it as a Bearer token, like any other token type. Each company installation gets its own token. You receive it when the company installs your droplet: Fluid sends your install webhook a short-lived exchange token, and you exchange it for the installation’s credentials. See Exchange the token for credentials for the full flow.
  • Access. The token acts for the installing company. Its access is limited by the scopes granted to the installation — by default, the scopes your droplet requests. A request to an endpoint whose scope the installation lacks returns 403. See Token scopes for the scope list.
  • Storefront company endpoints. On the v2026-04 company endpoints (/api/v202604/company/...), a droplet installation token needs the website scope. It is not checked against storefront.view or storefront.update, and the website scope covers both reads and writes.
  • Lifecycle. The token does not expire. It stops working as soon as the company uninstalls your droplet, so delete your stored credentials when your uninstall webhook fires. Fluid also refuses it while your droplet is disabled.
  • Storage. Keep the token on your server, keyed to its installation. Never expose it in browser code, a query parameter, or an embed URL.
Partner and public tokens can also be managed programmatically on the /api/v2025-06/tokens/* endpoints. See List public tokens and the other API tokens pages in the API reference.

​
Working with public tokens

​
Create a public token

Go to Settings → API Tokens and create a token from the Public Tokens card. If the screen has an API clients card and no Create Public Token button, your company creates API clients instead; see the note under Partner token. You give the token a name (unique within your company), select its scopes, choose an expiration, and optionally add domains to its allowlist. The full token value is shown once, at creation. After that the dashboard lists only a masked form — pub- followed by the last eight characters — so copy the token somewhere safe before closing the dialog. If you lose it, create a replacement and delete the old one.
Creating a public token requires a company or partner token: a public token cannot mint another public token.

​
Expiration and the domain allowlist

A public token must carry an expiration, a domain allowlist, or both. A token that never expires and has an empty allowlist is rejected at creation. The dashboard offers expirations of 1 hour, 24 hours, 7 days, 30 days, or Never expires. Picking Never expires requires at least one allowlisted domain. Prefer a short expiration wherever you can mint tokens on demand: your server issues a fresh token for each page load or session, so a leaked one is useful only briefly.

​
Scopes

A public token reaches only the endpoints its scopes cover. Grant the narrowest set your integration needs. A DAM Picker integration typically needs dam:browse and dam:upload, plus dam:unsplash for stock photography and dam:ai_generate for AI image generation.

​
Storefront company permissions

The v2026-04 storefront company endpoints (/api/v202604/company/...) accept a company-admin bearer token carrying storefront.view for reads and storefront.update for writes. A droplet installation token needs the website scope instead — see Droplet installation token.

​
Best practices

  • Store tokens in environment variables. Never hard-code tokens in source files. Use .env files locally and a secrets manager (such as AWS Secrets Manager or Vault) in production.
  • Use the least-privileged token type. Prefer public tokens for client-side code, droplet installation tokens for droplets, partner tokens for other third-party integrations, and limit any existing company token to fully trusted server-side environments.
  • Request only the droplet scopes you need. Every scope granted to an installation is available to its droplet installation token.
  • Prefer expiring tokens. Even for long-running integrations, favor tokens that expire and are refreshed over indefinite ones.
  • Replace and audit. To replace a partner or public token, create a new one, switch your integration to it, then delete the old one. Review and revoke unused tokens under Settings → API Tokens.