Meet your store
where it already is.

Choose your path.

One API, whichever way your store is built. The WordPress plugins need no code, the Medusa plugin takes a little setup, and a Shopify app is in development. The libraries and the REST API are for a store you build yourself, and the integration guide takes them step by step. Every path that uses a key keeps it on your server; never expose it to a browser.

Installing the Shopify app.

The Post Coverage app for Shopify is not in the Shopify App Store yet: ask your Post Coverage contact for the install link. While it is in the sandbox, the checkout offer runs on Shopify development stores only, and needs a store on the Shopify Plus plan. Protection always starts off: the shopper chooses it.

There are two ways to start. Both are quick.

Start on this website

1. Sign up, set up your business, and open Settings, then Integration, in your dashboard.
2. Enter your store’s .myshopify.com address and press Get my install link.
3. Press Install the Post Coverage app and approve it in Shopify.
4. When the app opens in your Shopify admin, check that its request code matches the one on your dashboard, then link your business with one click.

Start in Shopify

1. Install the app with its install link.
2. In the app, press Set up Post Coverage. Your store’s details are filled in from Shopify: check them, make three short choices, and create your account. The store is connected straight away.
3. Check your email for how to sign in.
4. Sign in at postcoverage.com with that email address to open your dashboard.

Already have an account? In the app, choose I already have an account.

Once connected, Post Coverage adds its protection prices to your store, which takes a few minutes. Then, in the checkout editor, turn on the Post Coverage block, and exclude Package protection from your discounts.

Your dashboard’s Integration settings show whether the store is linked. Claims are settled by the Post Coverage team. The app sends no customer names, email addresses, phone numbers or postal addresses to Post Coverage.

Two plugins for your own WordPress.

Install either from Plugins, Add New, Upload Plugin. Both need PHP 8.0 and WordPress 6.4 or later, call Post Coverage only from your server, and ship with their readable source and a translation template.

Each readme’s External services section lists every request the plugin makes, when, and what it sends. Neither plugin sends customer names, email addresses, phone numbers, postal addresses, or payment details. The earlier single-file WooCommerce scaffold has been withdrawn: it stored the private claim code in plain order metadata. Delete it before installing these.

Both plugins, like the API, are covered by the Coverage and sandbox terms and the Privacy notice.

Your first test order.

Create your business workspace, generate a sandbox key in Integrations, and send a request from your server. This one records an order whose customer left protection off, so it needs no quote.

curl -X POST 'https://3feo7wip5b.execute-api.us-east-1.amazonaws.com/integrations/v1/orders' \
  -H 'Content-Type: application/json' \
  -H 'X-API-Key: YOUR_SERVER_SIDE_SANDBOX_KEY' \
  -d '{
    "externalId": "TEST-ORDER-1001",
    "amountCents": 4800,
    "currency": "USD",
    "purchaseType": "recurring",
    "customerOptedIn": false,
    "coverageEligible": true,
    "customerKey": "TEST-CUSTOMER-1001",
    "deliveryStatus": "processing"
  }'

A protected order starts with a quote and carries the quote’s pricingVersion, and its answer holds a once-only access code. The integration guide shows both steps.

Sandbox only. Do not send real customer names, email addresses, phone numbers, street addresses, payment details, or product descriptions. Unknown fields are rejected.

Two small libraries for your server.

The dependency-free JavaScript client works with Node.js 22+ and includes TypeScript declarations. The PHP library is one file for PHP 8.0+ that needs only the curl and json extensions, with no Composer dependency, and is namespaced so it cannot collide with anything on a WordPress site. Both keep keys on the server, reject redirects and unsupported fields, and retry transient reads and idempotent order events with bounded backoff.

Order creation and private-link resets are never retried automatically: a lost response may contain a once-only credential. Reconcile the same external reference, then explicitly reset its private claim link if needed. The reset invalidates every previous code while preserving the case and conversation.

See both libraries at work in the integration guide

Every order belongs in the picture.

Send selected, declined, and ineligible synthetic orders. A declined order has customerOptedIn: false; an ineligible order also has coverageEligible: false. Neither receives a fee, policy, or claim code. Reports describe the orders received, so an integration sending only protected orders cannot establish whole-store opt-in. Recurring purchase events use purchaseType: recurring, a unique externalId per transaction, and an explicit customer opt-in flag.

The optional customerKey is an opaque test identifier scoped to your store. It supports an observed repeat-customer measure without a customer name or email. Delivery status is an initial snapshot; carrier tracking updates are not connected yet.

Small surface. Clear behavior.

A familiar face in their inbox.

Preview branded test confirmations, private case notifications, and store-credit emails. The renderer produces HTML and plain text; it does not accept recipient addresses or send anything. Private case links belong in a transactional flow with tracking disabled.

Explore branded email previews

• JavaScript clientpost-coverage.mjs
• TypeScript declarationspost-coverage.d.mts
• PHP librarypost-coverage.php
• Test email rendererpost-coverage-emails.mjs

For schema details, see the OpenAPI specification. For the order of calls and the checkout rules, see the integration guide.