For developers and AI builders
Zoopit is API-first: orders, routes, activities and planning runs are all reachable over HTTP and described by OpenAPI. That makes Zoopit a straightforward system to hand to an AI agent, whether you are building an operations copilot, an automated order intake, or a planning assistant.
This page is the setup path for connecting your own agent to your Zoopit data. If you are instead looking for information for LLM crawlers and assistants answering questions about Zoopit as a company, see AI & LLM information.
What teams build with agents on Zoopit
Operations copilot
Ask about today in plain language: which orders are unassigned, which routes are running late, what changed since this morning.
Automated order intake
Let an agent read incoming orders from email, ERP exports or a webshop and create them in Zoopit with the right constraints.
Planning assistant
Trigger optimization runs, compare the result against the current plan, and hand a proposal back to a human planner for approval.
Before you start
- A Zoopit account with a project. Every entity in Zoopit belongs to a project, also referred to as
owners, and that is what scopes your agent access. - A Bearer token issued from the Zoopit dashboard. Tokens carry the scopes and roles of the project they were issued for.
- An agent runtime that can call HTTP APIs, for example the Claude or OpenAI SDKs, an agent framework of your choice, or your own code.
Zoopit services are served from subdomains under *.cloud.zoopit.no. The two you need for most agent work are orders-api.cloud.zoopit.no og routes-api.cloud.zoopit.no.
Set up in five steps
Issue a dedicated API token
Create a separate token for the agent rather than reusing a personal or integration token. Give it only the scopes the agent needs, and start read-only: you can always widen the scopes once the agent behaves the way you expect. Keep the token in your secret store or environment, never in the prompt or in the agent transcript.
Authentication and the project and scope model are described in the API reference.
Point the agent at the API description
Both services publish a machine-readable API description in Swagger 2.0 format, also known as OpenAPI 2.0. Agent frameworks and OpenAPI-to-MCP bridges that read that version can turn each operation into a callable tool directly. Tooling that only accepts OpenAPI 3.x needs a conversion step first.
Orders API description
https://orders-api.cloud.zoopit.no/public/docs/json
Routes API description
https://routes-api.cloud.zoopit.no/public/docs/jsonHuman-readable versions of the same documents live at docs.cloud.zoopit.no/orders-api og docs.cloud.zoopit.no/routes-api. The full descriptions are large, so for a focused agent it is usually better to expose a handful of operations as tools than to load every endpoint.
Make the first authenticated call
Every request carries the token as a Bearer credential. A call without a valid token is rejected with 401 Unauthorized, which is also the fastest way to check that your token reached the API.
curl -H "Authorization: Bearer $ZOOPIT_TOKEN" "https://orders-api.cloud.zoopit.no/v1/orders?limit=5"Responses are grouped into resource og related. The resource field holds the entity you asked for; related holds referenced entities such as locations, activities and consignments so the agent does not have to make a second round of lookups. Teach your agent to read both, and to quote the entity id in its answers.
Choose the tools your agent gets
A small, well-named tool set beats a full API surface. These are the operations most agents start with.
| What the agent needs | Endpoint | Service |
|---|---|---|
| List and filter orders | GET /v1/orders | orders-api |
| Look up one order | GET /v1/orders/{order_id} | orders-api |
| Delivery status across orders | GET /v1/orders/status | orders-api |
| Create an order | POST /v1/orders | orders-api |
| Consignments, tasks and bookings | GET /v1/consignments, GET /v1/tasks, GET /v1/bookings | orders-api |
| List routes and one route | GET /v1/routes, GET /v1/routes/{route_id} | routes-api |
| Stops and activities on a route | GET /v1/activities | routes-api |
| Run an optimization | POST /v1/routes/solve, POST /v1/routes/solve/async | routes-api |
| Follow a planning run | GET /v1/planner_requests | routes-api |
List endpoints share the same query conventions: limit og offset for paging, where for filtering, order for sorting and select for choosing fields. Have the agent pass select with only the fields it needs, and always cap limit so a single answer cannot pull thousands of rows into the context window. Parameter formats are documented per endpoint in the API reference.
Ground the agent, then constrain it
Give the agent a short operating brief alongside the tools. Something close to this works well as a starting point.
You have read-only access to the Zoopit Orders and Routes APIs
for one project. Use the tools to answer questions about orders,
routes and delivery status.
Rules:
- Never invent order ids, route ids or delivery times. If the
data is not in a tool result, say so.
- Always cite the order or route id behind a claim.
- Ask for a limit or a date range before listing large sets.
- If a call returns 401 or 403, stop and report it. Do not retry
with different credentials.
- Route changes and new orders require human approval before
you call a write endpoint.For public-web context about Zoopit itself, the site also publishes /llms.txt og /ai.txt.
Guardrails worth setting on day one
- Read before write. Start the agent with read-only scopes. Add write access one endpoint at a time, once you trust the behaviour.
- One token per agent. Separate tokens make it possible to see what the agent did, and to revoke it without breaking your other integrations.
- Human in the loop for planning. Optimization runs and order creation change real work in the field. Keep a person between the agent proposal and the dispatched plan.
- Page, do not scrape. Use
limit,offsetogwhereto fetch what the task needs instead of pulling whole tables into the model context. - Log the calls. Store the requests and responses your agent makes. When an answer looks wrong, the tool trace is where you find out why.
Getting help
The API documentation is at docs.cloud.zoopit.no. If you are planning an agent integration and want to talk it through, or you need a specific endpoint or scope that does not exist yet, get in touch and we will help you scope it.