Test and go live

This is the final step of a custom integration. You'll run the full flow — fetch an offer, register a sale, and confirm the warranty was created — against staging, then swap your staging credentials and endpoints for the production set and re-verify before you send real traffic.

❗

Do the whole dry run on staging, then swap the entire credential set at once

Staging and production are separate environments with separate tokens and separate endpoints. A staging token is rejected by production, and vice versa. Build and verify against staging, then change tokens and host URLs together in one cutover — never hard-code one environment's value where the other runs. See Get your credentials.

Prerequisites

Before you start the dry run, confirm:

• Your custom integration is wired up end to end — see Initialize the SDK, Add a warranty to an order, and Register the sale.
• You have your staging Retailer ID, Public Token, and API token. See Get your credentials.
• You have your production Retailer ID, Public Token, and API token ready to swap in (but not yet wired up).
• Environment selection is config-driven — tokens and host URLs come from an environment flag, not from inline literals.
• If you consume webhooks, your order_success_url is configured and webhook delivery is enabled for your staging account. See Webhook catalog.

Point everything at staging

Select your staging configuration before testing. A custom integration talks to two surfaces, and both have a staging host:

Load the staging SDK script and initialize with your staging Public Token, and point your server's POST /api/checkout calls at the staging host with your staging API token.

🚧

The Public Token and the API token are different credentials

The browser SDK initializes with your Public Token (mulberry.core.init({ publicToken })). Your server authenticates POST /api/checkout with your API token as Authorization: Bearer <token>. They are not interchangeable — sending one where the other is expected returns 401 Unauthorized. See Get your credentials.

Run the dry run on staging

1. Fetch a test offer

On a test page, initialize the SDK and fetch offers for a product you know is covered:

await mulberry.core.init({ publicToken: 'YOUR_STAGING_PUBLIC_TOKEN' })
await mulberry.core.initCompleted

const offers = await mulberry.core.getWarrantyOffer({
  id: 'OSLO-XYZ',
  title: 'Oslo Chaise in Velvet',
  price: '2999.00', // your platform's price, passed through unchanged
})

You should now see a non-empty array of offer objects. Each one carries the warranty_offer_id you'll register in the next step.

🚧

Pass the price unchanged — don't convert it to cents

getWarrantyOffer forwards price to Mulberry's offer API exactly as you pass it. Use the decimal amount your platform already gives you and pass it through — don't multiply it to cents. For the full offer contract, see Mulberry SDK reference.

• An empty array ([]) means Mulberry has no coverage for that product — pick a product you know is covered for this test.
• null means the SDK's geo gate rejected the test visitor's location (core.validLocation is false), and an error is logged to the console. Test from a supported region.

2. Register a test sale

From your server, register the offer the same way your production code will — POST /api/checkout against the staging host, authenticated with your staging API token, sending the selected warranty_offer_id:

POST https://staging.getmulberry.com/api/checkout
Authorization: Bearer <your-staging-api-token>
Content-Type: application/json

{
  "order_id": "test-order-0001",
  "email": "[email protected]",
  "billing_address": { "state": "NY", "zip": "10001" },
  "line_items": [
    { "warranty_offer_id": "<warranty_offer_id-from-step-1>" }
  ]
}

A successful registration returns HTTP 200:

{ "success": true, "order_id": "test-order-0001", "data": { "...": "..." } }

You should now have a 200 with "success": true and the order_id you sent echoed back. For the full request and response contract, see Register the sale.

• Use a fresh, unique order_id for each test run. Registration dedupes by order_id per retailer — re-posting the same id returns 400 with order already exists.
• A 401 here means a missing or wrong-environment API token, or the token was sent to the wrong host. Confirm you're using the staging token against the staging host.

3. Verify the warranty registered

Confirm the sale actually created a warranty contract — don't rely on the 200 alone. Use either signal:

• Partner dashboard — sign in to the staging dashboard, find the order by the order_id you sent, and confirm the warranty appears against it.
• ORDER_SUCCESS webhook — if you consume webhooks, Mulberry sends an ORDER_SUCCESS event when the sale is confirmed. Correlate it to your test by the external_order_id you supplied (the order_id from step 2). See Webhook catalog.

You should now see the test warranty either in the dashboard or as a received ORDER_SUCCESS webhook tied to your order_id.

📘

The 200 and the contract are two different confirmations

A 200 from POST /api/checkout means the request was accepted. The dashboard entry — or the ORDER_SUCCESS webhook — is what confirms the warranty contract exists. Always verify the second signal before you treat a sale as registered.

4. Confirm the claims handoff

Once the test warranty is registered, the customer can file a claim against it. Confirm your integration is ready to receive claim activity:

• If you react to claims programmatically, make sure your CLAIM_UPDATE (and, where applicable, CLAIM_REPLACEMENT) endpoints are configured and verifying signatures. See Webhook catalog and React to claim updates.
• For how claims are filed and what your side must handle, see How claims work.

You should now have confirmed that a registered warranty is claimable and that your claim-handling endpoints are wired up.

Cut over to production

With the staging dry run passing end to end, switch to production:

1. Swap your staging Public Token and API token for the production set, sourced from config — not inline.
2. Point the SDK script and offer calls at the production host (https://app.getmulberry.com/...) and your POST /api/checkout calls at https://www.getmulberry.com.
3. Confirm webhook delivery is enabled for your production account and your production endpoint URLs are configured. See Webhook catalog.
4. Re-run steps 1–3 of the dry run against production with a real, low-stakes order, and confirm the warranty registers in the production dashboard.

You should now see a real warranty registered against a production order — your integration is live.

👍

You're live

Offers render from production, sales register through POST /api/checkout, and warranties show up in the production dashboard. Keep the staging set in config so you can re-test changes against staging before each release. For anything you can't verify here, contact your Partner Success manager.