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. The key belongs to an API application and runs as a service account. Antly allows whatever that account's roles allow. 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}An api_key call runs as the application's service account. Antly allows the call when that account's roles include the namespace:action, and when the namespace sits inside the API key ceiling (profiles.*, objects.*, tickets.*, tasks.*, workflow.*). Role rules use the same grammar as a person's permissions. There is no model: or controller: prefix, and the application does not keep a separate scope list. 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.