AnythinkDocs
See something missing?
powered by

Authentication

Anythink authentication is built to be simple to integrate and secure by default. Users can sign in with email and password or Google, your app receives a JWT that controls exactly what they can see and do, and role-based access rules determine which data each user is allowed to touch.

How it works

When a user signs in, Anythink returns a JSON Web Token (JWT). Your app passes this token with every subsequent API request. Anythink verifies the token, identifies the user, and applies whatever role-based and row-level access rules you have configured — automatically, on every request.

There are two sides to this:

  • Authentication — confirming who the user is (login)
  • Authorisation — controlling what they are allowed to see and do (roles and permissions)

Both are handled by Anythink. You configure the rules once in your dashboard; the platform enforces them on every API call.

Sign-in methods

Email and password

The default method. Users register with an email address and password, and receive a confirmation email before their account is activated.

Register a new user:

http 
POST /org/{orgId}/auth/v1/register
Content-Type: application/json

{
  "first_name": "Alice",
  "last_name": "Smith",
  "email": "alice@example.com",
  "password": "securepassword"
}

Log in:

http 
POST /org/{orgId}/auth/v1/token
Content-Type: application/json

{
  "email": "alice@example.com",
  "password": "securepassword"
}

Both return an access_token (JWT) and a refresh_token.

Google OAuth

Users can sign in with their Google account. You configure the integration once in your Anythink dashboard, and Anythink handles the full OAuth flow.

Setting up Google sign-in:

  1. Go to the Google Cloud Console and create an OAuth 2.0 Client ID under APIs & Services → Credentials
  2. Set the authorised redirect URI to: https://your-instance.anythink.cloud/org/{orgId}/auth/v1/google/callback
  3. In your Anythink dashboard, go to Settings → Authentication → Google OAuth and enter your Client ID and Client Secret
  4. Toggle Google sign-in to Enabled

Once configured, your app initiates the flow by redirecting users to the Google authorisation URL, and Anythink exchanges the resulting code for a JWT automatically.

Using the JWT in your app

Once a user is signed in, include their JWT as a Bearer token in every API request:

http 
GET /org/{orgId}/orders
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Anythink uses this token to:

  • Identify which user is making the request
  • Apply their role's entity-level permissions (can they read/write this entity at all?)
  • Apply any row-level security rules (which specific records can they see?)

If you make a request without a token, or with an expired token, you get a 401 Unauthorized response.

Public vs. authenticated requests

Some data you may want to be publicly accessible — product listings, published articles, pricing. For these, use the public search endpoint which requires no token:

http 
GET /org/{orgId}/search/public?q=*&e=products

Everything else requires a valid JWT.

Token refresh

Access tokens expire after a short period. Use the refresh token to get a new access token without asking the user to log in again:

http 
POST /org/{orgId}/auth/v1/refresh
Content-Type: application/json

{
  "token": "your-refresh-token"
}

Returns a new access_token. Store refresh tokens securely — they are long-lived.

API keys

For server-to-server integrations — workflows, scripts, or backend services — you can use an API key instead of a JWT. API keys are created in your dashboard under Settings → API Keys and take the format ak_....

Pass the key in the x-api-key header:

http 
GET /org/{orgId}/customers
x-api-key: ak_your_key_here

API keys are scoped to your organisation and carry the permissions of the role they were created with. Keep them secret — treat them like passwords.

Roles and permissions

Roles control what authenticated users can do. Every user is assigned a role, and every role has a set of permissions on each entity — read, create, update, delete, or none.

This is configured in Settings → Roles & Permissions in your dashboard. See the Roles and Permissions doc for the full guide.

Row-level security

Beyond role-level permissions, you can restrict individual records to specific users. For example, a customer should only be able to see their own orders — not everyone else's.

Row-level security (RLS) is configured per entity and works automatically once enabled. When a user with an RLS-enabled entity makes a request, Anythink filters the results to only records that belong to them.

See the Roles and Permissions doc for setup details.