Fluos API authentication

How Fluos authenticates dashboard sessions with Clerk and verifies inbound webhook signatures.

Fluos has two auth stories: browser sessions for the product, and provider signatures for inbound webhooks.

Product sessions (Clerk)

Sign-in is handled by Clerk. Fluos never stores a password. Users sign in with Google, Apple, or a one-time email code. See Getting Started.

Authenticated product routes (/dashboard, /admin, and most /api/* handlers) expect a Clerk session cookie. Unauthenticated API calls receive:

{ "error": "Unauthorized", "code": "unauthorized" }

There is no public API key, OAuth app, or personal access token for third-party apps today. If you need programmatic video generation, that is an enterprise conversation — contact Fluos sales.

Public endpoints

These do not require a session:

  • /openapi.json, /llms.txt, /llms-full.txt, /ai.txt
  • /sitemap.xml, /robots.txt, /feed.xml
  • /docs, /developers, marketing pages
  • GET /api/search
  • Markdown negotiation on public pages (Accept: text/markdown)

Webhook signatures

Inbound webhooks are authenticated by the provider, not by Clerk:

EndpointHeaderSecret
POST /api/webhooks/clerksvix-id, svix-timestamp, svix-signatureCLERK_WEBHOOK_SIGNING_SECRET
POST /api/stripe/webhookstripe-signatureSTRIPE_WEBHOOK_SECRET
POST /api/webhooks/resendsvix-id, svix-timestamp, svix-signatureRESEND_WEBHOOK_SECRET

Invalid signatures return 400. These endpoints are not a general write API — only the matching provider can produce a valid signature. Details: Fluos webhooks.

Workspace connectors

Figma, Notion, Google Drive, Slack, and Linear connections use Composio-managed OAuth from Skills → Connectors inside a Fluos workspace. Tokens stay with Composio. That flow is user-initiated in the product, not a Fluos-hosted MCP server.