ChannelWeave Website Connector Verification Checklist - v2
Developer and agency starter/reference pack - 10 October 2026

Hand this to your developer or agency. It is a test record, not a finished
connector or production certification. Reference: /docs/reference/website-api

1) Prepare a controlled test
- [ ] Agree a test environment, test stock and downstream effects first.
- [ ] Replace the fictional order reference and SKU in the v2 JSON example.
- [ ] Use a SKU that exists in the connected account's stock.
- [ ] Remember: a zero-price order is not a dry run; normal order and stock
      workflows still apply. Do not use a real customer's order as a test.

2) Map the request
- [ ] Created: POST /webhooks/website/orders/created with top-level
      external_order_ref, currency_code and a non-empty line_items array.
- [ ] Each line has a SKU and positive quantity; use the transaction currency.
- [ ] Cancelled: POST /webhooks/website/orders/cancelled with the same
      external_order_ref and currency_code. Lines are not required.

3) Authenticate and sign on the server
- [ ] Store the Website API key and signing secret outside browser code.
- [ ] Send Authorization: Bearer <website_api_key> on Website API requests.
- [ ] Order webhooks also have X-CW-Timestamp (current Unix whole seconds)
      and X-CW-Signature: v1=<hmac_sha256_hex>.
- [ ] Compute HMAC-SHA256 using the signing secret over timestamp.raw_body.
      Send the unchanged UTF-8 JSON body; do not re-serialise after signing.
- [ ] Verify missing auth, altered signatures and timestamps more than
      300 seconds (five minutes) away are rejected. Keep clocks accurate.
- [ ] Test new credentials during rotation's 24-hour overlap, before the
      previous API key or signing secret expires.

4) Verify delivery and retries
- [ ] Inspect HTTP results, the created order, lines and stock availability.
- [ ] Test cancellation and released reservations on the controlled order.
- [ ] Retry an unchanged order with the same external_order_ref and line
      ordering, but a fresh timestamp and signature for each attempt.
- [ ] Check repeated delivery does not create an extra order. Do not assume
      exactly-once processing or idempotency-key deduplication for orders.
- [ ] Implement bounded sender retries and a visible failed-delivery record.
      Incoming orders are processed immediately, not queued for retry for you.

5) Check your website's stock caching
- [ ] Website/relay dynamic stock responses use Cache-Control: no-store.
- [ ] CDN rules bypass dynamic stock responses; stale-while-revalidate is off.
- [ ] Verify actual response headers and refreshed stock after the test.
- [ ] Catalogue and stock reads use the bearer token only, not order signatures.

Developer / date:
Test order reference / environment:
Results and unresolved checks: