Authentication & Access
Authentication classes
Understand Antly JQL authentication classes: jwt, session, oauth2, api_key, and public.
Every JQL call resolves an authentication class. The class tells Antly how to authenticate the caller before it checks tenant context, namespace permissions, and intent-level rules.
Classes
jwt is the normal API and SPA token class. Login and OAuth exchange flows return JWT access data, and frontend JQL calls commonly include authenticationClass: "jwt".
session is the browser session class. It is used by same-site authenticated pages that rely on Django session cookies and CSRF protection.
oauth2 is for django-oauth-toolkit access tokens issued to OAuth2 applications. Use it for delegated third-party apps where a user authorizes access through the OAuth flow. See /developer/oauth2.
api_key is for server-to-server JQL access with a generated JqlToken from a system.App. Send it as Authorization: Bearer <token> (or X-Antly-Api-Key). It is intentionally separate from anonymous access. See /developer/api-applications-keys.
public is for truly anonymous traffic. Public forms, careers pages, storefront reads, payment link verification, and webchat bootstrap calls use carefully exempted controllers. Public does not mean "any API key can do this"; it means the endpoint itself is designed for anonymous callers. See /developer/public-access.
Example: JWT call
1{
2 "__meta__": {
3 "schema": "model",
4 "namespace": "tasks.Task",
5 "intent": "retrieve",
6 "authenticationClass": "jwt",
7 "return": {
8 "id": null,
9 "title": null,
10 "status": null
11 }
12 },
13 "filter": {
14 "status": "open"
15 }
16}Example: API key call
1{
2 "__meta__": {
3 "schema": "model",
4 "namespace": "objects.Record",
5 "intent": "retrieve",
6 "authenticationClass": "api_key",
7 "return": {
8 "id": null,
9 "data": null
10 }
11 },
12 "filter": {
13 "object__namespace": "Lead"
14 }
15}The backend validates api_key calls as the intersection of three layers: the platform ceiling (profiles.*, objects.*, tickets.*, tasks.*, workflow.*), the app's namespace:action directives, and the run-as user's RBAC. Directives use the same grammar as workspace permissions — there is no model: or controller: prefix. See /developer/api-applications-keys.
Exempt intents
Some controller intents are authentication-exempt because they must run before a user exists or because they are public product surfaces. Examples include tenant discovery, registration, password reset, JWT refresh, OAuth code exchange, public object controllers, ATS careers reads and submissions, public page retrieval, webchat token requests, and hosted payment link flows.
Treat exemptions as product-owned contracts, not an integration escape hatch. If you are writing an integration, prefer api_key, oauth2, or jwt; use public only for surfaces that Antly explicitly exposes anonymously.