Rentals API
Equipment and vehicle rental: rental orders, pickup and return handling, branches, webhooks and bots.
Root types are RentalQuery and RentalMutation.
Start with Authentication.
Profile and settings
profile returns the authenticated vendor's profile; settings returns the
settings blob. Both are read-only through this API.
Rental orders
Cursor-paginated, filterable by locationId and status. Note status is a
plain String, not an enum — valid values are not published in the schema.
The rental lifecycle
| Mutation | Effect |
|---|---|
Record collection. Condition report is optional | |
Extend the return date | |
Record return. Condition report is required | |
Cancel; reason is required |
The asymmetry on condition reports is deliberate: you may record a pickup without documenting condition, but a return must always carry one. That report is your evidence in a damage dispute, so capture it properly at both ends.
newEndDate is a NaiveDate — a calendar date with no timezone, YYYY-MM-DD.
Rental settings
Returns your rental configuration, or null if none is set.
Creates or replaces the settings — there is no partial update, so send the complete object.
Coupons
Discount codes that run on your own storefront.
| Operation | Notes |
|---|---|
The coupons you own. Not paginated | |
The code must be unique across the platform | |
Change a coupon you own | |
Delete a coupon you own |
vendorCoupons lists only the coupons your vendor owns. Platform coupons your
storefront happens to qualify for are not included, and cannot be changed
here.
A code is unique across the whole platform, not just your storefront, so
createVendorCoupon rejects a code another vendor already uses.
discount is a percentage when percentage is true and a fixed amount
otherwise, and it can never be negative. maxCouponAmount caps a percentage
discount and is ignored for a fixed one. minOrderAmount is in your currency.
All three are Decimal — a string on the wire.
productIds and vendorLocationIds narrow where the coupon applies; an empty
list means all of your products, or all of your locations. On
updateVendorCoupon either list replaces the existing restriction outright,
and an empty list clears it. times caps redemptions across all customers.
expiresOn is UTC; omit it for a coupon that never expires.
The three coupon mutations need vendors:promotions:write, which a coarse
vendors grant does not include. Request it by name — see
Authentication.
Reviews and performance
Read-only figures on how your business is doing.
| Operation | Notes |
|---|---|
Sales, top products and trends for a window | |
Acceptance, delivery success, timing and rating | |
Most recent reviews first |
The two analytics queries need vendors:analytics:read; vendorReviews needs
vendors:reviews:read. See Authentication.
Sales analytics
period and date are plain Strings, not enums, so a typo is not caught
by query validation.
period | Window |
|---|---|
today | From midnight in your timezone until now |
week | The last 7 days, ending now |
month | The last 30 days, ending now. The default |
year | The last 365 days, ending now |
Any other value | The single day named by date, in your timezone |
For a single day, pass date — YYYY-MM-DD or an RFC 3339 timestamp —
together with a period that is none of the four names. An unknown period
without a usable date is rejected rather than widened to all time. Passing
date on its own does not work: period then defaults to month, and
date is ignored.
Your timezone is that of your location with the lowest ID, or UTC if you have no locations.
In topProducts, up to ten products are ranked by revenue. In trends:
dailySaleshas one entry per day that saw a counted order, in date order. Days without one are skipped, and entries carry no date, so the series is not continuous.growthRateis the percentage change against the preceding window of the same length. It reads0when that window sold nothing.peakHoursholds up to three hours of the day (0–23, your timezone), busiest first.
Sales figures and the order-based performance metrics are computed from platform orders in a delivered state, reading up to 10,000 per window. This API does not document whether or how your rental orders count towards them, so reconcile the figures against your own records before relying on them. Verified against the backend source as of 2026-09-17; tracked in backend#909.
Performance metrics
vendorPerformanceMetrics takes no
arguments, and its order figures cover the last 30 days.
orderAcceptanceRate and deliverySuccessRate are percentages, 0–100.
avgPreparationTime is the average number of minutes from order creation to
delivery, across delivered orders. Despite the name, it is not preparation
time.
customerSatisfaction is your average star rating out of 5. It is averaged
over all of your reviews, not only the last 30 days.
Every figure reads 0 both when there is nothing to measure and when it could
not be worked out, so a 0 is not proof of a real zero.
Reviews
vendorReviews returns your most recent reviews
first. limit defaults to 20 and is capped at 100; the response's limit
echoes the value applied. There is no pagination, so reviews past the cap
cannot be reached. ratingFilter keeps a single star rating, 1 to 5, and any
other value is rejected.
A review's date is YYYY-MM-DD HH:MM:SS in UTC, not RFC 3339. orderId is
0 when the review is not tied to an order, and comment is empty when the
customer left a rating without words.
Locations
Your branches.
Cursor-paginated.
location(locationId:) fetches one. createLocation, updateLocation and
deleteLocation manage them; delete returns true.
To stop trading at a branch temporarily, deactivate via updateLocation rather
than deleting — deletion loses the association with historical records.
Webhooks
The alternative to polling. There are no GraphQL subscriptions, and polling for new rentals every few seconds will exhaust your rate limit.
webhooks(first:, after:) lists them.
webhook(webhookId:) fetches one. updateWebhook and deleteWebhook manage
them; set isActive: false to pause without losing configuration.
events is the WebhookEvent enum, so a typo is now a query validation error
rather than a subscription that silently never fires.
| Group | Values |
|---|---|
Orders | ORDER_CREATED, ORDER_UPDATED, ORDER_ASSIGNED, ORDER_CANCELLED, ORDER_COMPLETED |
Bookings | BOOKING_CREATED, BOOKING_CONFIRMED, BOOKING_CANCELLED, BOOKING_COMPLETED |
Payments | PAYMENT_RECEIVED, PAYMENT_REFUNDED |
Catalogue and customers | PRODUCT_LOW_STOCK, REVIEW_CREATED, CUSTOMER_MESSAGE |
Autonomous units | UNIT_REGISTERED, UNIT_VERIFIED, UNIT_ASSIGNED, UNIT_STATUS_CHANGED, UNIT_DELIVERY_COMPLETED, UNIT_MAINTENANCE_REQUIRED, UNIT_TELEMETRY_ALERT |
The enum lists values this vertical will never emit. Subscribing to one is accepted and simply never fires.
The enum spelling and the wire spelling differ. On the wire an event is
dot-separated — ORDER_CREATED is delivered as order.created — and that is
what the X-Kesk-Event header carries, what the payload's eventType key
holds, and what is stored against the subscription. The underscored form exists
only because a GraphQL enum value cannot contain a dot. Match on the header
value you actually receive rather than deriving it from the enum name.
Verifying deliveries
| Header | Contents |
|---|---|
X-Kesk-Signature | HMAC-SHA256(secret, raw_request_body), lowercase hex, no prefix |
X-Kesk-Event | The event's wire name, e.g. order.created |
The body is the event's fields plus an eventType key naming the event.
Sign the raw bytes. Parsing the JSON and re-stringifying it changes key order or whitespace, and every valid delivery will fail.
Deliveries time out after 10 seconds and are attempted at most 3 times, retrying 30 seconds after the first failure and 5 minutes after the second. A non-2xx response, a timeout and a transport error all count as failures. Redirects are not followed — point the webhook at its final URL.
Return 2xx as soon as you have durably accepted the event, then process
asynchronously. Be idempotent — retries mean you will see events more than once.
When a delivery exhausts its three attempts the webhook is disabled —
isActive flips to false and it stops receiving events entirely until you
re-enable it. An endpoint that is down long enough does not just miss those
deliveries; it stops being a webhook. Monitor isActive.
Every attempt is recorded with its request body, response status and failure reason. Response bodies are not retained.
Getting the signing secret
createWebhook does not return a signing secret. Call
regenerateWebhookSecret(webhookId:) once after registering to obtain it —
that is the only time it is shown. Until you do, you have a webhook whose
deliveries you cannot verify.
The same mutation rotates the secret later. The value is stored hashed and cannot be retrieved again.
Bots
Automations registered against your account.
BotType: WEBHOOK, SCRIPTED, AI_POWERED.
BotStatus: ACTIVE, INACTIVE, SUSPENDED, PENDING_REVIEW.
| Operation | Notes |
|---|---|
Permissions, version and tags are not editable afterwards | |
Cannot change permissions, version or tags | |
Permanent | |
Queue a test delivery to a WEBHOOK bot | |
Rotate, returns the new secret | |
Totals, webhook health, daily series. days defaults to 7, max 90 |
Reference
Generated reference — every type, field and argument, built from the live schema.