Introduction

The Chargee Order API sits between your commerce or operations systems and Chargee’s fulfillment world. Its job is to turn “we sold something that must ship from Monta” into a tracked order Chargee understands — and, when that order is fulfilled, to help physical Sparky devices land in the right Chargee group.

What problem it solves

Warehouse fulfillment for Chargee products typically runs through Monta. Chargee also needs a reliable local picture of those orders: status, serial numbers (box codes), and ownership per merchant account. Separately, when devices ship, Chargee wants them attached to the merchant’s Amber group so the rest of the platform can work with them.

Without a dedicated Order API, every integrator would have to speak Monta’s dialect, store fulfillment state themselves, and wire device linking by hand. This API centralizes that: authenticate as a Chargee merchant, create or import orders, keep status in sync, and let Chargee handle the fulfillment side effects.

How the pieces fit together

At a high level there are four actors:

1. Your system — shop, OMS, middleware, or internal tool that decides when an order should exist and when to refresh it.
2. Order API — authenticates you, stores order records for your account, and orchestrates everything else.
3. Monta — the warehouse system that actually creates pick/pack/ship work and eventually exposes status and serials.
4. Amber — Chargee’s group/device layer. When an order becomes fulfilled and box codes are known, the Order API can link those Sparkies into your group.

You talk only to the Order API over HTTPS with JSON. You never send Monta credentials on each order call; they are stored on your account and used server-side. You also do not call Amber yourself for the standard fulfillment-linking path — that is a server-side consequence of sync when an order newly becomes fulfilled.

Mental model: local truth vs warehouse truth

The API keeps a local order record per merchant. That record is what you list, filter, and show in product UIs. Monta remains the warehouse source of truth for fulfillment progress. Sync and import are how warehouse truth is copied into local truth. Create is how a new local order is born by first asking Monta to accept the work.

There is also a thin “passthrough” style of access that reads Monta more directly. That is useful for diagnostics; day-to-day product logic should prefer the local order picture, because only that picture participates in Chargee’s sync, ownership rules, and Sparky linking.

Who owns what

Every authenticated session belongs to one merchant user. Orders belong to that user. Another merchant cannot see or claim your webshopOrderId. That ownership boundary is the main access control of the API today: identity first, then “everything under this account.”

What a typical journey looks like

You obtain a short-lived access token for your account. You create orders as sales happen, each with a stable webshop identifier. Chargee (and Monta) advance fulfillment over time. Local status moves through pending and processing toward fulfilled — or to cancelled or error when that is what Monta reports. Along the way you can ask for a fresh sync, or rely on Chargee’s background sync. When fulfillment completes and serials appear, Chargee may attach devices to your group without a separate “link devices” step from your side. If you already had history in Monta before integrating, you can import that history into your local account.

What this documentation set is for

These guides explain concepts: authentication, access boundaries, versioning, latency, rate limiting, errors, paging, and the order lifecycle. They are meant to be read as descriptions of behavior. Concrete request and response shapes live in the interactive API reference (OpenAPI / Swagger) for your environment.