Developers

 Good morning,I’m trying to sync the Front conversation statuses in Front with our internal data so we can display them to our users in our app. We just need to get the Open/Waiting/Resolved value from the conversations. I'm playing with the application webhooks, as recommended in your docs, but I cannot find an event that reacts to a change in these statuses (there are some internal status changed events but for Waiting and Resolved are, internally, the same “archived” status so nothing triggers in this case). I’ve gone around this issue by creating a custom rule that adds a tag when the status changes so I can receive the “Tag added” event but then I’m getting a lot of events that are not actually changing the status… The other solution will be polling directly the API but given the API request per minute restriction, if the inflow of tickets grows it might not be realistic. Is there anything else we can do, or something that we are missing? Thanks in advance,Ruben

Hello we’ve just started using front and we don’t have the time to figure out what we don’t know what we don’t know. Is there a partner directory or anyone who’s doing consulting paid consulting?We’re an IT business and have no issues spending cash on software implementation but Front doesn’t seem to be offering this service. Please help it’s a fantastic tool I’m sure but oh boy it takes a while to figure things out!

Hello,For one of our mutual customer we are seeing that conversation events are missing from /events api call.While individual event exist when queried via /conversation/[id]/events endpoints.I have also checked it’s not a private resource. Also checked the api token access it’s all correct.I can share more details if we can start a thread around api call and conversation which is missincg, since it’s one of our mutual customers data I am not posting here our public forum.Let me know how to debug this.I have already created a support ticket.

Hi all, Not sure if this is the correct location for this. I run a Technical Support team and we have inbound via email and WhatsApp as well as Zoho CRM tasks.  Zoho Desk didn’t work out for us as it would not work with custom modules of CRM. We don’t a yet have a developer.  Front looks like it may suit us but we use personal email, shared team inboxes and we also use WhatsApp groups that involve the team but also customers in those groups. Can Front work with WhatsApp groups (as well as 1 to 1 WhatsApps) and Zoho tasks?

You can now subscribe to conversation lifecycle events in Autopilot Resolve, so your app can react in real time as end users move through a conversation, from starting a new one to escalating to a human teammate. Available event types:created: end user starts a new conversation viewed: end user opens or navigates to a conversation escalation_offered: Autopilot Resolve offers to hand off to a human escalated: the conversation is handed off escalation_declined: end user dismisses the offer status_changed: the conversation moves between open, in_progress, and resolvedThree ways to subscribe, depending on your setup:FrontCompanion.on(handler) for a synchronous listener that returns an unsubscribe function onConversationEvent as an option on init() to register in the same call A companion-conversation-event CustomEvent on window, which works even before the boot script has loadedCommon patterns include firing your own analytics when a conversation escalates, updating your UI when a new conv

You can now create application channels programmatically, without manual setup in the Front UI for every new channel your app needs. This unlocks fully automated provisioning flows so your integration can spin up channels as customers onboard or as new use cases emerge. POST /inboxes/:inbox_id/channels To create an application channel, send a request with:type set to custom application_uid set to the developer app that defines the channel credentials matching your application server's authentication type (API key, basic, bearer, or OAuth2 variants)For OAuth2 authorization_code flows, omit credentials and complete the OAuth flow interactively after the channel is created. Full parameter details, credential shapes, and examples are in the reference docs. Happy coding!

Setup: I sync messages from the Core API and process them downstream. For that I need just the new content of each message, not the quoted thread history, signatures or disclaimers.What the API gives me:- `body` - full HTML, including everything- `text` - plaintext rendering, also including everything- `blurb` - quote-free, but truncated, so usable as a signal at bestSo I'm parsing the HTML myself, and running into the usual wall: no standard for marking quoted content, every client does it differently, unclosed tags, tables used for layout. Forwards are the worst case, some clients wrap the entire forwarded message in a single blockquote, so naive stripping leaves an empty body.Front clearly handles this internally (collapsed quotes in the UI, the `front-quoted` class, rules that skip quoted text when matching conditions).1. Is that exposed anywhere I've overlooked, an endpoint, field, parameter, or a paid add-on? Happy to pay for it.2. If not, what are you all using? Interested in wh

Hi all,We're an AI agent provider integrating with our customers' Front instances. Our integration has two parts: (1) webhooks so we receive conversation events from each customer's instance, and (2) an embedded React app (plugin/iframe) that loads contextually in the Front sidebar.Today, onboarding each customer is manual: we ask each tenant to create/initialize a webhook app in their own instance, exchange credentials with us, and configure everything by hand. This is slow, error-prone, and doesn't scale.What we'd like instead:Ship our integration as a single installable Front application (ideally via the App Store or as a private/partner app). Customers install it and complete a short setup form; our backend receives the install, and we can approve or reject the tenant on our side. Webhook subscriptions and credential exchange are auto-configured per tenant on install (OAuth flow), rather than each customer manually creating webhook apps. The plugin (React iframe) ships as part of t

Hi Front team,We use the Front Chat widget with our knowledge base enabled inside it, and we'd like to extend the widget's in-app Help Center experience to article links that live elsewhere in our web app.Context on what we're doing:We've started adding contextual tooltips throughout our web app that link to the relevant Front KB article for each feature. This has been great for helping users understand features — especially newer ones — right at the point where they encounter them.The one bit of friction: those tooltip links open the article in a new browser tab, pulling the user out of our app. What we love about the widget's built-in Help Center is that when an article is linked inside the widget (from a chat reply, or from a link within another article), clicking it just opens the article in the Help Center tab of the widget. The user can read the full article, expand the widget for a better view, and follow along while staying in our app. That in-context experience is exactly what

 We've added a new set of API endpoints and settings designed specifically for building voice call integrations in Front. If you're building a telephony integration or looking to bring voice into your Front workflows, here's what's new.New API endpointsThe Channel API now includes dedicated endpoints for voice calls:Create a call Update call status Add a call transcript Add a call summary Add a call recordingCall state managementVoice channels support a full call lifecycle — from ringing and queued to connected, hold, transferred, hangup, missed, and abandoned — with defined valid transitions between each state so your integration can handle any scenario cleanly.There are also related call events.App configurationVoice integrations are built on top of application channels, with a few voice-specific settings to configure:Use a Phone contact type when setting up your application channel feature Add a sidebar plugin feature to visualize calls and related assets — with support for incoming

With the Autopilot Resolve SDK, you can take complete control over the Autopilot Resolve widget on your websites. The widget answers customer questions using your Front knowledge sources and Playbooks, and escalates to a human agent when needed. The Autopilot Resolve SDK gives you more advanced control compared to the default JavaScript snippet. It allows you to mount the widget in a container element, pass customer context to the AI, manage visibility, and handle identity verification for logged-in users in ways that you can more deeply customize. The SDK is intended for cases where you need more control, like single-page apps, custom launcher buttons, dynamic context updates, or programmatic show/hide behavior.Get started on our Developer Portal.Happy coding!

We're building a way for external AI agents to operate as real teammates inside Front — assigned conversations, their own identity, clean handoffs to humans, and @mention support. No more webhook workarounds or human accounts standing in as proxies. If you've already built an agent or are actively working on one, we want to hear from you. We're in early development and looking to understand real use cases before we build. Interested? Join our beta group to get started.

Task conversations are now fully supported in the Core API. You can create, read, and update them just like you can other conversation types, with a dedicated description field for capturing the context of the task. To learn more about how tasks work in Front, refer to our Help Center.POST /conversationstype now accepts 'task' in addition to 'discussion' The subject field provides the title of the task comment is optional for tasks and required for discussions New optional description field, valid only when type is 'task'GET /conversations/:conversation_idResponse now includes a type field returning 'conversation', 'discussion', or 'task' Response includes a nullable description field, present only on task conversationsPATCH /conversations/:conversation_idNew description field to set or clear (null) the task descriptionGive it a spin and let us know what you build!Happy coding!

It appears like Model Context Protocol (MCP) is the protocol that everyone is moving towards as it puts the burden of keeping everything “tidy” on the service provider rather than the client.  There are already many official MCP servers available and more on the way. There are also community developed ones. Is anyone else exploring this?Cheers!

I love the new knowledge base integration with AI, but I’d like to add additional context to the AI based on the user submitted message the AI is looking at.Having the AI have access to our MCP server means it can look up specific information about the user requesting help as well as access documentation.Is that a possibility?  I couldn’t find a good approach using Connectors.

UPDATE: There’s a new version of the MCP server. Please join the following group to learn how to get started: https://community.front.com/groups/beta-mcp-server-83The data access note for the original MCP server does not apply to the new one linked above. We're excited to announce the beta release of the Front MCP server — and we'd love for you to try it.Model Context Protocol (MCP) is an open standard that lets AI applications securely connect to external data sources and tools. With the Front MCP server, AI-powered tools like Claude, Cursor, Windsurf, and others can interact directly with your Front account and API documentation using natural language — no manual API calls required.What does that look like in practice?Ask your AI assistant to pull open conversations from a specific inbox, then tag or triage them Query your Front account data in real time to inform what you're building Explore Front's API endpoints and get full details about specific ones — without digging through doc

Hi,                                                                                                               Trying to figure out how to create and manage Sequences via API and coming up empty. The public Core API spec has no sequences paths, the dev portal reference doesn't mention them, and there's nothing in the changelog.A bit disappointed we are not being able to drive them programmatically. This means we either keep humans clicking through the UI or rebuild a sequencing engine on top of public primitives. Both of which are worse than a thin API wrapper would be.A few questions:Are sequence endpoints available on any plan tier or beta that's just not in the public spec? Is there a roadmap item or feature request to track / +1? If sequences endpoints aren't coming, what's the recommended composition for sequence-like workflows in their absence?

We've added a set of Time Off API endpoints to help you build integrations that stay in sync with teammate availability in Front. What is Time Off?A time off represents a scheduled out-of-office period for a teammate in Front. While active, the teammate's status switches to Out of office and any configured auto-responder starts replying to inbound messages on their behalf. When the period ends, their status returns to Available automatically. What you can buildThe Time Off API lets you read and manage these scheduled periods programmatically. A few example use cases:Surface upcoming absences in a workforce management tool Sync time off data with your HRIS Skip unavailable teammates when routing work from an external systemEndpointsGet time off List teammate time offs List team time offs Create time off Update time off Delete time offFor full reference docs, check out our Developer Portal.For an end-user overview of how time off works in Front, see Time off in the Help Center. Happy cod

We have a use case where we have a unique id, e.g. 12345, for each customer case and we want to have a unique email address with that id, e.g. 12345@cases.example.com, that a customer can send emails to when they have queries. We have setup the inbound flow so customers can send us emails to the unique email address and we can see them in the Front inbox, however, we can’t seem to be able to specify we are replying from that unique email address or set the reply to header to be that unique email address. This breaks our workflow. Is there any way around this?

Hi all, I’m struggling with something….I have a conversation custom field “Shipment Number” and an app object which is basically just a URL.I want to append the shipment number to the URL. Then I can create rules to populate this object when Shipment number is filled in.Is this possible?

Hi friends!I am implementing a custom solution and need to be able to search and identify contacts on Front with their phone number.I have tried https://api2.frontapp.com/contacts/alt:phone:[Number] returns an exact result if the number exists. However in many cases the number doesn’t exist and it return a 404 error which causes the custom template I am building to crash.I have also tried https://api2.frontapp.com/contacts?q=[Number] but the problem is that the query is ignored and all the contacts we have are returned every time and these contacts have no connection to the query. This is really not helpful. If this endpoint can return only contacts that have the query as a handle or name, that will be a lot more helpful.Has anyone had a reason to do something similar or is there anything I must have missed with searching contacts with the query method?