Integration Overview

OpenBoxes Lift exposes a REST API and signed webhooks, so you can connect your supply chain data with the other systems your organization depends on. The API covers the core entities well for reading, and covers some of them for writing. It is not a complete mirror of the interface, and some workflows (purchase orders are the main one) can only be driven in the OpenBoxes application. The API documentation is the authoritative list of what exists.

This page is the honest catalog: what connects today, what is coming soon, and what we would start on request. The same catalog is in your customer portal under Integrations, where you can register interest in any item, and on the public integrations page.

What "coming soon" means here: we are building it and it is not available yet. We do not publish dates, quarters or months, and nothing is promised for a particular day. Nothing in that section works today.

Available today#

These work today: the REST API, the Reporting API, the scheduled CSV export and webhooks are on every plan, and so are Power BI and Excel through our Power Query recipe and Looker Studio through a CSV file you upload by hand; stock alerts by email, the weekly stock summary, PagerDuty stock-out incidents and Slack and Microsoft Teams stock-out messages are on every plan too, on Shared and Dedicated instances alike. The monthly stock report to DHIS2 is included on every plan (Shared, Dedicated and Enterprise). The stock-alert email can also go to addresses outside your account, listed as its own row below because it has its own tile in the portal. Handheld scanning is in beta, and it works the same on every plan: on Shared, on Dedicated, and on Enterprise, which runs on Dedicated, Look up, receiving, picking and shipping are all in beta. It is included on every plan at no extra charge during the beta. Temperature logger files are in beta too, on every plan at no extra charge during the beta: you upload the files your loggers make and see each fridge or freezer beside its OpenBoxes location. Sensor connections (Monnit, The Things Stack, ChirpStack and Lift JSON) and temperature alerts are in the same beta.

Integration	Description	Availability
REST API	Read products, stock, locations, orders and shipments with an API key; write products, stock movements and inventory items	Every plan
Webhooks	Signed, retried event delivery to any public HTTPS endpoint you own	Every plan
Reporting API	The Reports page's figures (stock on hand, stock value, expiring lots, open purchase orders and activity) as flat datasets in JSON or CSV, read with an API key, for Power BI, Excel or your own code. Served from our daily check, not live, with its own allowance of 600 requests an hour	Every plan
Scheduled CSV export	A zip of your report data every day, week or month. We email a link to the portal to each teammate who turns it on	Every plan
Power BI and Excel	A Power Query recipe you paste into Power BI Desktop or Excel, which reads the Reporting API with an API key and refreshes on demand. The Power BI connector is coming soon	Every plan
Looker Studio	By hand: upload a scheduled export's CSV file with Google's CSV file upload connector. Nothing refreshes by itself. The Looker Studio connector is coming soon	Every plan
Stock alerts	A daily below-minimum / nearing-expiry email you opt into, sent to the account owner and the teammates ticked in the panel	Every plan, on Shared and Dedicated instances
Weekly stock summary	A Monday email about the week before: stock-outs, below minimum, expiring lots, stock value, open purchase orders and activity. Each person turns it on for themselves; Slack and Teams channels can get a counts-only version	Every plan, on Shared and Dedicated instances
PagerDuty	An incident in your PagerDuty service when a product with a minimum set runs out of stock at a location, found by the same once-a-day check. Stock-outs only; below-minimum and nearing-expiry stay in the daily email. With its Temperature alerts toggle on, it also gets temperature alerts (beta)	Every plan, on Shared and Dedicated instances
Slack	A message in a Slack channel, through an incoming webhook from a Slack app, when a product with a minimum set runs out of stock at a location, found by the same once-a-day check, and one "stock returned" message when stock comes back. Stock-outs only; below-minimum and nearing-expiry stay in the daily email. With its Temperature alerts toggle on, it also gets temperature alerts (beta)	Every plan, on Shared and Dedicated instances
Microsoft Teams	A card in a Teams channel, through a Workflows webhook created in Teams, when a product with a minimum set runs out of stock at a location, found by the same once-a-day check, and one "stock returned" card when stock comes back. Stock-outs only; below-minimum and nearing-expiry stay in the daily email. With its Temperature alerts toggle on, it also gets temperature alerts (beta)	Every plan, on Shared and Dedicated instances
Email to outside addresses	The same daily stock-alert email to an address that is not a user on your account (a supplier or a contractor), once the account owner adds it and it confirms a 6-digit code. Up to five per account, each with its own unsubscribe link	Every plan, on Shared and Dedicated instances
DHIS2	Your monthly stock report (balances, receipts, consumption, losses and days out of stock) sent to the monthly form on your own DHIS2 server, after each month closes. One way, figures only, from our daily check	Every plan: Shared, Dedicated and Enterprise
Handheld scanning (beta)	OpenBoxes Lift Mobile, a web app for a phone or handheld scanner: look up stock, receive inbound shipments and pick and ship requests by scanning barcodes, in Chrome at your own instance address. In beta, included on every plan at no extra charge during the beta. It works the same on every plan: on Shared, on Dedicated, and on Enterprise, which runs on Dedicated, Look up, receiving, picking and shipping are all in beta	Every plan: Look up, receiving, picking and shipping
Temperature logger files (beta)	Upload the files from Berlinger Fridge-tag 2L loggers (now sold by Sensitech), Fridge-tag readouts made with the free Varo app (its zip as it is, or the Fridge-tag file inside), LogTag loggers (CSV or TXT from LogTag Analyzer) and other CSV files you map once. See each fridge's readings, excursions and monthly summaries next to the OpenBoxes location it is in. Lift shows a copy of your logger's record. Use your logger's own record for decisions about your vaccines and medicines, and for inspections. Lift is not a validated system	Every plan, included at no extra charge during the beta
Sensor connections (beta)	Readings sent to Lift by themselves from Monnit Temperature and Thermocouple sensors (an iMonnit webhook), The Things Stack, ChirpStack and your own system (Lift JSON), built against each vendor's published format	Every plan, included at no extra charge during the beta
Temperature alerts (beta)	An email, Slack, Microsoft Teams or PagerDuty alert once a logger's alert rule is met on readings from a sensor connection, an alert when a sensor stops sending, and one summary when an uploaded file shows new excursions (never to PagerDuty). A second channel, not a replacement for your device's own alarm	Every plan, included at no extra charge during the beta

Stock alerts, in short#

Stock alerts are included on the plan you are already on; there is no alerts add-on to buy. They are off until someone on the account turns them on in the portal under Integrations > Destinations. Anyone on the account can open that panel and change these settings. It is a shared team surface, not an owner-only control, so a teammate can also switch the instance's alerts off for everyone.

Once a day, shortly after 7am in your instance's timezone. The hour is fixed. This is not real time: nothing is sent the moment stock drops.
Only products with a minimum level set at that location are checked for being low. The low-stock half reads the minimum level you already set in OpenBoxes. Lift adds no second place to configure it, and a reorder point is not used. A product with no minimum is never reported as below minimum, however low it gets, so if you set no minimums you will never be told anything is low. Every email states how many of your products have a minimum set.
The nearing-expiry half does not use minimum levels at all. It looks only at how close a lot is to its expiry date, so an instance with no minimums set still receives an email on any day a lot falls inside the chosen window. It lists stock approaching expiry; a lot that has already passed its expiry date is not listed. Nothing is sent only when neither half has anything.
We cut long lists sensibly and always state the true total: at most 50 rows per location in each section and 200 rows in one email overall, keeping the largest shortfalls in the below-minimum section and the lots closest to expiry in the expiring section, with the real count shown whenever there is more than we display.
The account owner and the teammates ticked in the panel receive it, plus any outside address the account owner has added and that has confirmed a 6-digit code. Every email carries a one-click unsubscribe link that stops that one address, and that opt-out cannot be undone by re-ticking them, not even by the account owner. Anyone on the account switches the whole instance off in the same panel.
Shared and Dedicated alike. What decides is where your instance actually runs, not the plan name. If we are moving your instance between tiers, alerts keep running on the shared fleet until the move and resume on the new server once the move is complete; the daily check may not run on the days the move is in progress.

The full article is Stock alerts.

Weekly stock summary, in short#

Every Monday from 7am in your instance's timezone, covering Monday to Sunday of the week before, and sent even in a week when nothing went wrong. Each summary says how many daily checks it is based on, for example "Based on 6 of 7 daily checks."
Nobody gets it automatically. Someone on the account switches it on for the account in Integrations > Destinations > Stock alerts, and then each person is off until it is turned on for them: you tick yourself, or the account owner ticks you. Only people on the daily alert's list can get it.
Values go to the account owner and admins. Other teammates get the same summary without values, unless the account owner shows values to all teammates. Outside addresses never get values or a portal link, but they do see product names for new stock-outs and the activity totals.
Slack and Teams, only if you tick "Also post the weekly summary here" on the destination: one short message of counts and up to 5 new stock-outs by name, never values. PagerDuty never gets it.

The full section is The weekly summary.

Reporting API, in short#

The Reporting API is included on every plan, on Shared, Dedicated and Enterprise alike, with no add-on to buy.

The same figures as the Reports page, as seven read-only datasets: a one-row summary, stock on hand, stock history, stock value over time, expiring lots, open purchase orders and activity. JSON (up to 1,000 rows a page) or CSV (up to 10,000).
From our daily check, not live. Every row says which daily check it comes from.
On https://api.openboxes.cloud only, with an API key in the X-API-Key header (never in the URL). Only the account owner creates API keys.
Quantities by default. Stock value, prices and order amounts are included only on a key the account owner has turned on Include values for.
Its own allowance of 600 requests an hour per account on every plan, separate from your API limit; the API add-on does not change it.

The full article is Reporting API.

Scheduled CSV export, in short#

The scheduled CSV export is included on every plan, on Shared, Dedicated and Enterprise alike, with no add-on to buy. It is in the portal under Integrations > Reporting > Scheduled CSV export.

Daily, weekly or monthly, one schedule per account, set by the account owner or an admin. It is built from 07:00 in your instance's timezone, normally after that morning's daily stock check.
A zip of seven CSV files (the Reporting API's datasets, with the same columns) plus a manifest.json and a README.txt.
The email links to the portal; the file is never attached. Each person on the team turns the email on for themselves, and the account owner can turn it on for a teammate. It never goes to outside addresses or channels.
Kept for 7 days, then deleted. It does not use your API limit or the Reporting API's allowance, and it needs no API key.

The full article is Scheduled CSV export.

PagerDuty, in short#

The PagerDuty destination is included on every plan too, on Shared and Dedicated instances alike. Anyone on the account adds it in the portal under Integrations > Destinations, with the integration key from an Events API v2 integration on the PagerDuty service of your choice.

Stock-outs only. An incident opens when a product with a minimum level set at a location runs out (its quantity on hand there is zero), found by the same once-a-day check the email uses. Below-minimum and nearing-expiry never go to PagerDuty; they stay in the daily email.
One incident per product and location. A product still at zero the next day does not open a second incident. The incident resolves itself when the next daily check sees stock again; running out again later opens a new one.
Severity is always warning (a test is info; never error or critical). Urgency is governed by your PagerDuty service settings, not by us: a service defaults to high urgency, and severity only maps to Low urgency where you have turned on Dynamic Notifications.
A test incident pages whoever is on call for that service. To test without paging anyone, first put the service in a maintenance window (in PagerDuty's words, "While a service is in a maintenance window, its integrations are disabled and no new incidents will trigger"), point the destination at a test service whose escalation policy notifies only you (or a schedule with nobody on call), or add an Event Orchestration rule that suppresses events for the service.
At most 50 new incidents per destination per day. Past that, one overflow incident says how many more products are out.
US or EU region: you choose; US is the default. The integration key is entered once and never shown back; rotating it or removing the destination resolves that destination's open incidents first.
Not a webhook event, and the weekly summary is never sent to PagerDuty.

The full article is PagerDuty alerts.

Slack, in short#

The Slack destination is included on every plan too, on Shared and Dedicated instances alike. Anyone on the account adds it in the portal under Integrations > Destinations, by pasting the URL of an incoming webhook created in a Slack app in your own workspace. The host must be hooks.slack.com; legacy custom-integration webhooks and GovSlack are not supported, and the channel is chosen in Slack when the webhook is made.

Stock-outs only. The same trigger as PagerDuty: a product with a minimum level set at a location runs out, found by the same once-a-day check. Below-minimum and nearing-expiry never go to Slack as alerts (a Slack or Teams channel ticked for the weekly summary gets only their counts, once a week); they stay in the daily email.
One message per product and location, then one "stock returned" message. Nothing more is posted while the product stays at zero; when the next daily check sees stock again, one message says so. Nothing else is ever posted about it. Unlike PagerDuty, there is nothing to close in a channel.
At most 50 new stock-outs per destination per day. Past that, one overflow message says how many more products are out, with the true total.
A test posts one short [TEST] message and pages nobody, one test per destination every 5 minutes.
The webhook URL is entered once and never shown back; the panel shows only the host. Rotating it is pasting a new URL, and nothing is posted to say so. If Slack refuses a message three times in a row we switch the destination off; saving the URL again switches it back on.
Not a webhook event, and orders and shipments are not posted to Slack: those are webhook events to an endpoint you own.
The weekly summary, if you tick it. A destination with "Also post the weekly summary here" ticked (off by default) also gets one short Monday message of counts, never values.

The full article is Slack alerts.

Microsoft Teams, in short#

The Microsoft Teams destination is included on every plan too, on Shared and Dedicated instances alike. Anyone on the account adds it in the portal under Integrations > Destinations, by pasting the URL of a Workflows webhook created in Teams: open the channel, choose Workflows, and pick the template "Post to a channel when a webhook request is received".

It must be a Workflows webhook. Microsoft retired the old Office 365 connector webhooks on webhook.office.com in May 2026, and we refuse one with a message that says so. Other hosts are refused too, so the URL has to be the one Teams itself gave you.
Stock-outs only. The same trigger as Slack: a product with a minimum level set at a location runs out, found by the same once-a-day check. Below-minimum and nearing-expiry never go to Teams as alerts (a Slack or Teams channel ticked for the weekly summary gets only their counts, once a week); they stay in the daily email.
One card per product and location, then one "stock returned" card. Nothing more is posted while the product stays at zero. Unlike PagerDuty, there is nothing to close in a channel.
At most 50 new stock-outs per destination per day. Past that, one overflow card says how many more products are out, with the true total.
A test posts one short [TEST] card and pages nobody, one test per destination every 5 minutes.
The webhook URL is entered once and never shown back; the panel shows only the host. Rotating it is pasting a new URL, and nothing is posted to say so. If Teams refuses a card three times in a row we switch the destination off; saving the URL again switches it back on.
Not a webhook event.
The weekly summary, if you tick it. As with Slack, a destination ticked for it also gets one short Monday card of counts, never values.

The full article is Microsoft Teams alerts.

DHIS2, in short#

The DHIS2 integration is included on every plan, on Shared, Dedicated and Enterprise alike, with no add-on to buy. It is in the portal under Integrations > Connections > DHIS2.

One way, monthly, figures only. Lift fills the monthly stock form (a DHIS2 data set) on your own DHIS2 server with figures such as opening balance, received, dispensed, losses, closing balance and days out of stock, per facility and product. No names, prices or lot numbers are sent, and nothing comes back into OpenBoxes.
From our daily check, not live. A month can be sent once it has closed; its figures are provisional from the 1st and final from the 10th.
DHIS2 2.40 to 2.43, with the standard calendar, monthly forms and an https address reachable from the internet. A server that only accepts known addresses (an IP allow-list) works once it allows both of Lift's DHIS2 addresses, 35.196.140.40 and 34.26.184.92.
A DHIS2 server our team has not approved before waits for approval before Lift contacts it. The account owner connects the server; the account owner or an Admin matches facilities and products, previews, runs a dry run and sends.

The full article is DHIS2 integration, and the DHIS2 overview puts it on one page.

Nothing in the Coming soon or Available on request sections below connects to OpenBoxes Lift today.

These are real and available on every plan, but they are not integrations, which is why they are not in the table above:

Third-party sign-in: a login option on your instance's own login page: people sign in with Google, Microsoft or GitHub instead of a password. It is individual sign-in, not company sign-in (SSO), which is a separate feature: included on Enterprise, a paid add-on on Dedicated, not available on Shared, and described on the same page.
One-time data import: when you move onto Lift we import your existing data once. The import wizard recognises exports from QuickBooks, Xero, Odoo, ERPNext, mSupply, OpenLMIS and Shopify, and takes plain spreadsheets and CSV files from anything else. This is a migration step, not an ongoing sync: nothing keeps the two systems in step afterwards.
The Reports page in the portal: a read-only page of your stock value, stock-outs, expiring lots, open purchase orders and weekly activity, built from our daily check, with CSV downloads. It is included on every plan. It is not the same as the Reporting menu inside OpenBoxes. The Reporting API (above) returns the same figures to software.
Custom integrations: a pattern, not a product; you build your own against the REST API and webhooks. Custom integration work by us is not part of any plan today.

Coming soon#

We are building these and none of them works yet. We do not publish dates, quarters or months for them, and nothing is promised for a particular day.

The daily stock alert email, the weekly stock summary, the PagerDuty, Slack and Microsoft Teams stock-out destinations, the Reporting API, the scheduled CSV export, the Power Query recipe for Power BI and Excel and the CSV upload to Looker Studio are available today, and handheld scanning is in beta (Look up, receiving, picking and shipping on every plan), and so are temperature logger files, sensor connections and temperature alerts. Everything below is still being built.

Integration	What it will do
Zapier	Trigger Zaps on orders and shipments; create products and stock movements from other apps
n8n	A community node for self-hosted automation
Looker Studio connector	A community connector for dashboards that reads the Reporting API and refreshes by itself. Today, upload the CSV files by hand
Power BI connector	A Power BI connector for the Reporting API. Today, use the Power Query recipe
More temperature sensors	The WHO EMS push from a fridge's own monitoring system, and other sensor vendors. Today, use a sensor connection or upload your logger files
Logger maker cloud connections	Readings pulled from a temperature logger maker's cloud service
ERP connectors: Microsoft Dynamics 365 Business Central, Oracle NetSuite, SAP Business One, Odoo	Products and purchase orders from your ERP into OpenBoxes, receipts back to your ERP against the purchase order and stock adjustments as its own inventory adjustments, locations and suppliers matched at setup, and a daily stock comparison. Your ERP stays your system for purchasing and accounting. Being built for Business Central online (not on-premises), NetSuite, SAP Business One, and Odoo with its Inventory app, on Odoo.sh, your own server or an Odoo Online plan that includes the external API. See ERP connectors. When they arrive, they will be included in the plan price on the Dedicated and Enterprise plans, and not offered on the Shared plan. Today, use the REST API, webhooks and the Reporting API
QuickBooks Online	A connection between OpenBoxes Lift and QuickBooks Online. What it will send has not been published yet. When it arrives, it will be included in the plan price on the Dedicated and Enterprise plans, and not offered on the Shared plan

Available on request#

These are not built and are not promised. Ask, and we will talk through honestly whether we can help and what it would take:

Integration	What it would do
Xero	Bills and manual journals, created as drafts
Power Automate	A Microsoft connector for flows in Teams and SharePoint
Shopify	Web-store orders would become outbound stock movements in OpenBoxes, and fulfillment status would go back to your store
WooCommerce	Web-store orders would become outbound stock movements in OpenBoxes, and fulfillment status would go back to your store
ShipStation	Shipments and shipping labels in ShipStation for your outbound stock movements
EDI with trading partners	Purchase orders, advance ship notices and inventory exchanged with your trading partners. Tell us about your partner; asking is not a promise that we will build it
FHIR export	Share stock data with health information systems using HL7 FHIR

A web-store order would arrive in OpenBoxes as an outbound stock movement. A one-time import of a Shopify product export when you move onto Lift is available today; an ongoing Shopify sync is not, and is on request like the rest of this table.

Integration Philosophy#

OpenBoxes Lift follows three principles for integrations:

API-first where it exists: products, locations, inventory, stock movements and orders are all readable through the REST API; products, stock movements, inventory items and the other generic domain classes are writable. Not everything in the interface has an endpoint: check the API documentation for the operation you need before you design around it.
Webhook-driven: Signed webhooks push order, shipment, stock-adjustment and tenant-lifecycle events to your systems in near real time, so you do not have to poll for changes. All of them are delivered on every plan (Shared, Dedicated and Enterprise).
Standards-based: Plain HTTPS and JSON, with pagination and signing conventions you can implement in any language, rather than proprietary protocols.

How integrations work today#

Stock alerts and DHIS2 are set up in the portal under Integrations. Everything else you can connect today, you connect yourself against the API and webhooks:

Authentication: Generate an API key in the OpenBoxes Lift portal under API → API Keys.
Reads and writes: Call the REST API from your own script, scheduled job or integration platform. Apart from DHIS2, there is no in-portal connector configuration screen, because there are no other managed connectors yet.
Events: Register an HTTPS endpoint on the Webhooks page, or with an admin-scoped API key (Webhooks), and subscribe to the event types you need; the event picker there is the authoritative list of what delivers.
Monitoring: Webhook delivery attempts, retries and responses are visible in the delivery log on the Webhooks page. API traffic is visible on the Usage page.

Tier requirements#

No integration is gated behind a higher plan today. The REST API, the Reporting API, the scheduled CSV export, webhooks, stock alerts and the PagerDuty, Slack and Microsoft Teams destinations are included on Shared, Dedicated and Enterprise alike, as are third-party sign-in and the one-time data import, and what differs between those plans is the API and webhook allowance, not the feature. That includes the webhook events from the OpenBoxes instance (orders, shipments, stock adjustments), which are delivered on every plan. For stock alerts and PagerDuty, what decides is where the instance actually runs, not the plan name. If we are moving your instance between tiers, alerts keep running on the shared fleet until the move and resume on the new server once the move is complete, and the daily check may not run on the days the move is in progress. Custom integration work by us is not part of any plan today; tell us what you need and we will say honestly whether we can help.

Tip: Shared and Dedicated start with the standard 30-day free trial, so you can validate your integration against a real instance before your first charge. If you later need Dedicated-tier limits, contact our sales team about upgrading.

Telling us what you need#

Demand decides what we build next, and the fastest way to be counted is the Integrations tab in your customer portal. It lists this catalog under four sections (Apps, Connections, Destinations and Reporting), and every coming-soon or on-request item carries a button that records your interest.

If the system you need is not in the catalog at all:

Check the community forum at community.openboxes.com: someone may have already built what you need.
Tell us via the chat in your portal or at support@openboxes.cloud. Include the system name, your use case, and the data you need to exchange.
Consider building it yourself: the REST API is flexible enough to support most use cases with modest development effort. See our Custom Integrations guide.

Rate Limits#

API rate limits are hourly and apply per account: all of your API keys share one quota, and the limit covers X-API-Key requests across every endpoint combined, except the Reporting API, which has its own allowance of 600 requests an hour. There is no concurrent-connection limit.

Tier	Requests per hour
Shared	1,000
Dedicated	25,000
Enterprise	50,000

Exceeding the limit returns a 429 Too Many Requests response. See Rate Limits for headers and back-off guidance, and the Error Reference for details.