Generate JWT Token
Use this action when a later step needs a signed token to authenticate a request to AutoTalk's own /v1 API.
Check for a first-class action first
If you are reaching for this action so that a later HTTP step can call AutoTalk's own API, look for a dedicated action for that operation before you mint anything. There are actions for reading, counting, creating, updating and deleting documents, running functions, sending messages, uploading files and running other workflows.
A dedicated action is the better tool for three concrete reasons, not as a matter of taste:
- It creates no credential. Mint-then-call produces a real token that stays valid for its whole lifetime — up to 24 hours — and remains spendable by anything that can read it. A dedicated action carries only the narrow permission that one operation needs and hands nothing back.
- It is checked before the run starts. A workflow whose steps exceed your permissions is refused up front, as a whole. A minted token that is too weak fails later, mid-run, at whichever step happens to spend it.
- It is less to get right. No scope list to maintain, no lifetime to choose, no URL to keep in step with the API.
Mint a token when you genuinely need one: connecting the AutoTalk MCP server, or reaching a /v1 route that has no action of its own. If you find yourself minting one for something ordinary — counting documents, reading a record — that gap is worth reporting, because the action is the intended path and the token is the workaround.
Best for
- Authenticating a later request to AutoTalk's
/v1API (for example, an AutoTalk MCP-connect step) - Passing the token to AutoTalk's API via the
x-jwt-token(orx-auth-token) header — it is signed with AutoTalk'sJWT_SECRETand is not verifiable by arbitrary third-party systems - Restricting access with a short validity window
Main fields
| Field | What it does |
|---|---|
| Advanced mode | Unlocks the Duration and Allowed IPs options. Duration only takes effect when this is on (otherwise the token uses the default 300-second lifetime). Allowed IPs are never silently dropped: providing an IP list without Advanced mode is rejected with an error rather than ignored |
| JWT Duration (seconds) | How long the token stays valid, in seconds. Defaults to 300 (5 minutes) and is capped at 86400 (24 hours). Only applied when Advanced mode is on |
| Allowed IPs | Restricts the token to specific IP addresses. Only applied when Advanced mode is on — and providing IPs without Advanced mode is rejected (the restriction is enforced, never silently lost) |
| API scopes | The capabilities the token may use on /v1 and on the AutoTalk MCP server, picked with the same permissions grid used for team roles and API keys. Only applied when Advanced mode is on — and, as with IPs, a scope list supplied without Advanced mode is rejected rather than ignored. Leaving it empty mints a token that holds nothing, so the token will be refused wherever it is used |
What later steps can use
The token is available at:
step(N).jwt
Tips
- Keep the duration short unless you have a strong reason not to.
- Only use IP restrictions when the receiving system has a stable IP range.
- Treat the generated token as sensitive data in later steps.
- Turn on Advanced mode and pick the narrowest set of API scopes your later steps actually need. A token minted without scopes grants nothing at all, and a token minted with more than you need stays spendable for its whole lifetime.
- Scheduled runs are capped: a workflow triggered by a schedule, a data hook or
a notification button may not mint
automation:adminor anyorg.*scope, because there is no credential behind such a run to inherit authority from.