STONEWARE DEVELOPER CENTER

Integrate the physical operation.

Server-to-server access to stone inventory, purchasing, receiving, reservations, warehouse and fulfilment — with company, employee, permission and retry controls intact.

Browse API reference Quick start

GET/api/slab/v1/operations/slabs?warehouse_id=1&per_page=30

Authorization: Bearer slabop_…
Accept: application/json

200 OK
{
  "data": [ … ],
  "meta": {
    "per_page": 30,
    "has_more": true,
    "next_after_id": 348
  }
}

41read collections

79mutations

163HTTP operations

60/mincredential limit

OPERATIONAL DOMAINS

Start from the business object you are integrating.

The public operational contract is organised around canonical Stoneware resources and workflow actions.

INVENTORY

Exact stone & locations

Slabs, remnants, materials, warehouses, locations, movements and related inventory context.

Open Slabs reference →PROCUREMENT

Inbound operation

Suppliers, purchase orders, shipments, containers, receipts, exceptions and landed cost.

Open PO reference →COMMITMENT

Reservation & allocation

Projects, selections, reservations, quote links and allocations around exact physical stock.

Open Reservations reference →FULFILMENT

Pick, dispatch & return

Fulfilments, proof, dispatch context and returns using the same authoritative state.

Open Fulfilments reference →

TECHNICAL MODEL

Understand the boundary before you write integration code.

These diagrams summarize the verified operational contract; the endpoint reference and workflow rules remain authoritative.

Authority intersectionScope ∩ employee permission ∩ company access.

Safe retriesReuse the same logical request and UUID key after an unknown outcome.

Webhook reconciliationVerify, re-read and reconcile authoritative state.

Keyset paginationFollow next_after_id until has_more is false.

Authenticate

Company + employee scoped operational credentials.

Retry safely

UUID idempotency keys and replay protection on every write.

Reference

41 reads and 79 mutations grouped by operational domain.

Code examples

Verified read patterns in cURL, JavaScript, PHP, Python and C#.

Workflow recipes

Use the API in the same operational sequence as Stoneware.

Errors & limits

Design for permission failures, validation, conflicts and retry limits.

INTEGRATION ARCHITECTURE

Build a trusted service around Stoneware — not a second workflow engine.

The operational API is designed for server-to-server integration that respects current company access, employee permissions and authoritative Stoneware state.

01Your trusted serviceKeep credentials on a server you control.

→

02Operational credentialCompany + employee + explicit scopes.

→

03Stoneware APIPermission intersection and workflow checks.

→

04Canonical operationInventory, purchasing, reservation or fulfilment service.

→

05Re-read stateReconcile authoritative results and webhook changes.

PRODUCTION INTEGRATION CHECKLIST

Build against the workflow boundary.

Keep integrations company-scoped, permission-aware and safe to retry.

Trusted server onlyOperational bearer credentials stay out of browser JavaScript and distributed mobile binaries.

Permission intersectionToken scope never overrides the active employee’s current permission or company access.

Retry safelyEvery write uses one UUID idempotency key per logical operation and reuses it on unknown outcomes.

Re-read authorityAfter webhooks or mutations, re-read authoritative state instead of fabricating local workflow status.

API boundary

This operational API does not create customer, invoice, accounting, ARI or Supplier Finance & FX records unless an endpoint is explicitly present in the verified contract. Those areas remain owned by their authoritative Stoneware workflows, and this portal does not publish invented endpoints for them.

APPLICATION CAPABILITY BOUNDARY

Web v3 documents more product capability than the current public operational contract exposes.

ARI and Supplier Finance & FX are documented as Stoneware application capabilities. Do not infer a public API from a product page: only endpoints listed in the verified reference are supported.