Skip to main content
Planck is the canonical product and API name. Existing Bifrost integrations do not need a flag-day migration: compatibility aliases remain available while you update clients.

​
What to use for new integrations

  • Create and store API keys with the sk-planck- or pk-planck- prefix.
  • Use PLANCK_API_KEY for client and SDK configuration.
  • Use Planck-* request headers. For example, use Planck-Auth, Planck-User-Id, and Planck-Property-*.
  • Route explicitly through the planck model-provider slug.
  • Use /v1/planck-dataset, /v1/planck-sql, and /v1/playground/requests-through-planck for the renamed API resources.
  • Read Planck-* response and webhook headers, such as Planck-Id and Planck-Signature.

​
Compatibility behavior

  • Existing sk-bifrost- and pk-bifrost- credentials remain valid.
  • Bifrost-* request headers remain accepted. If both names are present, the corresponding Planck-* header wins.
  • Compatibility response and webhook headers are emitted alongside the Planck names during the migration period.
  • The bifrost model-provider slug resolves to the canonical planck provider.
  • The corresponding /v1/bifrost-dataset, /v1/bifrost-sql, and /v1/playground/requests-through-bifrost routes remain accepted.
  • New JavaScript integrations use the @inquantum/planck-* package family, including @inquantum/planck-helpers, @inquantum/planck-async, and @inquantum/planck-mcp. Python integrations use the corresponding planck-helpers and planck-async distributions.
  • Internal monorepo workspaces and compatibility identifiers may retain their @bifrost/* names when changing them would break internal consumers.
  • Existing Docker automation can continue to invoke bifrost-compose.sh and the bifrost profile. New automation should invoke planck-compose.sh and the planck profile.
Internal database identifiers, authentication realm names, and legal-entity references remain unchanged where renaming would break stored data or established integrations. See the Planck header directory for the canonical request contract.