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 (see tenancy).

Tip

In the API Explorer, Sign in with Inklura gets you a token through the console, whatever way you sign in there. The explorer then builds a ready-to-run cURL for any endpoint. The token stays in your browser (this tab only, unless you ask it to remember it). "Copy cURL" runs from your own terminal; the in-page "Send" button relays the request, token included, through the docs site to the API.

The four ways to authenticate

Method Use it for How
Session cookie The console in a browser __Secure-authjs.session-token, set at sign-in
Bearer JWT Scripts, servers, service-to-service Authorization: Bearer <jwt>
OIDC Delegated login through the platform identity provider Authorization code + PKCE against auth.1clic.pro
Feed API key A site's content feeds A feed key (feed_…), with its own hourly limit

Session cookie

Signing in at manage.inklura.fr sets a __Secure-authjs.session-token session cookie. It holds a JWT signed by the platform, valid for 24 hours after a password sign-in. The cookie belongs to the console host: other *.inklura.fr apps keep their own session, and the shared login at the identity provider signs the user in to each of them (see SSO).

Bearer JWT (programmatic access)

For anything that isn't a browser (a script, a backend service, 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 signature and expiry, then acts as the user in the token, within that user's tenant and site. An invalid or expired token is treated as no credential.

Note

Tokens are issued only by the platform: there is no self-serve "create API key" for the full API. To get your own session token, use Sign in with Inklura in the API Explorer (see the "Getting a token" section of Sessions & Tokens). For a long-running integration, email support@inklura.fr to arrange a service credential.

OIDC (auth.1clic.pro)

Inklura's identity provider is an OIDC server at auth.1clic.pro (discovery document at https://auth.1clic.pro/.well-known/openid-configuration). The console uses an authorization code flow with PKCE (S256):

  1. The console redirects the user to auth.1clic.pro/oauth2/authorize.
  2. The user authenticates.
  3. On return, the code is exchanged for tokens (verified against the provider's JWKS) and an Inklura session is created.

If you are building a first-party app that should take part in platform login, a client has to be registered with the identity provider: see Single Sign-On.

Invitation links

Admins invite users with a signed link instead of a password:

  1. From the console, an admin creates an invitation for a tenant and site (optionally with a role and a pinned email address). The link carries an expiry date.
  2. The recipient opens the link they received and may choose a password (at least 8 characters). If the link pins an email address, only that address can use it.
  3. The platform verifies the link signature and expiry, creates the user's account (or adds access for an existing account), and signs them in to the console. An existing account that already has a password keeps it: an invitation never replaces it.

Feed API keys

A site's content feeds can be protected by their own scoped keys rather than a user session:

  • Feed key: a key with a feed_ prefix. Each key has an hourly request limit (rateLimit, 0 to 10000, 1,000 by default, 0 for unlimited), an optional IP allowlist (allowedIps: IPv4 or IPv6 addresses and IPv4 CIDR ranges, comma-separated), an optional expiresAt date, and a set of permissions (full_content, unlimited_requests, custom_cache; full_content by default). Keys are managed through the feedApiKeys tRPC router (list, get, getStats, create, update, regenerate, toggleActive, delete). The full key is returned only once, by create or regenerate: afterwards only its prefix is visible. A feed that accepts keys reads it from the X-Feed-Api-Key header, from Authorization: Bearer feed_…, or from the api_key query parameter.
  • Live-chat widget keys: the embeddable live-chat widget uses its own keys, separate from feed keys.

These keys are the exception: the general API uses sessions or Bearer JWTs.

Tenant & site scope

Your token names your account's home tenant and site. The scope of each call is resolved on the request, then the platform checks it every call against your account's access, and a tenant or site you cannot access is rejected with FORBIDDEN. See Sessions & Tokens.

Next steps