An agent that only talks solves nothing. The REST APIs of your ERP, your EHR or your order system become tools the agent calls mid-conversation — and Hal-AI exposes its own public API so your team can build on top of the platform.
No proprietary connector required: if the system has a REST API, it is in.
Three routes into your stack
🔌
Your system's API
Endpoint, authentication headers and a description — and the agent starts querying and acting there.
🧩
MCP servers
Model Context Protocol configured per agent, alongside the REST APIs you registered.
🛠️
Hal-AI public API
Versioned REST, key-based authentication, per-resource scopes and published OpenAPI documentation.
Agent tools
Your system's APIs become the agent's tools
The agent is not handed an integration script. It is handed a list of tools described in plain language, and it decides at every turn of the conversation which one to call — if it needs to call any at all.
What you register
The endpoint — the URL of the REST call in your ERP, EHR, order system or internal system.
The authentication headers — whatever your system requires before it accepts the request.
The description — in plain language, what the call does and when it makes sense to use it. That description is how the agent picks the tool.
What changes in the conversation
A customer asks about an order; the agent queries the order system and answers with the real data. A patient asks for an appointment; the agent checks the calendar and offers what is actually open. Nothing branches inside a flow: the lookup is an action the agent takes, like any other.
The manager records the endpoint, the authentication and the tool description inside that agent's configuration.
2
The agent can now see the tool
The tool joins that agent's list — not the whole platform's. Every agent carries its own set.
3
Lookups and actions during service
The agent decides to call, reads your system's response and carries the conversation forward with the data in hand.
This is not a chatbot running a flow. It is an operational agent trained to do the work.
Endpoint importer
Integration starts with a conversation, not a project plan
Registering dozens of endpoints by hand is integrator work. Hal-AI handles it with a tool that reads the source documentation, lists what is there and implements the tools — checking in with the manager at every step.
1
Point to the source
The manager names the API documentation to connect. The Squad reads the source so nobody has to work through the docs line by line.
2
Review the endpoints it found
The Squad comes back with the list of available endpoints. The manager can ask anything about any of them and gets the details in writing.
3
Choose what makes the cut
Not everything the documentation exposes should become an agent tool. The manager sets the scope — what it can look up, what it can act on, what stays out.
4
The tools get implemented
The Squad implements the tools you chose and they start existing for the agent. What used to be a multi-week project becomes a conversation.
Once the importer is done, this is how the scope you chose shows up inside the agent's configuration: every approved endpoint becomes a tool with its own name, method, path and state. Alongside them sit the MCP servers connected to that agent and the platform's native tools that are switched on for it. Whatever was left out of the scope stays listed, dimmed, so nobody has to guess why the agent cannot do that.
Hal-AI · Agent tools and APIsConfiguration
Logistics Agent · Meridian TransportTools available to this agent during the conversation — system endpoints, MCP servers and native resources.+ Import endpoints
PersonalityMemoryAPIsMCPsWeb Chat Embed
Import finished24 endpoints read in the documentation · 5 implementedReview scopelist_source_endpoints → 24 routes · implement_squad_apis → 5 tools
Search tools by name or route…All 5Active 3Out of scope 1
Imported endpoints turned into agent tools
Tool
Method and path
State
api_get_order
GET /orders/{number}
Active
api_get_route_tracking
GET /routes/{route}/tracking
Active
api_get_delivery_window
GET /deliveries/windows
Active
api_post_reschedule
POST /deliveries/reschedule
In testing
api_del_order
DELETE /orders/{number}
Out of scope
AuthenticationHeader per environment — kept on the platform, never in the prompt text.
Description of api_get_route_trackingLooks up the current position and the next stop of a route.
Use it when the customer asks where their delivery is.
Never promise a time that is not in the route response.It is this plain-language description that makes the agent decide to call the tool — there is no flow chart or keyword behind it.
Connected MCP servers
Bound to this agent, not to the whole account. The tools each server exposes join the same list.
Customer question about Order 4471: the agent read the route, saw the delivery window and answered with the data from the system.
What you're looking at
Up top, the APIs tab open inside the configuration of a single agent, next to Personality, Memory and MCPs. The blue strip just below it is the importer's trail: 24 endpoints read in the documentation, 5 implemented, with the names of the two tools the Squad used to get there. Every row in the table is a tool with its method, path and state — active, in testing or out of scope — and underneath it sit the authentication field and the plain-language description the agent reads before it decides to call that endpoint.
The advantage
Everything that agent can reach fits on one screen: you can go through the inventory without opening code or a separate integration console, and you can see before the conversation happens that rescheduling is still in testing. The credential lives on the platform rather than in the prompt text, so rotating a key stops being a rewrite of instructions. And the MCP servers and the native tools show up in the same column, so nobody has to cross-check two settings pages to find out why the agent could not do something.
Only on Hal-AI
No integrator put this list together: a Squad read the documentation, listed the endpoints and implemented the ones the manager approved in conversation — the same self-configuration it uses to adjust its own context, knowledge and schedule. And the scope that comes out of that conversation is an allowlist: the DELETE that exists in the customer's API stays listed and switched off, because it never became a tool. In a flow-based automation, every call is drawn by hand in the editor, and what nobody drew is also something nobody can see.
Beyond REST APIs registered one at a time, the platform accepts MCP servers. The tools that server exposes become available to that agent during the conversation.
Per agent, not per account — your sales agent and your post-sales agent can point at different servers.
It coexists with REST APIs — the agent picks between the two tool sources based on what the task calls for.
An open standard — if your team already maintains an MCP server for internal use, it works here.
🧩
MCP servers
Configured per agent, with the tools the server exposes.
🔌
REST APIs
Your system's endpoints with authentication and a description.
🌐
Web reading
The agent opens a page and uses what it finds in the answer.
🔎
Internet search
Search as a tool, for when the answer does not live inside the company.
Hal-AI public API
The whole platform is an API too
Integration in the other direction: instead of the agent calling your system, your system drives the platform. The public API is REST, versioned under /api/v1 and authenticated by key.
How the API behaves
Versioned — the version lives in the path, so an evolution of the platform does not break the integration you shipped yesterday.
Per-resource scopes — each key enables only the resources you check off. A key that reads reports cannot send a message.
Idempotency key on sends — retrying the same request after a timeout does not deliver two messages to the customer.
Standard response envelope and pagination — the same shape across every resource, with pagination on list endpoints.
Rate limit per key — the limit follows the key, not the entire account.
Published OpenAPI/Swagger documentation — the API Keys and Documentation screens live inside the console, restricted to the company administrator.
A key's company is always the key's company: there is no company parameter that could be forged in a request.
Hal-AI · API keys and documentationCompany console
API keys · Meridian FreightScreen restricted to the company administrator. Each key enables only the scopes that are checked, and carries its own request limit.+ New key
API keysDocumentation
Public API v1OpenAPI specification published in the consoleOpen documentationbase /api/v1 · envelope { data, meta } · pagination on list endpoints
Key erp-integrationcustomers:readmessages:sendservice:transferteam:writePer-resource scopes: whatever is not checked gets refused, even if the path exists in the documentation.
Key exec-dashboardreports:readmessages:sendcampaigns:writeA key that reads reports cannot send a message. The request limit follows the key, not the entire account.
Recent calls to the public API, with method, path, key used, status and response time
Method and path
Key
Status
Time
POST /api/v1/messages
erp-integration
201
128 ms
POST /api/v1/messages
erp-integration
200 replayed
34 ms
GET /api/v1/customers?page=2
erp-integration
200
96 ms
GET /api/v1/reports/usage
exec-dashboard
200
210 ms
POST /api/v1/campaigns
exec-dashboard
403 scope
18 ms
POST /api/v1/squads/{squad}/run
erp-integration
202 running
72 ms
201 POST /api/v1/messages Idempotency-Key: order-4471-notice
09:41:02POST /api/v1/messages — key erp-integration09:41:02{ "data": { "id": "msg_8f21", "state": "queued" },09:41:02 "meta": { "request": "req_2c90", "replayed": false } }09:41:07Same idempotency key sent again — returned msg_8f21, "replayed": true09:42:15403 — the exec-dashboard key does not have the campaigns:write scope
The same envelope across every resource v1
Connected MCP servers
The outbound path: while your system drives the platform through the public API, the agents reach external tools through MCP servers linked to each agent.
The console's API keys screen, open next to the Documentation tab. Up top, two keys from the same company with different scopes: an ERP integration that reads customers and sends messages, and an executive key that only pulls reports. Below, the recent calls with method, path, key, status and time — plus a sample response with the data and meta envelope.
The advantage
The scope is checked on the key, not on the intent of whoever is calling: the attempt to create a campaign with the reports key comes back 403 in 18 ms and stays on the same list. And the idempotency key solves the classic sending problem: the retry after a timeout returned the same msg_8f21 with "replayed": true, instead of sending the customer two messages.
Only at Hal-AI
The last row on the list is what almost no customer service API exposes: POST /api/v1/squads/{squad}/run. Your system does not just fire off a message — it triggers a master agent and follows the run, the logs and the outcome the Squad itself declared when it finished.
What a key can reach
Resources exposed by the Hal-AI public API and what each one allows
Resource
What the key can do
Channels
List and create the company's channels.
Customers and messages
Read customers and message history.
Sending
Send messages and templates, with an idempotency key.
Service
Transfer and close chats, turn the bot on and off.
Team
Manage queues, operators and supervisors.
Campaigns
Create campaigns and track how they are running.
Content
Manage official templates and quick replies.
Reports
Pull reports and usage.
Squads
Trigger a Squad and follow the run, the logs and the outcome it declares.
Connected out of the box
The integrations the platform already ships with
Before any integration of your own, Hal-AI already talks to the infrastructure that holds customer service up: the official channel, email, telephony, billing and browser notifications.
Sending messages, media, interactive options, contacts and locations; official templates; number quality and health. WABAs and phone numbers are activated through Meta's Embedded Signup.
This is what exists in the platform today. Any other system comes in through a REST API registered as a tool or through an MCP server.
Frequently asked questions
What people usually ask about integration
Do I need a prebuilt connector for my system?
No. If your system exposes a REST API, that API becomes a tool the agent can use: you register the endpoint, the authentication headers and a description of what the call does. There is no fixed list of supported systems — an ERP, an EHR and an order system all come in the same way.
What is the endpoint importer?
It is a tool that reads a source's documentation, lists the available endpoints and implements the matching tools. A Squad does this in conversation with the manager: it explains every endpoint it finds, and the manager decides what the agent gets and what stays out.
Does Hal-AI support MCP servers?
Yes. Model Context Protocol servers are configured per agent, and the tools the server exposes become available to that agent during the conversation, alongside the REST APIs you registered.
Can the Hal-AI public API trigger a Squad?
Yes. Beyond channels, customers, messages, sending, queues, operators, campaigns, templates and reports, the public API exposes triggering a Squad and following the run, with the logs and the outcome the Squad itself declares. Keys and the OpenAPI documentation live in the console, restricted to the company administrator.
Bring us your API documentation and we will show you the agent using it
Our team walks through the systems the agent would need to query, what it could run on its own and what should still go through a person.