Skip to content
Rigyx

Authentication

Every request carries an API token. Tokens are scoped — each one grants exactly the permissions you choose, and nothing more.

Create a token

  1. 1
    Open the Developer settings
    In the portal, go to Settings → Developer.
  2. 2
    Create a token
    Click New token, give it a name, and select the scopes it needs — only the scopes you tick are granted.
  3. 3
    Copy it now
    The raw token is shown exactly once. Copy it straight into your secrets store — it cannot be retrieved again afterwards.

A token looks like jmt_ followed by a long random string. Only a short prefix (for example jmt_a1b2c3d4…) is shown in the portal afterwards, so you can tell tokens apart without exposing them.

Authenticate a request

Pass the token as a Bearer token in the Authorization header on every request:

curl
curl -H "Authorization: Bearer jmt_..." \
  https://rigyx.com/api/public/v1/whoami

/whoami is the quickest sanity check — it returns the business and scopes the token is bound to:

200 OK
{
  "business_id": "5b2e...-uuid",
  "scopes": ["leads:read", "leads:write", "webhooks:manage"],
  "token_id": "a1b2...-uuid"
}
A missing or bad token
Requests with no token, or an invalid or revoked one, return 401 with code UNAUTHENTICATED. The token is never accepted from a query string — only the header.

Scopes

A scope is a single permission string like leads:read. Scopes are checked on every request: a token holding only leads:read cannot POST /leads — it gets a 403 with code INSUFFICIENT_SCOPE, naming the scope it lacked. Grant each token the narrowest set it needs.

Leads
leads:readleads:write
Contacts
contacts:readcontacts:write
Campaigns
campaigns:readcampaigns:write
Emails
emails:reademails:send
Documents
documents:readdocuments:generatedocuments:send
Invoices
invoices:readinvoices:write
Tasks
tasks:readtasks:create
Inbox
inbox:readinbox:reply
Agents
agents:invokeagents:config
Webhooks
webhooks:manage
API tokens
api_tokens:manage
Events
events:read
This is the full set of scopes a token can hold. The endpoints published today are listed in the Endpoint reference — new endpoints are added under existing scopes over time, without breaking tokens you already issued.

Token security & revocation

How tokens are handled, and what to do when one is exposed:

Hashed at rest
The server stores only a SHA-256 hash of the token, never the token itself. A database leak does not expose usable tokens — and it is why a token cannot be shown to you twice.
Constant-time checks
Tokens are compared with a timing-safe comparison, so the check leaks nothing about how close a guess was.
Revoke instantly
Delete a token in the Developer tab and it stops working on the next request. If a token leaks, revoke it and issue a new one — there is no other recovery step.
Per-token rate limit
Each token has its own request budget (60 / minute by default). One noisy integration cannot starve another.
PreviousAPI overviewNextConventions