ERP/iPaaS REST API

Full scope of Suprocure's generic ERP integration REST API: data objects, direction, mechanism, sync frequency, error handling, authentication, responsibilities and security — with sources.

One generic REST API — not a named ERP connector

This page lists the full technical scope of Suprocure's only genuinely verified integration surface (a REST API secured with a per-company API key): which data object moves in which direction, through which mechanism; sync/frequency, error handling, authentication, responsibilities and security — each referenced to source code.

AvailableView technical API docs

Data objects

Data objects
Object	Direction	Mechanism	Evidence status
Purchase Request Read-only — there is no endpoint for the ERP to write requests into Suprocure.	Outbound (Suprocure → ERP)	REST API	Verified
Supplier	Bidirectional	REST API	Verified
Purchase Order	Bidirectional	REST API	Verified
Product / Material	Bidirectional	REST API	Verified
Invoice Status Not a standalone invoice object/endpoint — a status field attached to the order record only.	Inbound (ERP → Suprocure)	REST API	Verified
Tender Bid / Quote Tender bids are only kept in the Suprocure UI today and are not exposed via this API at all.	Outbound (Suprocure → ERP)	—	Not offered
Goods Receipt / Delivery	Outbound (Suprocure → ERP)	REST API	Pending review
Push Notification (Webhook)	Outbound (Suprocure → ERP)	Webhook	Pending review

Sync / frequency

There is no fixed interval — it operates synchronously on request (polling). The ERP/iPaaS side can do incremental pulls via the `updatedSince` parameter; PATCH/PUT calls are processed instantly whenever the ERP triggers them.

Error handling

Retry: Suprocure has no automatic retry/backoff on its side — every request is processed synchronously and returns its result (success/error + HTTP status: 400/401/403/405/500) directly. Retry strategy is the caller's (ERP/iPaaS) responsibility.
Idempotency: Write endpoints are UPSERTs keyed by a natural business key: supplier (tax number), product (material code), order (order number), BOM/overhead/quality records (externalRef or product reference). A repeated call with the same key does NOT create a duplicate — it updates the existing record.

Authentication

Method: A per-company key sent in the `x-api-key` HTTP header. The key is matched against the `organizations.erp_api_key` column; a match grants access ONLY to that company's (org's) data — the service-role key is never sent to the client (ERP), verification happens entirely server-side (inside the Edge Function).
Key/secret handling: The key itself is NEVER shown on this page or in any document — it is retrieved/regenerated from the Settings > Integrations screen by a signed-in company admin.

Responsibilities

Customer

Keep the API key secure and share it only with authorized systems (ERP/iPaaS)
Set up and operate the sync schedule (polling/cron) on their own side
Implement retry/logging strategy on their own side for error responses (4xx/5xx)
Fill in matching fields (tax number, material code, order number, externalRef) correctly and consistently

Suprocure

Keep the API running, secure, and company-isolated (via RLS)
Record write operations to audit_log (best-effort, never blocks the main operation)
Return meaningful error messages and HTTP status codes
Keep scope/field changes up to date on this page

Security & data scope

The key grants access ONLY to the company (org) it is matched to — additionally isolated via Postgres RLS; one company's key cannot access another company's data.

Logging: Write operations (order/supplier/product/BOM/overhead/quality sync) are recorded to the `audit_log` table on a best-effort basis — the actor is labeled "ERP Integration (Company Name)"; this never blocks the main operation.

Last verified: 2026-08-19
Technical owner: Platform Mühendisliği
Verified versions: This is Suprocure's own API — it has no separate version of the ERP it connects to.

Want to see this module with your own data, on your own screen?