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. 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 against configured API-key scopes. Product defaults allow API-key authentication for profile.*, objects.*, tickets.*, tasks.*, and workflow.*, then the app's namespace directives narrow what the token can actually do.
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.