API overview
Integrate against the published contract: versioned OpenAPI documents and canonical JSON schemas.
Why a published contract
Vision Scan is preparing deterministic, versioned OpenAPI contracts. Publishing the specification document and canonical JSON reference will mean integrators build against the same definition the product ships with — no reverse engineering, no drift between environments.
What is published
Each release will publish a deterministic OpenAPI v1 document plus canonical JSON schemas for the payloads it exchanges. The artifacts will carry content hashes so consumers can verify they are building against an unchanged contract.
What the API does
The Vision Scan API is the server-side integration surface. Backend systems — your receiving and inventory integrations, or middleware you operate — call the API so Vision Scan data flows into the systems you already run, without a device in the loop.
When to use the API vs the SDK
Use the SDK when the work happens on a device — capture, decode, and on-device scan observations for Android and Zebra hardware. Use this API when the work happens off-device — backend integrations and the versioned contract your systems integrate against; the SDK overview owns platform selection.
Requests & responses
Every call follows the same path from your integration to a structured answer. The lifecycle below is the concept — field-level details live in the versioned spec for your release.
When a call fails, the response is an RFC 9457 problem document — never an invented shape. Branch on the document's stable code: every failure maps to a closed set of error states, and each state carries a caller action. The lifecycle image above shows the same branch: a successful response, or guidance for the caller. The Error concepts section explains the document itself.
Get the generated spec
This page does not hand-maintain endpoint listings — the generated OpenAPI v1 document for your release is the reference. It is published deterministically per release and pinned by hash for reproducible integrations.
Sign in to open the developer portal for the current versioned API artifacts for your tenant.
Authentication
API access is tenant-scoped through the developer portal: keys and versioned API artifacts live behind sign-in, and the public documentation never carries credentials. Sign in to manage API keys. Never package a bearer token in resources, logs, or the APK.
The customer-integration contract groups operations by access level: anonymous covers sign-in only, bearer carries the tenant-scoped operations, and a separate level covers SDK artifact downloads. The portal developer surfaces are sign-in gated — tenant identity always comes from the authenticated session, never from a client-supplied value.
Versioning
Integration stays on versioned contracts: the public API, the SDK public contracts, the customer-integration surface, and the license envelope are each versioned. Pin the contract version for the release you deploy — the artifacts carry content hashes so you can verify nothing changed under you. Breaking changes follow a documented migration window; additive changes land without breaking existing consumers.
Error concepts
API errors are reported as RFC 9457 problem documents carrying a stable machine-readable code and a correlationId you can include when you contact support. Branch on the code to decide what to do next — the code is the stable part of the contract, not the human-readable message. The exact error shape for the release you deploy is pinned by the generated OpenAPI document — this page intentionally does not hand-list it. The diagram in Requests & responses shows how a code becomes an error state and then a caller action.
API reference
The complete, generated API reference is being prepared. When published, it will be the deterministic, hash-pinned OpenAPI document for your release — and this page will never hand-list endpoints in the meantime.
Blocked on: generated per-release OpenAPI document — Backend/Platform
Available today:
Worked examples
Worked request/response examples for common receiving and inventory integrations are being prepared. Until they land, the sandbox demo and the cloud guides show real request/response shapes.
Blocked on: worked examples for common receiving and inventory integrations — Documentation
Available today:
Contract policies
Contract stability
Integration remains through versioned OpenAPI. Breaking changes follow a documented migration window; additive changes land without breaking existing consumers.
Deterministic generation
The published artifact will be generated deterministically each release, and its hash recorded so teams can pin the exact contract version they integrate against.
No source coupling
Consumers never depend on internal source code or database structures. The OpenAPI document and canonical JSON schemas are the complete, supported integration surface.