How to Use the Front API (2026): Auth, Endpoints & Examples

This guide walks through it in order. We'll cover what the Front Core API is, the base URL, how authentication works (the API token / Bearer method and OAuth for apps), the endpoints you'll actually use — conversations, messages, contacts, channels, inboxes, teammates, comments and drafts — plus cursor pagination, rate limits, webhooks, and copy-paste examples in curl, Python and Node. Details are verified against Front's developer docs as of June 2026 — Front revises the product periodically, so treat exact figures as "confirm in the live docs." 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.

What the Front Core API is

The Front Core API is a RESTful, JSON-over-HTTPS API — Front calls it their "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 to note: 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.

Front API authentication: 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 actually requires OAuth — not static tokens — when a partner integration makes updates on behalf of another Front customer's account, unless you've been granted an exception.

Getting 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 which features, namespaces and permissions (scopes) it can use — so 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.)

The endpoints you'll 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) — great 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:

Example: send a message with curl

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.)

Example: list conversations (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).

Example: create an internal comment (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);

Pagination

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

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:

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 on heavier endpoints — roughly 1 request/second for analytics, 5 requests per resource per second for conversations and messages, and search conversations is capped at ~40% of your global limit — so a search-heavy job hits a ceiling well before a simple read loop does. (Confirm current figures in Front's rate-limiting docs; they vary by plan and change over time.)

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), 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 single most common thing that breaks naive integrations at scale.

Webhooks and rules

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"). Great 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 you'd reach for an AI 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.

That's the gap an AI agent layer fills. To be upfront: Macha is an AI agent layer that runs on top of Zendesk and Freshdesk, and it does not currently integrate with Front — so if you're on Front, this isn't a drop-in option today. We mention it only because the pattern is relevant: 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. (We built this on Zendesk first — see Macha on Zendesk.) 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 AI action — each automated step — not per closed ticket. If and when you're on a supported help desk, you can try it free — 7-day free trial, no credit card required. For Front specifically, the right path today 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 — roughly ~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/sec; conversations/messages ~5 per resource per second; search ~40% of global). 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.

The bottom line

The Front (front.com) Core API is quick to get going once auth clicks: every call goes to https://api2.frontapp.com/, you authenticate with a Bearer token — an API token for your own integrations (Settings → Developers → API Tokens, admins only) or OAuth for apps you distribute — and you work with JSON resources for conversations, messages, contacts, channels, inboxes, teammates, comments and drafts. The three things that catch people are scoping the token correctly, the cursor pagination (follow _pagination.next until null), and the per-company rate limit (tiered by plan, with burst and resource-specific caps on top). Cache nothing you shouldn't, honor retry-after on a 429, and you can sync, send and update almost anything in your inbox. 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 verified against Front's developer documentation (dev.frontapp.com), June 2026. Front updates its API periodically — confirm endpoints, limits and field values in the live docs before relying on them.