Developers
Developer documentation
Each Hybot deployment serves its own interactive OpenAPI reference at the project's /docs path, because the authoritative contract is the one running against the project you integrate with. This page explains the shape of that surface: HTTP for commands, WebSocket for live state, and a vendor-agnostic robot abstraction underneath.
What the surface looks like
HTTP for commands
- Tasks are created and robots dispatched over HTTP. A direct dispatch to a named point of interest, for example, is a POST to /api/robots/{id}/go-to-poi — the same call the staff interface makes, because there is no privileged internal path.
WebSocket for live state
- Position, state and battery stream over WebSocket rather than being polled. If you are building a display, a dashboard or an alerting integration, this is the surface to attach to; polling the HTTP endpoints for the same data will be worse in every respect.
A vendor-agnostic robot abstraction
- Two implementations exist today: AutoXing Mars hardware via the AutoXing cloud API, and a full-fidelity mock used for demos and testing. Everything above the abstraction — queue, map, interface — is written against the interface, not the vendor.
A fleet that changes at runtime
- Robots can be added, removed and reloaded without restarting the server, and a misconfigured robot is skipped with a warning rather than taking the fleet down. Integrations should expect the fleet roster to change underneath them.
Before you integrate
Two pieces of context make the API make sense. The first is how tasks are assigned: the queue is re-scored continuously rather than matched once, so creating a task is a request for work to be done, not an instruction to a specific robot. The second is how service robots navigate, which sets out the division of responsibility between the platform and the robot itself.
If you are evaluating rather than building, the engineer-facing overview covers the architecture end to end, and the platform pages describe the three layers an integration sits between.
Frequently asked questions
Why is the full API reference not published on this site?
- Because a copy here would drift from the deployment you are actually calling. Each project serves interactive OpenAPI documentation at its own /docs path, generated from the code running there, which is the only version that can be trusted.
How does authentication work?
- JWT issued into HTTP-only cookies, with access and refresh tokens, and three roles: admin, operator and viewer. Role determines what an integration is allowed to do, so an integration that only reads fleet state does not need operator rights.
Can I add support for a robot you do not integrate with?
- The robot layer is an abstraction rather than a hard-coded vendor client, which is what makes another implementation possible in principle. Whether it is practical depends entirely on what the manufacturer's own interface exposes, so it is a conversation rather than a download.
Is there a simulator for development?
- Yes. A full-fidelity mock robot implements the same interface as physical hardware and is used for demos, training and testing. You can build and exercise an integration end to end without a robot in the room.
Talk to someone who built it
Integration scope depends on what your systems expose, so the useful first conversation is about your side rather than ours.