Authentication

Every Inklura API call is authenticated as a user within a tenant. There is no separate "organization API key" for the general API — a request carries a session identity, and the server derives the tenant/site scope from it (plus optional tenancy headers).

Tip

Try it interactively. The API Explorer has a Credentials & context panel — paste your Bearer token and (optionally) your X-Tenant-Id / X-Site-Id, and it builds a ready-to-run cURL for any endpoint. Everything you enter stays in your browser (localStorage) and is never sent to the docs site.

The four ways to authenticate

Method Use it for How
Session cookie Browser apps on *.inklura.fr __Secure-authjs.session-token set at login
Bearer JWT Scripts, servers, service-to-service Authorization: Bearer <jwt>
OIDC Delegated login via the platform IdP Authorization-code + PKCE against auth.1clic.pro
Feed API key Read-only content feeds FeedApiKey (feed_…) — feature-scoped, rate-limited

Session cookie

Signing in at manage.inklura.fr mints a NextAuth (Auth.js) JWT session cookie:

  • authjs.session-token in development
  • __Secure-authjs.session-token in production

The token is an HS256 JWT signed with the platform AUTH_SECRET, valid for 30 days. The same cookie is honored across every *.inklura.fr subdomain — that is what makes SSO work.

Bearer JWT (programmatic access)

For anything that isn't a browser — a script, a backend service, or one Inklura app calling another — send the session JWT as a Bearer token:

curl https://manage.inklura.fr/api/trpc/auth.getSession \
  -H "Authorization: Bearer $INKLURA_TOKEN"

The server verifies the JWT with AUTH_SECRET directly (no database round-trip, no browser request scope), then resolves your tenant/site. This is exactly how the console and desktop clients authenticate to the lean API server.

Note

Because the JWT is signed with the shared AUTH_SECRET, tokens can only be minted server-side by the platform. There is no self-serve "create API key" for the full API. To automate, reuse a valid session token, or contact support@inklura.fr to arrange a service credential.

OIDC (auth.1clic.pro)

Inklura's identity provider is a dedicated OIDC server at auth.1clic.pro. The console uses an authorization-code + PKCE (S256) flow:

  1. GET /api/auth/oidc-login → redirect to auth.1clic.pro/oauth2/authorize
  2. User authenticates
  3. GET /api/auth/callback?code=… → the code is exchanged for tokens (JWKS-verified) and a NextAuth session is minted

The console's client id is cm-nextjs-app. If you are building a new first-party app that should participate in platform login, you register a client with the IdP — see Single Sign-On.

Magic-link onboarding

Admins invite users with a signed, single-use link instead of a password:

  1. An admin calls POST /api/manage/auth/invite-link, which returns an HMAC-SHA256-signed invite scoped to (tenant, site) (signed with MANAGE_INVITE_SECRET).
  2. The recipient opens …/manage/onboard?d=<payload>.
  3. POST /api/auth/manage-invite-accept re-verifies the HMAC, provisions the user, and sets the __Secure-authjs.session-token cookie.

Feed API keys

Some read-only subsystems have their own scoped keys rather than a user session:

  • FeedApiKey — a hashed key with a feed_ prefix for content feeds. Each key has a per-hour rateLimit, an optional IP allowlist (CIDR), an expiresAt, and a set of permissions. Managed via the feedApiKeys tRPC router.
  • LiveChatApiKey — used by the embeddable live-chat widget.

These are the exception, not the rule — the general API uses sessions/Bearer JWTs.

Tenant & site scope

Your identity determines which tenant you act as, but many calls also need a site scope. You can pin both explicitly with headers — see tenancy:

X-Tenant-Id: <tenant uuid>
X-Site-Id:   <site uuid>

Without them, the server falls back to your session's selected tenant/site (cookies) or the request host.

Next steps