API & webhooks: Put proof into the systems you already run

Read orders and proofs, push warehouse records and get signed webhooks. Each key carries only the scopes it needs.

One event, end to end

Your systems hear about it the moment it happens

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.

  1. 1

    Signed delivery

    Every webhook carries an HMAC-SHA256 signature over the timestamp and body, plus a stable event ID.

  2. 2

    Verified in a few lines

    Recompute the signature with your endpoint secret and compare — standard library code in any language.

  3. 3

    Twelve events to build on

    Orders, proofs, disputes, returns and warehouse records — subscribe to the ones your system needs.

Webhook events

  • order.approved
  • order.disputed
  • proof.delivered
  • dispute.resolved
  • return.requested
  • return.evidence_requested
  • return.evidence_received
  • return.evidence_skipped
  • return.expired
  • return.decided
  • warehouse.record_created
  • warehouse.condition_recorded

Why teams connect the API

Evidence that shows up where your team already works

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.

Proof where you work01

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.

React, don't poll02

Know the moment a buyer decides

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.

Least access by default03

A WMS gets warehouse data, nothing else

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

From a scoped key to a verified webhook in four steps

Real scope and event names, exactly as the API uses them.

Step 1 of 4

What you can build on

Narrow keys, named events, signatures you can check

Scoped keys

Scopes per key

Six scopes: read and write for orders, proofs and warehouse records. Tick only what each integration needs.

An operations manager reviews a tablet with a warehouse supervisor above the fulfilment floor

Warehouse scopes

Warehouse kept apart

Warehouse scopes are separate from order scopes, so a WMS can push pallet records without seeing an order or a buyer.

Webhook events

Events named after what happened

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

Signatures you can check

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.

Two e-commerce operations managers review order records on a laptop next to the warehouse

Automatic retries

Retries you do not build

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

Keys you can trace and revoke

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.

Connect your first system

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.

  1. 1Create a Business or Scale API key with only the required scopes.
  2. 2Read an order's proofs, or push a warehouse record.
  3. 3Subscribe an endpoint and verify each signature.
View API access plans

API access is available on Business and Scale.

API and webhook facts

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
Two e-commerce operations managers review order records on a laptop next to the warehouse
  • 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

01
Scopes
orders:read, orders:write, proofs:read, proofs:write, warehouse:read, warehouse:write
02
Webhook events
Order: approved, disputed · Proof: delivered · Dispute: resolved · Return: requested, evidence requested, evidence received, evidence skipped, expired, decided · Warehouse: record created, condition recorded
03
Authentication
Bearer API key (dp_…); stored as a SHA-256 hash, shown in full once
04
Signing
HMAC-SHA256 of “timestamp.body” with a per-endpoint secret; X-PallasMark-Signature (sha256=…), X-PallasMark-Timestamp, X-PallasMark-Event, X-PallasMark-Webhook-Id headers
05
Retries
Exponential backoff from 1 minute up to 24 hours; same event ID on every attempt; delivery log with one-click resend
06
Key visibility
Name, prefix, scopes and last use per key; revoke any key on its own
07
Plans
Business and Scale

Questions merchants ask

API and webhook questions

What is the PallasMark API?

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.

Can I connect packing videos to my order system via API?

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.

How is the key stored?

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.

Can I give a partner warehouse access only?

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.

How do I verify a webhook?

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.

How do I avoid processing the same webhook twice?

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.

What happens if my endpoint is down?

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.

Which plans include the API?

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

Checking proof by hand, or having it arrive on its own

The evidence is the same. Who has to go and fetch it is not.

Without the API

Two sources of truth
  1. 1

    A buyer approves the packing video in PallasMark.

  2. 2

    Someone has to notice and update the order in your ERP.

  3. 3

    The two systems drift apart over a busy week.

With the API

One source of truth
  1. 1

    The buyer approves; order.approved is sent to your endpoint.

  2. 2

    Your system checks the signature and updates the order.

  3. 3

    Both systems agree, with no one copying anything.

Let your systems hear about the proof as it happens.

Scoped keys and signed webhooks on Business and Scale — so evidence reaches the tools your team already runs.