Authentication
Every CAIP API is protected. Before you can call an endpoint, your request must prove who (or what) is making it. CAIP supports three authentication methods, so you can pick the one that fits your scenario:
| Method | Who / what authenticates | Underlying mechanism | Best for |
|---|---|---|---|
| WebEAM User | A person, signing in with their q‑Number | WebEAM OAuth 2.0 Authorization Code flow (Human‑to‑Machine, H2M) | Interactive access — portals, dashboards, notebooks, and trying things out as yourself |
| WebEAM M2M | An application / service (no human) | WebEAM OAuth 2.0 Client Credentials flow (Machine‑to‑Machine, M2M) | Recommended for API‑to‑API authentication in productive use cases |
| API Keys | An application, using a pre‑issued key | Static key sent as a bearer credential | Recommended for development and quick starts |
All three ultimately result in an Authorization: Bearer <token-or-key> header on your CAIP API request — what differs is how you obtain that credential and how it is managed.
- Just exploring or building a prototype? Start with an API Key — it's the fastest way to make your first call.
- Signing in to a UI (Portal, Langfuse, …) as yourself? That's WebEAM User — you already have it via your q‑Number.
- Shipping a productive service that calls CAIP APIs? Use WebEAM M2M — it issues short‑lived tokens tied to a registered client identity, with no long‑lived secret in your requests.
WebEAM User (sign in with your q‑Number)
WebEAM User authentication identifies a real person. You log in with your BMW WebEAM credentials (your q‑Number) — the same identity you use for other BMW systems — and CAIP receives a user token on your behalf.
This is the method behind the interactive surfaces of CAIP:
- The CAIP Self‑Service Portal (managing Spaces, users, and API keys)
- Managed dashboards such as Langfuse
- Any CAIP UI that asks you to "sign in with BMW"
Technically this follows the OAuth 2.0 Authorization Code flow (also called Human‑to‑Machine / H2M): you are redirected to WebEAM, you log in, and the application exchanges the result for a user access token. Because it requires a human at a browser, it is not suitable for unattended, server‑to‑server automation — use WebEAM M2M for that.
WebEAM M2M (recommended for productive API‑to‑API auth)
WebEAM M2M authenticates an application, not a person. Your service holds a Client ID and Client Secret, exchanges them with WebEAM for a short‑lived access token, and uses that token as a bearer credential on CAIP API calls.
This is the recommended method for productive use cases, because:
- No user needs to be present — it works for backend services, CLIs, daemons, and pipelines.
- Requests carry a short‑lived token instead of a long‑lived secret.
- The identity is a registered client, which can be granted exactly the permissions it needs.
👉 See WebEAM M2M — Setup & Usage for how to register a client, obtain a token, and call CAIP APIs.
API Keys (recommended for development & quick starts)
An API Key is a pre‑issued credential you send with your request. It's the quickest way to get started — no OAuth flow, no token exchange — which makes it ideal for development and quick starts.
Getting an API key:
- Create one in the CAIP Self‑Service Portal, or
- Raise a Request API Key service request (required for China).
Using an API key — send it in the Authorization header of every request:
Authorization: Bearer <your-api-key>
For a concrete example, see the LLM API documentation, which uses API‑key authentication.
An API key is a long‑lived credential. Never commit it to source control, embed it in client‑side code, or log it. Store it in a secret manager and rotate it periodically. For productive, server‑to‑server scenarios prefer WebEAM M2M, which uses short‑lived tokens instead.