Skip to main content

​
Authentication

BLIPS API tokens are credential pairs. Each token consists of:
  • clientId
  • clientSecret
Requests are sent using HTTP Basic Auth. In practical terms:
  • Basic Auth username = clientId
  • Basic Auth password = clientSecret
This is the core authentication model for the current public BLIPS API contract. clientSecret is only returned on token creation. That means the token create flow is the one point where the full credential pair is revealed. Subsequent token list, detail, and revoke surfaces should be treated as management/readback operations and not as secret-retrieval surfaces. In the current OpenAPI copy, this is defined as the BasicAuth security scheme and applied globally across the public contract.

​
What this means for Mintlify

Once the docs site is deployed through Mintlify:
  • API Reference pages will show the authentication requirement automatically.
  • Playground forms will expose the corresponding auth input.
  • Endpoint pages inherit the security requirement from the OpenAPI document unless an operation overrides it.

​
Environment boundaries

Keep sandbox and production credentials isolated. The docs should describe BLIPS credentials as a token pair, not as a single opaque string. The public docs should eventually present at least two server targets in OpenAPI:
  • sandbox
  • production
That gives the Playground a real server selector instead of a placeholder base URL.

​
Auth-adjacent surfaces

The public API also includes token-management endpoints. Those routes are part of the authenticated API surface and should remain documented in the generated reference rather than being duplicated manually here. That means this page should explain:
  • what a BLIPS API token actually is
  • how clientId + clientSecret map into Basic Auth
  • that clientSecret is only returned on token creation
  • which environment those credentials belong to
  • how the Playground should authenticate requests once real servers are attached