Read orders and proofs from your own systems
Pull an order's proof status and links into a WMS, ERP or help desk, so the person answering a question never has to open another tool.
Read orders and proofs, push warehouse records and get signed webhooks. Each key carries only the scopes it needs.
One event, end to end
When a buyer approves, a return moves or a pallet is recorded, PallasMark signs a webhook and sends it to your endpoint. Verify the signature, read the event and update your WMS, ERP or help desk.
Every webhook carries an HMAC-SHA256 signature over the timestamp and body, plus a stable event ID.
Recompute the signature with your endpoint secret and compare — standard library code in any language.
Orders, proofs, disputes, returns and warehouse records — subscribe to the ones your system needs.
Webhook events
Why teams connect the API
Evidence that lives in one more dashboard gets ignored
Your team works in a WMS, an ERP or a help desk. If proof only exists in a separate tool, it is checked when someone remembers. When it flows into the systems they already use, it is there when the question comes.
Pull an order's proof status and links into a WMS, ERP or help desk, so the person answering a question never has to open another tool.
Signed webhooks fire when a buyer approves or objects, a dispute is resolved, a return is requested or its evidence arrives, or a pallet record is created.
Warehouse scopes are separate from order scopes. A warehouse integration can push pallet records without ever reading a buyer's name or address.
How the API works
Real scope and event names, exactly as the API uses them.
Step 1 of 4
What you can build on
Scoped keys
Six scopes: read and write for orders, proofs and warehouse records. Tick only what each integration needs.

Warehouse scopes
Warehouse scopes are separate from order scopes, so a WMS can push pallet records without seeing an order or a buyer.
Webhook events
12 events — order approved or disputed, proof delivered, dispute resolved, return requested, evidence requested, received or skipped, return expired or decided, warehouse record created and condition recorded.
HMAC signatures
Every delivery is signed with HMAC-SHA256 over the timestamp and the body, using that endpoint's own secret, in the X-PallasMark-Signature and X-PallasMark-Timestamp headers.

Automatic retries
Failed deliveries are retried automatically with exponential backoff, keeping the same event ID. Each endpoint shows its failure count and a delivery log you can resend from.
Key management
Only a hash of each key is stored; you see the full key once. Each key shows its prefix, scopes and last use, and can be revoked on its own.
Create a key with only the scopes you need, read a proof or push a warehouse record, and subscribe an endpoint to the events you care about.
API access is available on Business and Scale.
Facts, not adjectives. Everything below describes what the product does today — nothing here is on a roadmap.
Availability
API access is available on Business and Scale. Scale capacity is set in your agreement.
Pricing
Proof where you work
Read orders and proofs from your own systems
React, don't poll
Know the moment a buyer decides
Least access by default
A WMS gets warehouse data, nothing else
Questions merchants ask
The PallasMark API is a REST API with signed webhooks that connects packing video proof to the systems you already run. Your WMS, ERP or help desk authenticates with a scoped API key sent as a bearer token, then reads orders and their proofs, creates or updates orders, uploads proof and pushes warehouse records. Webhooks notify your endpoint when a buyer approves or disputes an order, a proof is delivered, a return moves forward or a pallet is recorded. Every webhook is HMAC-SHA256 signed with a per-endpoint secret. API access is included in the Business and Scale plans.
Yes. With an orders:write key your order system can create orders in PallasMark, and with orders:read it can fetch an order together with its proofs, so proof status appears next to the order in your own tools. A proofs:read key can download the evidence for an order or generate its evidence file PDF when you need it. To avoid polling, subscribe an endpoint to order.approved, order.disputed and proof.delivered and update your ERP, WMS or help desk the moment something changes. Shopify and WooCommerce stores can connect without code instead.
PallasMark stores only a SHA-256 hash of each API key, never the key itself. The full key, which starts with dp_, is shown once at creation, so copy it into your secret manager straight away. After that the dashboard shows the key’s name, its prefix, the scopes it holds and when it was last used, which makes it easy to tell integrations apart. A key can be revoked on its own at any time; requests with a revoked key are rejected immediately, while the record stays for your audit trail.
Yes. Warehouse access uses its own scopes, warehouse:read and warehouse:write, which are separate from the order and proof scopes. A key created with only those two can list and create warehouse (pallet) records for your facilities, but any call to an order or proof endpoint is refused with an insufficient-scope error. That lets a 3PL partner or WMS integration push pallet records without ever reading a buyer’s name, address or order history. Warehouse webhooks follow the same idea: their payloads carry the record, pallet and facility, not customer data.
Verify each webhook with HMAC-SHA256 signature verification. Read the X-PallasMark-Timestamp header and the raw request body, join them with a dot (timestamp.body), and compute an HMAC-SHA256 hex digest using that endpoint’s signing secret, which is shown once when you add the endpoint. Compare it with the value after sha256= in the X-PallasMark-Signature header using a constant-time comparison. Reject requests whose timestamp is too old to block replay attacks. Endpoints must use HTTPS, and the X-PallasMark-Event header tells you which event arrived before you parse the body.
Use the event ID as an idempotency key. Every delivery carries a unique evt_ identifier in the X-PallasMark-Webhook-Id header and as the id field of the JSON payload, and that ID stays the same across automatic retries and manual resends. Store the IDs you have processed and skip any you have already seen; return a 2xx status once you have recorded the event. Because the signature covers a fresh timestamp on every attempt, check the signature first, then deduplicate on the event ID before you update your WMS or ERP.
Each event is queued durably before the first attempt, and any delivery that does not get a 2xx response is retried automatically with exponential backoff, starting after one minute and stretching to 24 hours between attempts. Retries reuse the same event ID, so your idempotency check still works. The dashboard shows each endpoint’s status and failure count plus a delivery log with the attempt count and last HTTP status code, and once your endpoint is back you can resend any undelivered event from that log.
The REST API and webhooks are included in the Business and Scale plans; on Scale, capacity is set in your agreement. Keys, webhook endpoints and the delivery log are managed from the Developer page of the dashboard. If you only need your store connected, Free and Pro plans can link Shopify and WooCommerce without writing any code: orders arrive automatically and the proof link is written back to the store order.
Still have a question?
Talk to us and we will walk you through it with your own orders.
Same workflow, two set-ups
The evidence is the same. Who has to go and fetch it is not.
Without the API
Two sources of truthA buyer approves the packing video in PallasMark.
Someone has to notice and update the order in your ERP.
The two systems drift apart over a busy week.
With the API
One source of truthThe buyer approves; order.approved is sent to your endpoint.
Your system checks the signature and updates the order.
Both systems agree, with no one copying anything.
Scoped keys and signed webhooks on Business and Scale — so evidence reaches the tools your team already runs.
Each part is useful on its own. Together they turn one recording into an answer for every kind of claim.