Developer and API document
The authentication model, what the API surface covers, the webhook trust model, and device certificates.
One dashboard for your whole fleet.
The API is how you will judge us, so here it is at the level that matters before you sign: what a token can do, what the surface covers, how to trust a webhook, and how a robot proves itself.
1Authentication
Your team issues and revokes API tokens from the account area, each scoped to what it may do. Tokens are scoped by ability, so an integration only ever has the access it needs.
A request that presents a token without the required ability is refused outright, with a message naming the ability it lacked.
2The API surface
The platform exposes a versioned REST API covering fleet management, telemetry, behaviours and device certificates. The full endpoint, request and response reference is issued with your integration credentials.
3Webhooks
Three events are published today: robot.status_changed, alert.raised and rollout.completed. Each endpoint you register has its own secret, shown once when it is created or rotated.
Every delivery is signed so you can verify it came from us, and every outbound request is checked against SSRF safeguards before it leaves the platform.
4Device certificates
A robot does not hold a token. It authenticates with an X.509 certificate over mutual TLS, bound to the device and to its tenant. Certificates rotate without downtime and are revoked immediately if compromised.
- Key
- A step, a state, a period of service
- Key
- A certificate that authenticates today
- Key
- The grace window — both certificates valid
- Key
- Annotation and window edges
A robot does not log in with a password. It is registered, issued its own certificate and key pair, bound to that certificate, and given a policy saying what it is allowed to do. Only then can it connect. Those five steps are the top register.
The middle register is the part that matters, and it is the reason the drawing exists. Rotation is not a cutover. The certificate already in service is given an end to its grace period first, and only then is the replacement issued and bound to the same device. For the length of the window both certificates authenticate, so the robot is never in a moment where its old credential has stopped working and its new one has not started. That overlap is what "no downtime" means here, and the bars are the claim rather than an illustration of it.
A certificate reaches the end of that window and is revoked by a scheduled sweep. A certificate believed to be compromised is revoked at once, without waiting for any window, and a revoked certificate cannot connect again.
Two states appear on this sheet because two states occur. There is no pending state and no inactive state. Expiry is enforced by refusing the connection rather than by relabelling the record, so it is not drawn as a state either.
The bars are marked not to scale. The certificate lifetime and the length of the grace window are configured values this company has not published, so this drawing carries no time axis and no durations rather than implying figures it has no licence to state.