Trust · Security
The controls, named.
A developer evaluating an API asks about credentials before endpoints. Each control below is a specific mechanism in the deployed system.
Access control
How credentials are issued and scoped
WooliiPorter issues API keys only after approval activates a merchant account. Each key belongs to one merchant, carries explicit scopes and exposes its execution mode, and every read is bounded to that merchant, so a resource ID obtained elsewhere returns nothing.
- Approval activates the merchant account, and that is what opens API-key management.
- Keys are per merchant, carry explicit scopes, and expose their execution mode, so sandbox traffic stays in the sandbox.
- Every read is merchant-scoped: a resource ID on its own returns nothing.
- Credentials are issued to merchants. The API has no path by which one client issues credentials to another.
Event integrity
How WooliiPorter signs what it sends you
WooliiPorter delivers 8 webhook event types, each HMAC-signed over the raw request body and carrying an immutable event ID, at least once. The receiver contract is: verify the signature over the raw body, deduplicate on the event ID, then process — in that order, so a payload is authenticated before it is parsed and a repeat delivery is recognised before it is acted on.
Connected stores
What a store connection touches
A store connection reaches the orders WooliiPorter has to fulfil and nothing wider. Order submission runs outside the shopper’s checkout request, status updates return over a signed webhook bound to that one store, access tokens are encrypted at rest, and staff access to the operations systems is restricted by role.
| Surface | What it touches |
|---|---|
| WooCommerce | Orders submit asynchronously after checkout through Action Scheduler, outside the customer’s checkout request. Status updates return over a webhook bound to that store, HMAC-signed over the raw payload. Activating the plugin imports no historical orders and reads no full product catalog. |
| Shopify | Access tokens are encrypted at rest, embedded app requests use short-lived Shopify session tokens, and webhook authenticity is verified before a payload is processed. |
| Accounts | Passwords are stored hashed. Card numbers are handled by the payment processors. |
| Operations | Staff access is restricted by role, integration events are retained as an audit trail without raw webhook bodies, and development validation runs separately from production. |
The WooCommerce plugin in detail · What is stored, and where it goes
Checkable
Three artifacts you can inspect before you connect anything
Three technical artifacts are published before any account exists: the complete OpenAPI 3.1 contract, two SHA-256 checksums for the WooCommerce plugin, and the signature scheme, error table and idempotency contract in the Merchant API reference.
- The OpenAPI 3.1 contract at /api/developers/openapi, public and complete.
- Two published SHA-256 checksums for the WooCommerce plugin — the directory-served zip and the repo artifact are not byte-identical, so both are given and a mismatch is meaningful.
- The signature scheme, the error table and the idempotency contract, documented on the Merchant API reference before you have an account.
Questions
How does WooliiPorter issue and scope API keys?
API keys are issued once approval activates a merchant account. Keys are per merchant, carry explicit scopes and expose their execution mode, so sandbox traffic stays separate from production. Every read is merchant-scoped, and the API has no path by which one client issues credentials to another.
How are WooliiPorter webhooks authenticated?
Every event is HMAC-signed over the raw request body and carries an immutable event ID, delivered at least once across 8 event types. The documented receiver order is verify, deduplicate, process — the signature is checked before the payload is parsed, and the event ID identifies a repeat delivery before anything acts on it.
What does the WooCommerce plugin access in my store?
Orders that reach processing, submitted asynchronously through Action Scheduler outside the customer’s checkout request, plus the product and SKU references those orders need. Activating the plugin imports no historical orders and reads no full product catalog. Status updates return over a store-bound, HMAC-signed webhook.