What can I do through the API?

Send a robot to a configured point of interest without creating a queued task, create and query tasks of the four supported types, read fleet and robot state, and subscribe over WebSocket to live position, battery and status updates as they change.

Am I coding against a specific robot vendor?

No. Hybot has a robot abstraction layer with per-vendor adapters behind it, so your integration targets Hybot's model of a robot rather than one manufacturer's protocol. Adding a supported model to a site should not require changes to your code.

Is there a way to develop without hardware?

There is a mock robot type in the integration layer, which exists precisely so the system can run without physical units attached. Ask us about access when you talk to us; what is available to an external developer depends on the engagement.

How does live state reach my application?

Over a WebSocket connection. Robot position and state are broadcast as they change rather than polled, which is what you want for a floor plan view or any UI that has to look truthful while a robot is moving.

Where is the documentation?

API documentation is published alongside the platform rather than on this marketing site, and access depends on the engagement. Tell us what you are building and we will point you at the right surface rather than handing over a link that may not apply.

Engineer or developer

Build on Hybot: the developer's view

Hybot exposes its robot fleet over a REST API and a WebSocket stream. You can dispatch a robot to a named point of interest, create and query tasks, and subscribe to live state, position and battery. The robot abstraction layer is vendor-agnostic, so integrations target Hybot rather than one manufacturer's protocol.

The shape of the thing

Hybot is a robot management platform with a real fleet under it, and the integration surface reflects that. Two channels:

REST for anything you want to cause. Dispatch a robot to a configured point of interest. Create a task of one of the four supported types — DELIVER_ORDER, GET_ORDER, DELIVER_BILL, COLLECT_DISHES. Query fleet and robot state.

WebSocket for anything you want to observe. Robot position, state and battery are broadcast as they change. If you are drawing a floor plan, you want the stream, not a polling loop that makes your UI lie for two seconds at a time.

Dispatch without a task

The smallest useful call sends a robot to a named point of interest and does not create a queued task at all. Most integrations start there, because it maps onto the thing people actually want first: "when X happens in my system, put a robot at Y".

Queued tasks are the other mode, and they go through the assignment loop — priority, distance and battery weighed together, re-scored every two seconds. Which you want depends on whether you are expressing an instruction or a request.

You are not coding against a robot vendor

There is a robot abstraction layer with per-vendor adapters behind it. Your integration targets Hybot's model of a robot — state, battery, position, a place to go, a task to run — and the adapter deals with the manufacturer.

The practical consequence: a site adding a different supported model should not break your integration, because your integration never knew which model it was talking to.

Developing without hardware

There is a mock robot type in the integration layer. It exists so the system can run end to end with nothing physical attached, which is how anybody sane develops against a fleet. What access looks like for an external developer depends on the engagement — ask us and we will tell you plainly rather than publishing a promise that may not apply to your case.

Things worth knowing before you design

A robot marked inactive still broadcasts its state but is skipped for auto-assignment. Visible is not the same as dispatchable.
A misconfigured robot is skipped at startup with a warning. The fleet comes up; that unit does not.
Robots can be added, removed and reloaded without a server restart.
Multi-step tasks can include a confirmation waypoint where the robot waits for a human. Your integration may need to model "waiting for a person" as a first-class state.

Where to go next

Other audiences: operators, researchers, the merely curious.

Frequently asked questions

What can I do through the API?: Send a robot to a configured point of interest without creating a queued task, create and query tasks of the four supported types, read fleet and robot state, and subscribe over WebSocket to live position, battery and status updates as they change.
Am I coding against a specific robot vendor?: No. Hybot has a robot abstraction layer with per-vendor adapters behind it, so your integration targets Hybot's model of a robot rather than one manufacturer's protocol. Adding a supported model to a site should not require changes to your code.
Is there a way to develop without hardware?: There is a mock robot type in the integration layer, which exists precisely so the system can run without physical units attached. Ask us about access when you talk to us; what is available to an external developer depends on the engagement.
How does live state reach my application?: Over a WebSocket connection. Robot position and state are broadcast as they change rather than polled, which is what you want for a floor plan view or any UI that has to look truthful while a robot is moving.
Where is the documentation?: API documentation is published alongside the platform rather than on this marketing site, and access depends on the engagement. Tell us what you are building and we will point you at the right surface rather than handing over a link that may not apply.

Where this fits

This page is part of Hybot for every audience. If you are working through the topic in order, these are the neighbouring pages.

Service robots for business operators
For the person who has to justify the spend: what a Hybot deployment actually involves, what we can measure, and the questions to ask before you sign anything.
Hybot for researchers and academics
A production service-robot fleet is an unusual research substrate: real venues, real interruptions, real people. What exists, and how collaboration works.
What is a service robot, and what do they do?
A plain explanation for the curious: what these robots do in restaurants and hotels, how they find their way, what they are bad at, and where to read more.

The next step from here

One conversation, routed to the person who can answer it rather than to a general inbox.

Read the developer docs