Everything a store does in Stockroom by hand, from your own code
Purchase orders, receiving, suppliers, costs and stock adjustments, over plain JSON at https://api.stockroom.app/v2. Webhooks come with it, so nothing has to sit and poll.
Your first call
Get a key
The merchant turns the API on under Settings, then API, and creates a key for your integration. It starts with srk2_ and is shown once. Get a key has the two steps.
Ask who you are
GET /v2/whoami is the cheapest call there is. It names the store the key belongs to and lists what the key may do, so a wrong key or a missing scope shows up before anything else does.
Read, then write
Every key can read. Writes need a scope the merchant chose at creation, and the two writes that move stock take anIdempotency-Key so a retried call cannot receive a delivery twice. Conventions covers paging, money, errors and limits once, for every endpoint.
# Every call is the same shape: the base URL, a bearer key, JSON back.
curl https://api.stockroom.app/v2/whoami \
-H "Authorization: Bearer $STOCKROOM_KEY"{
"shop": {
"id": 12,
"domain": "example.myshopify.com",
"name": "Example Store",
"currency": "USD",
"timezone": "America/Chicago"
},
"key": {
"id": 4,
"name": "ERP key",
"prefix": "srk2_ab12cd34",
"scopes": [
"read",
"write:purchase_orders"
],
"expires_at": null
},
"api_version": "2"
}The reference
Account
The key itself: which store it belongs to, what it may do, and when it expires. GET /v2/whoami is the cheapest way to prove a key works.
Suppliers
Suppliers and their per-supplier catalogs: supplier SKU, cost, minimum order quantity and pack size. Archive, unarchive and merge are actions rather than fields; nothing in Stockroom deletes a supplier.
Purchase orders
Drafts, lines, charges and the whole lifecycle: send, mark ordered, mark on the way, close, reopen, cancel what is left, archive, duplicate. Each move is its own call, and an illegal one is 422 invalid_transition rather than a silent write.
Receipts
One record per delivery against a purchase order: what came in, to where, on what date, at what cost. Recording a receipt moves stock, so it requires an Idempotency-Key; voiding one reverses the movement instead of editing a number back down.
Payments
Payments recorded against a purchase order, one row each, so a part payment is expressible. The order's payment_status and paid_at follow from the rows; mark paid and mark unpaid are the shortcuts.
Stock adjustments
A signed delta per line, drafted and then applied. Applying moves stock and requires an Idempotency-Key. Stockroom adjusts by a delta and never sets an absolute level.
Catalog
Read-only mirror of the store's Shopify products, variants, locations and inventory levels. It may lag Shopify by a few seconds. To change catalog data, write to Shopify's Admin API.
Webhooks
Subscriptions to a URL, the delivery log, a test event and redelivery. The signing secret is in the creation response and nowhere else.
Shapes
The named objects every answer is made of: a supplier, a purchase order, a receipt, an adjustment, a webhook.
The guides
Get a key
The store gets access, then someone creates a key.
Authentication and scopes
One header, six scopes, and what each refusal means.
Conventions
Paging, money, errors, idempotency and rate limits, the same on every endpoint.
Stock changes and sync state
The record is final at once; Shopify hears about it in the background.
Webhooks
A signed POST when something happens, so nothing has to poll.
Coming from Stocky
Where each Stocky field went, for code you are repointing.
Changelog
What may change under you, what may not, and what has.
What is in the API today
| Area | What you can do |
|---|---|
| Suppliers | List, read, create, update, archive and merge. Read and write the per-supplier catalog: supplier SKU, cost, minimum order quantity and pack size. |
| Purchase orders | Create and edit drafts, add lines, send to the supplier, mark ordered, mark on the way, record receipts, void a receipt, record payments, close, reopen, cancel what is left, archive, duplicate, read the history, download the PDF. |
| Stock adjustments | Create a draft, edit it, apply it, cancel it. |
| Catalog | Read products, variants, locations and inventory levels from Stockroom's mirror of the store's Shopify catalog. Read-only, on purpose - see below. |
| Webhooks | Create and manage subscriptions, send a test, read deliveries, redeliver one. |
Stocktakes, transfers, builds, lot numbers, attachments, comments, reorder suggestions and reports are not in the API yet. Neither is the cost-and-price side of receiving: a receipt books the costs you send it, and the API never changes a selling price in Shopify.
Where Stockroom stops and Shopify starts
Stockroom does not own your catalog. Products, variants, locations and inventory levels are offered read-only, from a mirror Stockroom keeps of the store's Shopify data, so you can read a SKU or a stock level without a second API call. That mirror can lag Shopify by a few seconds.
To change catalog data - a product, a variant, a price, a stock level directly - write to Shopify's Admin API. Stockroom will never offer a catalog write, because two systems writing the same product is how stores end up with data nobody trusts.
Stock that Stockroom does own the reason for - a receipt, an applied adjustment - is written to Shopify by Stockroom, on your behalf, through a queue. Stock changes and sync state explains what the response tells you while that is in flight.
Versioning
This is v2, and it is the first public version. Changes are additive: new endpoints, new optional request fields, new response fields. An existing field will not change type or disappear, and an endpoint will not change what it does under you.
Treat unknown response fields as normal and ignore them, rather than failing on them - that is what makes an additive change safe on your side too. Anything that ever cannot be additive gets a new version and a long overlap, announced in the changelog.
There is an older API, and it is not this one. If you have read about a Stockroom API for QuickBooks or Xero, that is/v1 - a private contract our own MyWorks accounting apps use. It is not documented and not open. Build on v2.
Getting help
Email support@stockroom.app. Include the store domain, the key's name, the endpoint and the time of the call. Every API request is logged against the key that made it, and the merchant can see the same log under Settings, thenAPI, so that is enough for someone to find the exact call you made.