Hosting a small API inside HighLevel with AI Studio

That makes AI Studio a place for a small piece of logic that sits beside the rest of a HighLevel build: a webhook receiver, a lookup, a calculation another tool needs. Below is how the two kinds of backend code differ, the build steps, and the checks to run before a customer or a call depends on the route.

REST routes and Server Functions do different jobs

AI Studio gives an app two kinds of backend code. Which one you use decides whether anything outside the app can reach it.

• REST routes expose endpoints to external services. A route can support GET or POST and return JSON, which is what most webhooks and integrations expect to receive.
• Server Functions serve the app's own frontend. They are for the screens inside your AI Studio app, not for a caller somewhere else.

If something outside the app has to call it, build a REST route.

Start from a new project

New AI Studio projects use TanStack Start. Projects built earlier on Vite and React are not migrated automatically, and they need their own migration before they work the new way.

If you have an older project and want a REST route in it, plan that migration as its own piece of work. For a small route on its own, a fresh project can be the simpler place to put it.

Build the route

Write the contract down before you prompt or code anything. It gives you something exact to test against later.

1. Create a new AI Studio project.
2. Specify the route's path, its method (GET or POST) and the exact payload it expects, field by field.
3. Put every API key and credential in Secrets. Nothing secret goes in frontend code.
4. Add an authentication check to the route, such as a shared secret the caller sends in a header, or signature validation if the caller signs its requests. The check runs before the route does any work.
5. Test with a valid request. Then test a missing secret, a wrong secret, the wrong method and a broken payload. Each bad request should be refused, not half processed.
6. Publish. Publishing deploys the app's runtime, so an unpublished change is one of the first things to rule out when a route misbehaves.

Keep secrets on the server side

Secrets exist so credentials stay out of the frontend. The mistake that undoes that is sending a secret back out: in a route's response, in an error message, or to a screen in the app, where anyone with a browser can read it.

Return only what the caller needs. If a route fetches data from another service with a key, send back the fields the caller asked for and nothing else. Never echo the key, the full upstream response or the request headers.

When a route fails

HighLevel's article names four things to check when an endpoint fails. Work through them in this order.

1. Path. The caller uses exactly the route's path.
2. Method. The caller sends GET or POST to match what the route supports.
3. Publication. The version with your latest change has been published.
4. Authentication. The caller sends the secret or signature the route checks for, in the place the route reads it from.

Time it before a live call waits on it

HighLevel's article doesn't document request timeouts, or how long a route takes to answer after the app has sat idle. If a voice agent or a person on a page will wait for the response, measure it yourself, several times and after a quiet spell, before anyone relies on it.

Plan what happens when the answer is late. A voice agent needs a line to say while it waits, or a way to carry on without the data. Check HighLevel's current terms for running AI Studio apps too, before you build something that gets called often.