Gateway API
Put your records and Forest Actions inside Zendesk, in the app your ops vibecode for their team, or in any tool that can call an API.

TL;DR
The Gateway API puts your Forest records and actions inside any interface your ops work in: a helpdesk, a CRM, an internal portal or an app they vibecode.
Your ops can vibecode an interface for their team. It reads and writes your data and runs your actions, under each user's role.
Every call runs as the person or service account that made it, under the same roles and in the same activity log as the Forest UI.
Whatever interface your ops pick, it reads the same records and runs the same actions as the Forest UI, under the same rules. Your engineers build the screen and nothing behind it.
Find a customer and everything linked to them
The interface searches and filters records, then opens their relations: accounts, cards, past cases. One REST contract covers every collection.
Run the same actions
The refunds, freezes and status changes your engineers coded as Forest Actions run from the interface, with the same form and the same checks as in the Forest UI.
Write under the same rules
The interface creates and edits records, or runs an action. Every write is checked against the caller's role and lands in the activity log, like a change made in the Forest UI.
Each person works under their own role
Sign-in is per user, with their Forest account. Every call reaches your back-end as that person, so their role, permissions and scopes apply unchanged.
Scripts and integrations get their own identity
A nightly job or a server-to-server integration gets its own Forest identity, with a role and teams, authenticated by an application token. No shared credentials.
Build the screen with your AI coding tool
Turn on the OpenAPI document, and the AI coding tool drafting the interface builds against the real routes from the first prompt.


Where your ops work
Inside your helpdesk
Your support team sees the customer's records inside the ticket and runs actions from it. The Forest app for Zendesk already runs on the Gateway API, and suggests the actions that fit each ticket.
In the app your ops vibecode
An ops lead describes the review queue their team needs, an AI coding tool such as Lovable, Cursor or Claude Code builds it against the OpenAPI document, and an engineer allows its origin once. From the first login, it reads and acts under each user's role.
In any tool that calls an API
A CRM, an internal portal or a script calls the same routes with a user session or a service account token. A few lines of code connect it, and the rules stay in your back-end.
Forest everywhere
Frequently asked questions
You still have question ?
Book a conversation with a forest expert
What is the Gateway API?
It is the REST service of the Forest Gateway, served by your Forest back-end. Interfaces people click in use it to read and edit records, browse relations and run Forest Actions. AI agents connect to the other service of the same Gateway, the MCP server.
Which interfaces can use it today?
The Forest app for Zendesk runs on it out of the box. Any interface your team builds can call it from an allowed browser origin, and any server can call it with a service account token.
Can our ops vibecode an interface on it?
Yes. Turn on the OpenAPI document and hand it to your AI coding tool. An engineer adds the app's origin to the allowed list once, then each user signs in with their Forest account and works under their own role.
Can an interface change data without going through Forest's rules?
No. The Gateway API reads and edits records and runs your actions, and every call is checked against the caller's role and written to your activity log.
How do permissions work in an interface built on it?
Every call reaches your back-end as the signed-in user, or as the service account whose token it carries, and the answer is filtered by that identity's role. Your interface can hide a button; the back-end makes the decision.
Gateway API or MCP server: which one do I need?
The Gateway API serves interfaces people click in. The MCP server serves tools AI models call. Both ship in the Forest Gateway, apply the same roles and write to the same activity log, and you can turn on one or both.
Does it work with a Ruby back-end?
Yes, through the standalone Gateway, which serves the same routes from its own process. On a Node.js back-end, the Gateway runs inside the back-end itself.
Does customer data leave our environment?
The Gateway API runs with your Forest back-end, inside your infrastructure, and reads your databases in place. The AI relay behind suggested actions in Zendesk sends ticket fields and action names to Forest's AI proxy, never the records your team browses.
