ConnectWiz + API & Webhooks

Live integration

The API we sell is the API we use

The whole platform is specified in one OpenAPI contract that our own panel and mobile app are generated from — no shadow endpoints, no doc drift. On top of it: scoped Commerce API keys, secured webhook triggers, and flows that call your systems.

Start free All integrations
One OpenAPI contract Scoped API keys HMAC-verified webhooks
API & Webhooks × ConnectWiz
Payloads are data, never commands
Scoped key: catalog read · orders write
Webhook → HMAC verified → flow starts
Flow REST step calls your API
1
OpenAPI contract of record — the same file our own panel and mobile apps generate from
3
Commerce scopes — catalog read, orders read, orders write — issued per key
100
Max rows per read, clamped server-side — a limit parameter is validated, never trusted
50
Line items per order through the API — a stated bound, not a discovered one

Developers

What it does — precisely

One contract of record

A single OpenAPI 3 document specifies the platform; our own TypeScript clients generate from it — the docs can’t drift from reality because reality is built from the docs.

Commerce API keys

Tenant-issued keys with explicit scopes — catalog read, orders read, orders write — power your own storefront or app on the same order engine, with prices always resolved server-side.

Inbound webhooks, secured

Every flow webhook trigger has its own URL and secret, HMAC verification over the raw body and replay protection. A payload can name a person; it can never steer the flow’s internals.

Outbound via flows

The REST step calls your systems at exactly the moments you draw on the canvas — order placed, consent granted, booking made.

Under the hood

API design positions, stated

Prices never come from the client

An order request says what and how many — name and price are read from the catalog at that moment, server-side, and written onto the line as a snapshot. A tampered request can’t invent a discount.

Capabilities before calls

Each integration surface publishes a capability contract — can it match by phone, list guest orders, create orders? — and calling past a declared "no" throws immediately instead of failing somewhere deep.

Errors that mean something

The transport distinguishes "unauthorized" from "service down" — so "the shop is unreachable" is never rendered as "this customer never bought anything". Named errors are the difference between an API and a guessing game.

Replay-proof webhooks

Every inbound event claims a unique key in an idempotency ledger before processing — a retried or replayed delivery dies at the database layer, not in your automation.

Keys hashed, secrets scoped

API keys are stored as hashes with only the hash and scopes resolvable at the door — a leaked database row names no workspace and unlocks nothing beyond its scopes.

Drafts and confirmations are explicit

Order creation takes an explicit confirm parameter — the public API defaults to confirmed, panel flows can stage drafts — so "is this real?" is a field, not a convention.

Setup

How it connects

01

Issue a key

Create a scoped Commerce API key in the panel; revoke it just as easily.

02

Wire a webhook

Create a flow with a webhook trigger; sign requests with its secret.

03

Call back out

Add REST steps where your systems need to hear about it.

Better together

What it composes with

Flows

Webhook triggers start flows; REST steps call your systems back at the moments you draw — inbound and outbound automation share one canvas.

Commerce

The catalog and order engine behind the API is the same one the chat shop and AI use — one order truth, four doors.

Your own storefront

Teams run headless storefronts on the Commerce API today — the path the Shopify page honestly recommends while the native connector is built.

Security & guarantees

The boring guarantees

HMAC over the raw body

Webhook verification signs the raw request body with a per-trigger secret and compares in constant time — parsing happens only after proof.

Payloads are data, never commands

A webhook payload can reference a person; it can never steer a flow’s internals, rewrite prompts or invoke tools. The boundary between data and instructions is architectural, not behavioral.

Rate limits on every door

Public endpoints ride standard throttling, and read limits are clamped server-side — a misbehaving client degrades itself, not the platform.

The honest fine print

Boundaries, stated

No firehose yet

A generic subscribe-to-everything webhook feed isn’t built — outbound events happen through flow steps today. Stated here, so no sales call has to imply otherwise.

Bounded reads, by design

Reads return up to 100 rows with cursoring — the API is built for operational integration, not bulk export. Bulk needs are a conversation, not a loophole.

API & Webhooks FAQ

Straight answers

More in the full FAQ, or ask us directly.

The platform is specified in one OpenAPI 3 contract — the same file our web panel and mobile app generate their types from. What you integrate against is what we run on.

Per-trigger secrets, HMAC verification over the raw body, and replay protection through an idempotency ledger. And by rule, payloads are data: they can reference a person, never command the automation.

Through flow REST steps, fired at the moments you choose on the canvas. A generic outgoing webhook feed is on the roadmap and deliberately unpromised until it ships.

Yes — catalog reads and order writes are the supported path, with prices resolved server-side and scoped keys you can revoke per surface. The 50-line and 100-row bounds are stated so you design against them instead of tripping on them.

Deliveries are idempotent on our side — the ledger recognizes a replay and drops it, so your systems can retry safely. Outbound REST steps from flows carry their own retry policy with failures surfaced on the flow run.

Connected honestly beats connected loudly.

Every integration here is described by what it really does — direction, ownership and limits included.

Start free All integrations