This guide manages your Droplet with the v2026-10 company droplets API: Create a droplet for your company, Update a droplet, and Rotate a droplet’s webhook secret. The credential exchange uses Exchange an install token for installation credentials. The unversioned
/api/droplets endpoints will soon be deprecated, so use the v2026-10 endpoints for new work.1
Create the Droplet via API
Register your Droplet with Fluid by sending a Fluid creates the Droplet as a draft and returns it under a
POST request to /api/company/v2026-10/droplets. The payload defines your Droplet’s title, the URL Fluid will load in the merchant dashboard, the webhook endpoints Fluid calls during installation and uninstallation, and its Marketplace listing.droplet key. Save droplet.uuid; you’ll need it to manage the Droplet later.The create response doesn’t include the Droplet’s webhook secret. Get it by rotating the secret once with POST /api/company/v2026-10/droplets/{uuid}/webhook-secret-rotations, and store it as WEBHOOK_SECRET on your server. The response shows the new secret only once. Each later rotation replaces the secret immediately, so update your server straight away.2
Implement the Install Webhook Handler
When a merchant installs your Droplet, Fluid sends a signed
POST request to your install_webhook_url. Your handler must verify the signature and then exchange the included exchange_token for long-lived credentials.3
Exchange the Token for Credentials
The The response contains two tokens you must store securely:
exchange_token included in the install webhook is single-use and expires after 10 minutes. Exchange it immediately for long-lived credentials:The request needs no
Authorization header — the exchange token is the credential.4
Store Credentials and Register Webhooks
Store the
authentication_token and webhook_verification_token in your database, keyed by shop domain or installation ID. These credentials represent one merchant’s installation — each merchant who installs your Droplet gets their own set.After storing credentials, optionally register webhooks or drop zones for the merchant with the published POST /api/company/webhooks endpoint — see the Register and handle webhooks guide for the full registration, delivery, and verification contract:5
Implement the Uninstall Handler
When a merchant uninstalls your Droplet, Fluid sends a signed webhook to your
uninstall_webhook_url. Verify the signature the same way as the install handler, then clean up the merchant’s credentials and any associated resources.6
Test Locally with ngrok
Fluid must be able to reach your webhook endpoints over HTTPS. During development, use ngrok to expose your local server:ngrok prints a public HTTPS URL such as Remember to swap back to your production URLs before submitting for Marketplace approval.
https://a1b2c3d4.ngrok.io. Update your Droplet’s install_webhook_url and uninstall_webhook_url to use this URL while testing:7
Submit for Marketplace Approval
Once your Droplet is working end-to-end, contact Fluid to begin the Marketplace review process. Fluid will review your Droplet’s functionality, security, and listing content before making it available to merchants.
Your Droplet will not appear in the Fluid Marketplace until it has been reviewed and approved by Fluid. Complete its listing (
summary, description, logo_url, and features) before submitting.Verifying Webhook Signatures
Every webhook Fluid sends is signed with HMAC-SHA256. Verify the signature on every incoming request to ensure it genuinely came from Fluid. Reject any request where the timestamp is more than 5 minutes old to prevent replay attacks. This is the same signing scheme documented in the Register and handle webhooks guide — Fluid computes the HMAC over<timestamp>.<raw_body> using your shared secret.
Fluid includes three headers on every webhook:
Node.js
Identifying Merchants in Your Embed
Fluid appends the Droplet installation UUID as adri query parameter to your embed_url whenever it loads the Droplet inside the merchant’s dashboard. Use this value to look up the correct authentication_token for the current merchant:
Token Scopes
Yourauthentication_token is limited by the scopes granted to your droplet’s installation. By default, those are the scopes your droplet requests. A request to an endpoint whose scope the installation lacks returns 403. The available scopes are:
To find out why a request returns
403, see Debug a 403 from a Droplet token.
Check your Droplet works for every company
Before you ask Fluid to publish your Droplet, check that it works for many companies at once, not only yours. Each company that installs it gets its own installation and its own credentials.- No hard-coded companies. Don’t put a company ID, shop name or token in your code or configuration. Find the company from the installation on every request.
- One set of credentials per installation. Store each installation’s
authentication_tokenandwebhook_verification_tokenagainst that installation, and look them up by thedrivalue or the webhook’sX-Fluid-Shop. - Scope everything by installation. Every database row, cache key, file and background job belongs to one installation. A query without that filter can show one company’s data to another.
- Call Fluid with the installation’s token. Use the installation’s
dit_token, not your own API token or sign-in. Your token reaches only your company, and it keeps working after you leave. - Verify each company’s webhooks with its own secret. A secret shared across companies can’t tell their deliveries apart.
- Clean up on uninstall. When
droplet.uninstalledarrives, revoke and delete that installation’s credentials and stop its jobs. - Test with a second company. Install the Droplet in a second company too, and check that neither company sees the other’s data. A
draftDroplet installs only in your own company. See Who can install your Droplet.
Related pages
- Droplets: what Droplets are and how they fit into Fluid.
- Embed apps with drop zones
- Get user information in mobile and Portal widgets