Trust & compliance

No empty promises — here is the mechanism that makes zero-PII true, by construction.

The zero-PII data model

What is stored

Hashed, opaque pseudonymous ids (pptId hashes, correlation hashes).
Token id hashes (revocation, dedupe); raw tokens never persisted.
Opaque shipment/return/estimate refs, carrier refs, status, timestamps.

What is never stored

Your name, routing details, contact, or payment data — at any layer.
Raw addrToken or routing targets — transient, in-memory/in-flight only.
Request bodies, or tokens, in logs, errors, headers, URLs, or analytics.

All rows are TTL-bound and purged; audit is append-only and contains no bodies, no tokens, no personal data. Zero-PII is a build-time gate — the schema, code, logs, and analytics are scanned on every change.

Tokens, signatures, custody

Trust-service tokens are verified server-side (signature, expiry, audience, scope, revocation).
Merchant signing keys stay under merchant control (hooks/HSM).
mTLS client certs (avs-mtls) per trust service, loaded from secrets at runtime — never in the repo.
LTS signing keys sit in KMS/secrets; merchant API keys are stored hashed only.

Hosting & compliance posture

Static site + Netlify Functions + managed external datastore + secrets/KMS. Strict CSP, Referrer-Policy: no-referrer, no third-party trackers, no identifying cookies, privacy-preserving aggregate analytics only. Regulated-site logging, retention, breach, and residency requirements are absolutes — spec-gated and audited per country.

Service status · FAQ