Macha

How Do You Use the Front API in 2026? Auth, Endpoints, Rate Limits and Examples

Abbas, Customer Support & AI, Macha

Written by

Ankeet Guha, Co-founder & CTO, Macha

Reviewed by

Published July 7, 2026

Updated September 24, 2026

To use the Front API, an admin creates an API token under Settings, Developers, API Tokens, and you send it as a Bearer token to https://api2.frontapp.com/. Here are the endpoints you will use, cursor pagination, the per-company rate limits, webhooks, and copy-paste examples in curl, Python and Node.

Key takeaways

  • The Front Core API uses one fixed base URL, https://api2.frontapp.com/, and every request carries a Bearer token from an API token or OAuth.
  • Only Front admins can create API tokens, under Settings, Developers, API Tokens, choosing features, namespaces and Read, Write, Delete or Send permissions.
  • Front's rate limit is shared per company: 50 requests per minute on Starter, 100 on Professional and 200 on Enterprise, plus a burst of half the limit.
  • Front caps analytics at 1 request every 3 seconds and search at 40% of the main limit, and sells extra headroom at $200 per 100 requests/min per month.
  • Front list endpoints return 50 results by default and 100 at most, and the docs say to follow _pagination.next until null rather than counting rows.
How Do You Use the Front API in 2026? Auth, Endpoints, Rate Limits and Examples

To use the Front API, an admin creates an API token under Settings → Developers → API Tokens, and you send it as Authorization: Bearer YOUR_API_TOKEN to the fixed base URL https://api2.frontapp.com/; GET /me is the first call that proves the token works. From there you read and write JSON resources (conversations, messages, contacts, channels, comments), page with a cursor, and stay under a per-company limit of 50, 100 or 200 requests a minute depending on your plan. This is Front the customer-communication platform at front.com, not a frontend web API. New to the product itself? Start with what is Front; if you'd rather connect tools than write code, the best Front integrations is the companion piece.

ItemValue (dev.frontapp.com, checked 24 Sept 2026)
Base URLhttps://api2.frontapp.com/
AuthBearer token: API token (internal) or OAuth (public integrations)
Who can create tokensAdmins only
PaginationCursor; default 50, max 100 per page; follow _pagination.next
Rate limitPer company: Starter 50 rpm, Professional 100 rpm, Enterprise 200 rpm
BurstHalf your limit; refills in 10 minutes
Over the limitHTTP 429 with retry-after in seconds
AI agent accessMCP server at mcp.frontapp.com/mcp (open beta, OAuth)
The Front (front.com) customer service platform website — home of the Front Core API.
The Front (front.com) customer service platform website — home of the Front Core API.

What is the Front Core API?

The Front Core API is a RESTful, JSON-over-HTTPS API, which Front calls its "primary backend API." You make standard HTTP requests (GET to read, POST to create, PUT/PATCH to update, DELETE to remove) against resource URLs, and you get JSON back. HTTPS is required.

The base URL is a single, fixed host (there's no per-account subdomain like some help desks use):

https://api2.frontapp.com/

So the conversations endpoint is https://api2.frontapp.com/conversations, the contacts endpoint is https://api2.frontapp.com/contacts, and so on. One quirk: most read/write payloads are JSON, but a few endpoints, notably sending a message with attachments, accept multipart/form-data instead. We'll flag those where they come up.

Should you authenticate with an API token or OAuth?

Front gives you two ways to authenticate, and both end up sending a Bearer token in the Authorization header. Which one you pick depends on who the integration is for.

  • API token: for internal integrations: a script, a sync job, or a backend service acting as your own company's account. This is the simplest path and what most people building against their own Front want. No redirect, no browser.
  • OAuth: for apps meant to be installed by other Front companies (a public/partner integration you distribute). Front's docs say "OAuth is required for public integrations available to all Front customers unless you obtain an exception from us." Front wants per-customer consent it can revoke, which a pasted static token doesn't give it.

How do you get a Front API token?

You create an API token in the Front app under Settings → Developers → API Tokens tab → Create API token. A couple of things worth knowing:

  • Only administrators can create or manage API tokens. If you don't see the option, you don't have admin rights on the company.
  • When you create the token you choose its features (Access resources, Auto-provisioning, Application triggers, MCP server), its namespaces (global, shared workspaces, private) and its permissions (Read, Write, Delete, Send). Scope it down to only what your integration needs.
  • Give it an extremely descriptive name. Six months from now "warehouse-sync (read conversations)" will tell you exactly where it's deployed; "test" won't.
  • To revoke a token, open it under the same tab and click Delete. Deletion is immediate and cannot be undone: any app using that token stops being able to call the API the moment you delete it.

Treat the token like a password: keep it out of client-side code, repos and logs, and store it in an environment variable or secrets manager.

Calling the API with a Bearer token

Send the token in the Authorization header, prefixed with Bearer, on every request:

curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://api2.frontapp.com/me

GET /me returns the token's resource owner, a handy first call to confirm your token works before you build anything on top of it.

OAuth, briefly (for distributable apps)

If you're building an app for other companies, you'll register an OAuth app, redirect the user to Front to grant access, and exchange the returned authorization code at Front's token endpoint for an access_token and a refresh_token. Access tokens are short-lived; when one expires you swap the refresh token for a new pair without sending the user through the flow again. The end result is identical to a token: an Authorization: Bearer {access_token} header on each request, so the rest of this guide applies unchanged. (See Front's OAuth docs for the exact endpoints and scopes, which can change.)

Which Front API endpoints will you actually use?

Front exposes a resource for nearly every object in the product. The ones you'll reach for most:

  • Conversations: /conversations. The center of gravity for almost every integration: list, read and update conversations (Front's term for a message thread) and assign, tag, archive or change status.
  • Messages: /conversations/{id}/messages to read a thread's messages, and /channels/{channel_id}/messages to send one. A message is an individual inbound or outbound communication.
  • Contacts: /contacts. The people you communicate with, with their handles (email, phone, social). Create and sync them from your own systems.
  • Channels: /channels. The connected email addresses, SMS numbers, chat and custom channels that messages are sent through. You need a channel's id to send.
  • Inboxes: /inboxes. Shared or private inboxes that group conversations and channels.
  • Teammates: /teammates. Your team members, useful for routing, assignment and reporting. Each has an id you'll use as an author_id.
  • Comments: /conversations/{id}/comments. Internal notes on a conversation (not visible to the customer), useful for posting context from another system.
  • Drafts: /conversations/{id}/drafts and /channels/{channel_id}/drafts. Create a reply for a human to review and send, rather than sending automatically.

A quick map of HTTP verbs to common actions:

ActionMethodExample endpoint
List conversationsGET/conversations
Get one conversationGET/conversations/{id}
Update a conversationPATCH/conversations/{id}
List a conversation's messagesGET/conversations/{id}/messages
Send a messagePOST/channels/{channel_id}/messages
Import a messagePOST/inboxes/{inbox_id}/imported_messages
Add an internal commentPOST/conversations/{id}/comments
Get current token ownerGET/me
The Front platform overview — the shared inbox, conversations and channels that the Front Core API reads and writes.
The Front platform overview — the shared inbox, conversations and channels that the Front Core API reads and writes.

How do you send a message with the Front API?

To send an outbound message you POST to a channel (the email address, number or custom channel it goes out through). The required fields are to (an array of recipient handles) and body; when you're sending as a teammate you also pass an author_id. You can send JSON, or use multipart/form-data if you need to attach files.

curl -X POST https://api2.frontapp.com/channels/YOUR_CHANNEL_ID/messages \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["[email protected]"],
    "author_id": "tea_55c8c149",
    "subject": "About your recent order",
    "body": "<p>Hi, we spotted a payment issue and are on it.</p>",
    "options": { "archive": false }
  }'

A successful send returns the created message object as JSON, including its id and a _links object with the message's API URL. (If you want to bring an existing message in from an outside system rather than send a new one, use POST /inboxes/{inbox_id}/imported_messages instead.)

How do you list conversations in Python?

Here's a minimal Python script using requests that reads a page of conversations. By default the list endpoint returns recent conversations; pass q (a search query), limit, or filter by inbox using the inbox-scoped variant GET /inboxes/{inbox_id}/conversations.

import os
import requests

TOKEN = os.environ["FRONT_API_TOKEN"]
BASE = "https://api2.frontapp.com"
headers = {"Authorization": f"Bearer {TOKEN}"}

resp = requests.get(f"{BASE}/conversations",
                    headers=headers,
                    params={"limit": 25})
resp.raise_for_status()
data = resp.json()

for c in data["_results"]:
    print(c["id"], "|", c.get("subject"), "|", c.get("status"))

# cursor pagination: follow `next` until it's null
print("next page:", data["_pagination"]["next"])

Front returns the records in a _results array, plus a _pagination object you use to page through (more on that below).

How do you post an internal comment from Node?

The same idea in Node using the built-in fetch (Node 18+). Here we post an internal note onto an existing conversation, the kind of thing you'd do to surface order data to an agent:

const BASE = "https://api2.frontapp.com";
const conversationId = "cnv_55c8c149";

const res = await fetch(`${BASE}/conversations/${conversationId}/comments`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.FRONT_API_TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    author_id: "tea_55c8c149",
    body: "Order #1234 refunded automatically, no action needed.",
  }),
});

if (!res.ok) throw new Error(`Front error ${res.status}: ${await res.text()}`);
const comment = await res.json();
console.log("Created comment:", comment.id);

How does Front API pagination work?

Front list endpoints use cursor-based pagination. Two things matter:

  • limit: how many results per page. The default is 50 and the maximum is 100.
  • _pagination: an object on the response with a next field. When there are more results, next is a complete URL for the following page (it already includes an opaque page_token query parameter encoding where you are). When you've reached the end, next is null.

The cleanest way to walk results is to follow _pagination.next until it's null; you don't construct the next URL yourself. Front also warns: don't rely on result counts to decide whether to keep going (a page can return fewer rows than your limit, e.g. if records were deleted); use next as the single source of truth.

url = f"{BASE}/conversations?limit=100"
while url:
    r = requests.get(url, headers=headers); r.raise_for_status()
    page = r.json()
    for c in page["_results"]:
        ...  # process each conversation
    url = page["_pagination"]["next"]  # None ends the loop

What are the Front API rate limits?

Front's rate limit is per company, not per token, so every token and integration on the account draws from the same pool. It's also plan-tiered. The plan names match Front's current pricing (Starter $25, Professional $65, Enterprise $105 per seat a month on front.com/pricing):

PlanRequests per minute (per company)
Starter50 rpm
Professional100 rpm
Enterprise200 rpm

On top of the per-minute limit there's a burst buffer equal to half your plan's limit; if you exhaust it, it takes about 10 minutes to replenish. Front also applies tighter resource-specific limits: 1 request every 3 seconds for analytics, 5 requests per second per route and resource (for example, repeated calls on one conversation), search capped at 40% of your main limit, 10 "message seen" requests per message per hour, and 60 app-object-link requests per 60 seconds. A search-heavy job hits its ceiling well before a simple read loop does. If 200 rpm isn't enough, Front sells an "API Rate Limit Increase" add-on at $200 per 100 requests/min per month, and its docs say increases beyond the defaults require Professional or higher. That pricing is the incentive to note: Front charges for headroom, so a well-behaved client that caches and uses webhooks is cheaper to run. (Current figures: Front's rate-limiting docs.)

Every response carries headers so you can throttle proactively rather than wait to be cut off: x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset (a UNIX timestamp for when the window resets, never more than a minute out), plus x-ratelimit-burst-limit and x-ratelimit-burst-remaining. Watch remaining and slow down before it hits zero.

When you do exceed the limit, Front returns HTTP 429 Too Many Requests with a retry-after header telling you how many seconds to wait. The correct pattern is to back off for exactly that long, then retry, ideally with exponential backoff and jitter if you run multiple workers. Build this in from day one; it's the most common thing that breaks naive integrations at scale.

Should you use webhooks or polling?

If you want to react to events rather than poll for them, use webhooks: Front sends a POST with the event's JSON to a URL you control whenever something happens. There are two ways to wire them up:

  • Rule webhooks: configured inside the Front app as a rule ("when a conversation is tagged urgent, call this URL"). Good for getting started and for testing, and they work on private or shared inboxes; you don't need a server ready at configuration time.
  • Application webhooks: added as a feature of a published app; recommended for partner integrations because end users don't have to configure anything. These operate on shared inboxes.

Either way, webhooks are the right call for near-real-time sync; reserve polling for backfills and reconciliation, where it keeps you well inside the rate limit. (Note that "mass action" events, like moving inbox content between teams, aren't delivered via webhooks.)

When should you use an AI agent layer instead of the raw API?

The API is the right tool when you want deterministic, programmatic control: syncing data, wiring Front into your own stack, or posting messages and notes from other systems. But a growing share of "API projects" are really "I want conversations triaged and answered automatically," which is a different shape of problem. Writing and maintaining that logic (classify the message, look up the customer, draft a reply, decide whether it's safe to send) is a real engineering commitment, and it gets brittle as your product and policies change.

Front itself now points in this direction: its MCP server (mcp.frontapp.com/mcp, in open beta) lets an AI agent search conversations, create drafts, post comments and change assignments over OAuth, with exactly the authorizing teammate's permissions. That's plumbing, though, not an agent. To be upfront: Macha is an AI agent layer that runs on top of Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom, so on Front this is a drop-in option rather than something you script yourself. The pattern is the relevant part: rather than scripting triage-and-reply against an API by hand, an agent layer reads from your help desk plus a connected knowledge base to triage, draft and resolve routine conversations, leaving anything it can't confidently handle for a human. (See Macha on Front for how the Front connector works.) The honest trade-offs are the same everywhere: it's another integration to configure, it's only as good as the knowledge you feed it, and billing is per ticket (one conversation, charged once however many steps it takes), never per resolution. You can try it free: it starts with $50 of free usage, no credit card required. If you'd rather stay hands-on, the right path is the API above or an off-the-shelf connector from the best Front integrations.

Frequently asked questions

What is the Front API base URL? Every request goes to a single host: https://api2.frontapp.com/. So conversations live at https://api2.frontapp.com/conversations. There's no per-account subdomain. (This is Front the customer-communication platform at front.com, not a frontend/web API.)

Does the Front API use an API token or OAuth? Both end in a Bearer token. For your own internal scripts and services, create an API token under Settings → Developers → API Tokens (admins only) and send it as Authorization: Bearer {token}. For apps distributed to other Front companies, Front requires OAuth unless you have an exception.

How do I get a Front API token? In the Front app, go to Settings → Developers, open the API Tokens tab, click Create API token, give it a descriptive name, choose its features/namespaces/permissions (scopes), and create it. Only administrators can do this. Deleting a token revokes it immediately and irreversibly.

How do I send a message with the Front API? POST to https://api2.frontapp.com/channels/{channel_id}/messages with at least to (an array of recipients) and body; add author_id to send as a specific teammate. JSON works for plain messages; use multipart/form-data when you need attachments.

What are the Front API rate limits? They're per company (shared across all tokens) and tiered by plan: 50 rpm on Starter, 100 on Professional, 200 on Enterprise, plus a burst buffer of half your limit. Heavier endpoints have their own caps (analytics 1 request every 3 seconds; 5 requests per second per route and resource; search 40% of the main limit). Extra headroom costs $200 per 100 requests/min per month. On a 429, wait the number of seconds in the retry-after header. Confirm current figures in Front's docs.

How do I paginate Front API results? Front uses cursor pagination. Pass limit (default 50, max 100) and then follow _pagination.next, a full URL with the page token baked in, until it returns null. Don't rely on result counts.

Does Front have an MCP server for AI agents? Yes, in open beta. It lives at https://mcp.frontapp.com/mcp, authenticates with OAuth 2.1 and PKCE per teammate, and lets an agent search conversations, create drafts, post internal comments and update status or assignment, limited to the authorizing teammate's permissions.

What trips people up with the Front API?

Three things catch most first integrations. Token scope: an API token created with only Read permission fails on the first POST, so choose Read, Write or Send deliberately (Settings → Developers → API Tokens, admins only), and use OAuth for anything you distribute. Pagination: follow _pagination.next until it's null rather than counting rows. The per-company rate limit: every token on the account shares the 50, 100 or 200 rpm pool, so a nightly backfill can starve a live webhook handler; honor retry-after on a 429 and keep polling for reconciliation only. From here, see what Front is for the product overview, or the best Front integrations if you'd rather connect a tool than write code.

Front Core API details checked against Front's developer documentation (dev.frontapp.com) on 24 September 2026. Front updates its API periodically, so confirm endpoints, limits and field values in the live docs before relying on them.

Macha

About Macha

Macha is an AI agent platform that works on top of the help desk you already use — Zendesk, Freshdesk, Gorgias, or Front — and connects to the rest of your stack, even your own internal systems. Its AI agents resolve tickets and automate entire workflows end to end, all set up in plain English, no code. Learn more about Macha →

Zendesk
5.0 on Zendesk Marketplace

Loved by support teams worldwide

See what support teams are saying about Macha AI.

The application seems excellent to me! We are still testing, and we need support for some details and they were extremely efficient too!

Daniela Costa

Daniela Costa

Head of Support, Seabra

Macha has been a great addition to our support toolkit. It generates clear, well-organized responses that fit naturally into our workflow. One feature we particularly appreciate is its ability to automatically reply in the same language as the ticket.

Marius F

Marius F

Support Head, Zentana

We've been using Macha for a little while now and it's been really great addition so far! It's powerful, convenient, and makes getting work done a lot easier for our agents.

Alexander Wedén

Alexander Wedén

Head of Support

Support team is very helpful and responsive. Really enjoy how lightweight this is within Zendesk itself vs other more intrusive tools.

Cathleen Wright

Cathleen Wright

Zendesk Admin, Cortex IO

So far it's pretty good! Our queries are a little nuanced, so we can't always use it, but it's got enough utility for us. It can even incorporate our bilingual country with greetings in a second language.

Jae Oliver

Jae Oliver

Head of Support, Wise

Really enjoying using Macha, it has made a noticeable difference to our support team in a short amount of time. I really like the ticket summary feature, saves us a lot of time.

Harry Jackson

Harry Jackson

Head of Support, Crumb

Macha AI is a great addition to my workspace! It's powerful, convenient, and it really makes productivity so much easier for our agents!

Dave G

Dave G

Head of Support, Cyber Power Systems

Very impressed! AI integration for Zendesk has certainly come a long way and Macha seems to set the standard for now. This will for sure save lot of time in our support team.

Pauli Juel

Pauli Juel

Head of CS, Dokument24

Macha has been working great for us so far! The auto-responses are accurate and our resolution time has dropped significantly.

Lana T

Lana T

Zendesk Admin, Swotzy

Macha AI is a great addition. The knowledge base feature means our agents always have the right answers at their fingertips.

Mischa Wolf

Mischa Wolf

Head of Support, Topi

We're enjoying this integration so far. It's made our support team more efficient and our customers get faster responses.

Paula G

Paula G

Head of Customer Support, Xly Studio

The team enjoys using it. It saves considerable time on common questions and the integration options are excellent.

Kilian Leister

Kilian Leister

Support Head, Didriksons

Ready to supercharge your team with AI?

Get started in minutes. Connect your tools, configure your agents, and let AI handle the rest.

$50 in free credits · no time limit, no credit card