Developers

Deterministic, versioned control decisions over a stable REST API.

Reference

OpenAPI spec

Base /v1, bearer auth, cursor pagination, stable error codes.

docs/openapi.yaml on GitHub →

Idempotency

Writes accept an Idempotency-Key header. Queue consumers and webhook delivery are idempotent by design.

Webhooks

HMAC-signed with event ID and timestamp. At-least-once delivery — your handler must tolerate duplicates.

Error format

Stable machine codes: NOT_FOUND, UNAUTHORIZED, FORBIDDEN, INVALID_REQUEST, CONFLICT, RATE_LIMITED, PROCESSING_FAILED.

Core endpoints

POST /v1/uploads
POST /v1/invoices
POST /v1/invoices/from-upload
GET  /v1/invoices
GET  /v1/invoices/{id}
GET  /v1/invoices/{id}/analysis/latest
GET  /v1/findings
POST /v1/findings/{id}/review
GET  /v1/findings/{id}/comparison
POST /v1/scans
GET  /v1/scans/{id}
GET  /v1/scans/{id}/findings
GET  /v1/suppliers
POST /v1/suppliers/merge
POST /v1/purchase-orders
POST /v1/payments
POST /v1/erp-connections
POST /v1/erp-connections/{id}/sync
POST /v1/webhooks
GET  /v1/api-keys
GET  /v1/audit-events
GET  /v1/organizations/current/overview
GET  /v1/billing/subscription

What this API will never do

Let an LLM set the PASS/REVIEW/BLOCK decision — decisions are deterministic and reproducible against an engine/policy version
Expose upstream provider schemas directly — only Invogi's own versioned contracts
Execute payments or replace your ERP

Building an ERP or vertical SaaS integration? Talk to us about the embed path.