A REST API that writes, not just reads

API keys and scopes, fail-closed

Keys are stored as a salted hash with only a prefix retained for identification — the full key is shown once, at creation, and cannot be recovered afterward. Ten scopes cover read and write access per resource plus webhook management and data export; a key with no scope, or the wrong scope, is denied rather than waved through. Scopes are re-read from the database on every request rather than trusted from a cached claim, so revoking a scope takes effect immediately rather than at the next token refresh.

Rate limiting, Redis-backed and atomic

1,000 requests per 60 seconds per API key or OAuth client, enforced with an atomic sliding-window script against Redis so concurrent requests cannot race past the limit. Every response carries X-RateLimit-Limit, -Remaining, and-Reset headers, and an exceeded limit returns 429 with aRetry-After header rather than a bare rejection.

Webhooks: three events, delivered like a spec says they should be

Three events are available to subscribe to today — work_order.completed</code>, <code>inventory.threshold_breached</code>, <code>inventory.threshold_cleared — the catalog seeds strictly from what Qontiv actually dispatches, so a subscription never silently waits on an event that will never fire. Delivery follows the Standard Webhooks v1.0.0 signing scheme, retries nine times over roughly 75 hours with jitter, honors a subscriber's own Retry-After up to a 24-hour ceiling, and disables an endpoint automatically on a 410 response or after retries exhaust. Every delivery attempt re-validates the destination URL immediately before sending and refuses to follow a redirect — hardening against DNS-rebinding and open-redirect SSRF, not a check done once at registration and trusted forever. Failed or abandoned deliveries can be replayed individually or in a bounded date-range batch, and a replay against a retention-redacted record is refused outright rather than resending an empty signed body.

OpenAPI 3.0, a Scalar reference, and three SDKs

The full API is described as an OpenAPI 3.0 document (pinned to 3.0, not 3.1, while generator tooling for 3.1 stabilizes) and served at /api/docs through a Scalar reference with a working curl snippet and both API-key and OAuth2 security schemes wired in. Three SDKs — C#, Python, and TypeScript — are generated directly from that document, and generation fails the build if an operation drifts out of sync with the published surface, rather than shipping a stale client quietly.

GraphQL, for the full application surface

The same authenticated GraphQL endpoint that powers the Qontiv application is available for integrations that need more than the REST resources above — the REST API and webhooks are the documented, versioned, SDK-backed developer surface; GraphQL is available to authenticated users for everything else.

Also available: SCIM provisioning

Enterprise customers using SSO can provision and deprovision users via SCIM 2.0 rather than the REST API above — see the SSO and SCIM capability on the Enterprise tier.

Scope — what this does and does not do

• Write scope is not gated by plan tier. All twenty operations, including the six writes, are available at every tier; what differs by tier is the monthly API-call allowance and storage.
• Not every ERP object is exposed. The public surface covers items, inventory balances, work orders, production events, quality events, webhooks, and data-portability requests — a deliberately curated subset of the full application, not a mirror of everything in the product.

Availability

The REST API, webhooks, and SDKs are available on every tier. Core includes 100,000 API calls and 50 GB of storage per month; Professional includes 1,000,000 calls and 500 GB; Enterprise is unlimited. See pricing for the full tier ladder, orrequest a demo to see the API against your own data.