🔍⌘K

Start typing to search docs.

Authentication Patterns

1.0.0

Service tokens, organization scoping, and best practices.

On this page
  1. API key scopes
  2. Supabase alignment
  3. Patterns
  4. Security recommendations

API key scopes

  • Keys are tied to organizations; they cannot read data from other tenants.
  • Rotate keys through the dashboard or Doppler (ops/cli provides forge api keys coming soon).
  • Store keys in GitHub Actions or other CI providers as masked secrets.

Supabase alignment

The Forge API mirrors Supabase policies:

  • Requests run as a service role scoped to the organization provided in the key.
  • API responses only include prefixed tables for that org (e.g., demo_app_users).
  • Rate limiting sits in front of Supabase to guard shared resources.

Patterns

Success

Keep the CLI for provisioning + deployment and reserve the API for querying state or integrating with external systems.

  • On-demand previews – Generate a temporary API key, provision an environment, and revoke the key once QA is complete.
  • Usage analytics – Poll the API for domain status, Supabase usage, and plan details to populate customer dashboards.
  • Support tooling – Build lightweight admin tools that call the API with limited keys instead of exposing Supabase directly.

Security recommendations

  1. Rotate keys every 90 days via automation.
  2. Scope CI jobs to read-only key usage where possible.
  3. Track docs search logs and CLI telemetries to spot suspicious behavior.

Important

Never embed API keys in generated app code. Generated apps talk to Supabase directly with anon keys; API keys belong in servers or automation only.