How to Find & Create Your Front API Token (2026)

Where the API token lives

Front keeps API tokens in the Developers area of company settings, and only admins can reach it. Per Front's developer documentation on API tokens, the exact path is:

1. Open Settings (the gear icon).
2. Go to the Company section and select Developers.
3. Click the API tokens tab.
4. Click Create API token.

If you don't see the Developers option at all, you're almost certainly not an admin — Front is explicit that "you must be an admin to create or manage API tokens." There's no per-teammate self-serve path; personal-inbox access is handled differently (more on that under Private resources below). API tokens are a company-level credential, created and owned centrally.

The list view shows each token's name, its Token ID (a short jwt_-prefixed identifier, not the secret itself), the scope it was granted, last activity, and who created it. Note what's not shown: the actual secret token string. Front reveals the full secret exactly once, at creation. That single design choice drives most of the security advice later in this guide.

Choosing scopes: Global, Shared, and Private

When you create a token, Front doesn't hand out blanket access. You choose which resource namespaces the token can touch, and Front recommends limiting each token to the minimum it needs. There are three namespaces:

• Global resources — company-level things that exist above any single workspace: company rules, company tags, teams, and accounts. A token scoped to Global resources can manage the org-wide furniture.
• Shared resources — resources that belong to specific workspaces: shared inboxes, workspace tags, and the like. You can pick individual workspaces or choose All shared workspaces to cover every one at once. This is the scope most support-automation tokens need, because shared inboxes are where team conversations live.
• Private resources — an individual teammate's personal inbox, signatures, and other private items. This one has a catch: the teammate must enable API access in their own settings before a token can manage their private resources. You can't reach into someone's personal inbox just by scoping a token to it.

Match the namespace to the job. A token that syncs shared-inbox conversations to a reporting tool needs Shared resources, not Global. A token that manages company-wide tags needs Global. Over-scoping is the single most common way an API credential becomes a bigger blast radius than it needed to be.

Choosing permissions: read, write, delete, send

Inside each namespace, you set what the token is allowed to do. Front exposes four granular permission levels, and they're not interchangeable:

The separation of Send from Write, and Delete from both, is the useful part. A dashboard that only reports on inbox volume should get Read and nothing else. An automation that drafts replies but shouldn't send them gets Write without Send. Granting all four "just in case" is exactly the habit Front's own documentation warns against: "limit the permissions for each token to prevent misuse or security issues."

Using the token in a request

Once created, the token authenticates every Core API call. Per Front's authentication docs, you send it in the Authorization header, prefixed with Bearer, against the base URL https://api2.frontapp.com:

curl --request GET \
  --url https://api2.frontapp.com/conversations \
  --header 'Authorization: Bearer YOUR_FRONT_API_TOKEN' \
  --header 'Accept: application/json'

A successful response returns JSON. If you're building something more involved than a one-off call, our guide to how to use the Front API walks through pagination, endpoints, and error handling in depth.

One number worth knowing up front: Front's rate limit starts at 50 requests per minute by default and varies by plan, with a burst cap of 5 requests per second per resource type. Limits are enforced per company, not per token, so spinning up a second token won't buy you more throughput. Exceed it and you'll get an HTTP 429 with a Rate limit exceeded. Please retry in [milliseconds] message. Rate-limit increases require Professional plan or higher.

The one that surprises everyone: you can't regenerate a token

Most platforms let you rotate a key in place — click "regenerate," get a fresh secret, keep the same slot. Front does not. Front's documentation is blunt about it: tokens cannot be regenerated, and deleting a token is permanent and irreversible.

Two practical consequences follow:

1. Copy the secret the moment you create it. It's shown exactly once. If you close that dialog without copying it into your secret manager, the token is effectively lost — you'll have to delete it and create a new one.
2. "Rotating" a token means create-then-delete. To rotate, you create a new token with the same scopes, update every service that uses the old one, confirm nothing broke, and then delete the old token. Deleting "will immediately prevent any applications using the token from making requests to the Core API," so deleting first will cause an outage.

To revoke a token, go back to Settings > Developers > API tokens, open the token's details, and click Delete. The cutoff is instant.

Per-team keys and security hygiene

Because tokens are company-level and long-lived, a little discipline goes a long way:

• One token per integration, named for its job. "Zendesk migration script," "Looker sync (read-only)," "Macha connector." When something misbehaves or a vendor relationship ends, you can revoke exactly one credential without collateral damage. The list view's creator and last activity columns make orphaned tokens easy to spot.
• Scope narrowly, per team where you can. A token for one team's automation should be limited to that team's Shared resources workspace rather than All shared workspaces. Front's namespace model is built for this — use it.
• Store the secret in a real secret manager, never in a repo, a shared doc, or a Slack message. The token is a bearer credential: whoever holds it is your Front account, within its scope.
• Prefer OAuth for anything you'll distribute. Front recommends OAuth over static API tokens for public or multi-customer integrations — it's scoped per install and revocable per customer. API tokens are best for internal scripts and single-instance tools.
• Audit periodically. Since there's no auto-expiry, review the token list every so often and delete anything whose last activity has gone cold.

Limits and where it breaks down

Front's token system is clean, but honest about a few edges. There's no in-place rotation and no auto-expiry — key hygiene is entirely on you, and a leaked token stays valid until a human deletes it. Private-resource access depends on each teammate opting in, so a token can't unilaterally reach personal inboxes. Granular per-resource scoping and OAuth features vary by plan, and rate-limit headroom above the 50 rpm baseline is gated to Professional and up — a high-volume integration on a lower tier can hit the ceiling. And a token, however well-scoped, is still just plumbing: it authenticates a request, but it doesn't read a customer's message, understand what they're asking, or write a useful reply. That's the reasoning work an API alone was never meant to do.

That's the seam where an AI agent layer fits. The broader category of AI agents for customer service exists for exactly the part a raw API credential can't do — understanding intent and answering it. Macha is one such layer: it runs on top of the Front you already use through the live Macha–Front integration, and it does not replace Front, your shared inboxes, or your token-based scripts. Instead of you hand-building a token, wiring the Bearer header, and minding the rate limit, Macha connects as a native integration; its agent then reads a conversation, understands intent rather than keywords, and drafts or sends a grounded reply — pulling a real order or account status through a custom tool that turns your own REST API into something the agent can call. Your Front rules keep routing conversations to the right shared inbox; the agent handles the answer. Macha's credits are consumed per AI action, never per resolution — automation and reasoning have different costs, and it's honest to price them that way.

FAQ

Where do I find my Front API token? In Settings > Developers > API tokens (under the Company section). You must be an admin to see it. Click Create API token to make a new one, or open an existing token's row to view its ID, scope, creator, and last activity. The full secret value is shown only once, at creation.

Can I regenerate a Front API token? No. Front tokens cannot be regenerated, and deletion is permanent. To "rotate" a token, create a new one with the same scopes, migrate every service to it, then delete the old one — deleting immediately blocks requests, so delete last, not first.

What scopes and permissions can a Front API token have? Three namespaces — Global resources (company-level), Shared resources (workspaces/shared inboxes), and Private resources (a teammate's personal inbox, which requires the teammate to enable API access). Within each, you grant Read, Write, Delete, and Send permissions independently. Grant the minimum a given integration needs.

How do I authenticate a Front API request? Send the token in the Authorization header prefixed with Bearer, against the base URL https://api2.frontapp.com — for example Authorization: Bearer YOUR_TOKEN. The default rate limit is 50 requests per minute (per company, varies by plan), with a 5 req/sec burst cap; exceeding it returns a 429.

Do I need an API token to connect Front to Macha? No. Macha connects to Front as a native integration rather than requiring you to hand-build and manage a static API token. It runs on top of your existing Front inboxes and rules, so you keep your current setup and add an AI agent layer without extra plumbing.

Ready to add an AI agent on top of Front without wiring a single API token? Start a free trial of Macha and connect it to your Front in minutes.