Authentication

Authentication

The Partner API v2 authenticates every request with an API key sent in the X-Api-Key HTTP header.

curl -H "X-Api-Key: sedis_pk_live_8f3kQ2mZ..." \
  "https://api.sedis.se/v2/bolagsanalys/companies"

There is no OAuth flow, no token exchange, and no Authorization: Bearer header in v2.0 — a single header is all you need. (OAuth2 may be added later as an additional scheme without breaking X-Api-Key; see MCP server and the stability policy in API stability and versioning policy.)

Key format

sedis_pk_live_<random>

• sedis_ — namespace.
• pk_ — "primary key" (reserved room for future scoped keys).
• live_ — environment marker.
• <random> — high-entropy random secret.

Keys are stored hashed at rest (HMAC-SHA256). Sedis keeps only the hash and the short non-secret prefix (e.g. sedis_pk_live_8f3kQ2mZ) for display and audit logs. The full key is shown to you once, at issuance.

Issuance

Your Sedis administrator issues keys from the Sedis admin portal. At issuance you must copy the full key immediately — it is displayed a single time behind a one-time acknowledgement, and cannot be retrieved afterward.

A key can be org-wide (belongs to your company / SedisCustomer) or individual (additionally tied to a named person, for per-user accountability). Both kinds see exactly the same tenant-scoped data — the difference is only who the key is attributed to in the audit log.

Multiple keys per customer

You can hold several active keys at once. This is intentional and supports:

• Per-environment keys — separate keys for production, staging, and your BI sync, each rate-limited independently (Rate limits).
• Zero-downtime rotation (below).

Rotation (overlap window)

Because multiple keys are valid simultaneously, you rotate without downtime:

1. Ask your administrator to issue a new key. The old key keeps working.
2. Roll the new key out across your systems.
3. Once everything uses the new key, ask for the old key to be revoked.

There is no forced rotation interval — rotate on your own schedule.

Revocation

Revoking a key takes effect within about a minute (the auth layer caches key validity briefly for performance). A revoked key returns 401 Unauthorized with an RFC 7807 body (Errors (RFC 7807)). Revoke any key you believe is compromised immediately, then issue a replacement.

What an auth failure looks like

A missing, malformed, revoked, or unknown key returns 401:

HTTP/1.1 401 Unauthorized
Content-Type: application/problem+json

{
  "type": "https://httpstatuses.io/401",
  "title": "Unauthorized",
  "status": 401,
  "detail": "A valid X-Api-Key header is required.",
  "extensions": { "traceId": "00-..." }
}

Note there is no WWW-Authenticate challenge header — v2 will not pop a browser Basic-auth dialog; it returns a clean JSON problem instead.

Note — cross-tenant: if you authenticate successfully but request a resource that belongs to another customer, you get 404 Not Found, not 403. This is deliberate — see Multi-tenant isolation.