Migrating to site-scoped protection levels

Protection levels are moving from your account to your sites. Today one set of levels is shared across every site you operate. After this change each site has its own levels, with its own prices. This guide covers what changes in the API, what you need to do, and when.

Why

Protection prices can differ from site to site, which operators with mixed markets need and can’t currently do.
It’s a prerequisite for connecting multiple Stripe accounts to one Stora account, which we’re building now.

The two phases

Your account moves through two phases.

Every account is in Preparation until we switch it over. We’ll tell you before we activate yours, and we’ll give you notice.

Preparation

We’ve replicated every global protection level to every site on your account. Each site copy is a distinct product:

its own protection level ID
its own product and price in Stripe
its own base price

Globals remain the source of truth. We mirror changes down to the copies — edit a global’s base price and every site copy follows. Site copies can’t be edited independently during this phase, so a customer sees the same price whichever route they come through. You’ll see duplicate products and prices in your Stripe account as a result.

Don’t archive the duplicate products and prices in Stripe. They’re the live products for your sites once you’re switched over.

Nothing in the API changes by default in this phase. Global levels are still returned by default and still accepted on orders. The Back Office and Storefront still work in terms of global protection levels; the site copies aren’t surfaced there. This phase exists to give you time to migrate.

Activation

When your account is switched over, site protection levels become authoritative everywhere — API, Back Office and Storefront.

The API returns site levels and rejects global IDs on new orders.
Global levels can no longer be created, and their base prices can no longer be changed, in the API or the Back Office.
The Back Office moves protection management from your account to each site.

Affected endpoints

Endpoint	What changes
`GET /2025-09/protection_levels`	New `site_scoped` and `site_id` parameters available now. Returns site levels by default after activation.
`GET /2025-09/protection_levels/{id}`	Resolves site levels as well as globals now. Keeps resolving globals after activation, for referential integrity.
`POST /2025-09/protection_levels/{id}/base_price`	Still writes to global levels, and we mirror the change to every site copy. Rejected for global levels after activation.
`POST /2025-09/orders`	Global protection IDs rejected after activation.
`PATCH /2025-09/orders/{id}`	As above.
`POST /2025-09/orders/{id}/finalize`	As above.
`POST /2025-09/orders/{id}/line_items`	As above.
`PATCH /2025-09/orders/{id}/line_items/{line_item_id}`	As above.
`GET /2025-09/orders/{id}/validate`	An order holding a global protection level stops validating after activation.
`POST /2025-09/deals`	Global protection IDs rejected after activation.
`PATCH /2025-09/deals/{id}`	As above.

All of this stays within API version 2025-09. You don’t need to upgrade to a later version to migrate.

Listing protection levels

By default the collection returns your global levels, unchanged:

GET /2025-09/protection_levels

To reach your site levels, add site_scoped=true. This is the parameter we recommend building against. It returns every site level across your account, with the globals excluded — which is exactly what the unfiltered collection will return once you’re activated:

GET /2025-09/protection_levels?site_scoped=true

Use it as your default listing call during preparation. It gives you the whole site-level catalogue in one place, it’s the closest thing to the post-activation response you can see today, and it doesn’t require you to know your site IDs up front. If you’d rather narrow to particular sites, filter by site ID instead. Pass several, comma-separated, to cover more than one:

GET /2025-09/protection_levels?site_id=site_3e6ffcb963dc4b49,site_76cc3340ef180e55

Both site_scoped and site_id return 409 Conflict until we’ve finished preparing your account. If you see Site-scoped protection levels are unavailable until insurance preparation is complete for this operator, your site copies don’t exist yet — retry once we’ve confirmed your account is prepared.

site_scoped is a migration parameter. It exists for this transition, so you won’t find it in the API reference — this guide is its documentation. It works while your account is being prepared, and once you’re activated it’s no longer needed, because by then the plain call returns exactly what it returns today:

GET /2025-09/protection_levels

So the shape of the migration is: send site_scoped=true now, drop it once you’re switched over. site_id is not temporary. It’s part of the API and is the filter to keep in your integration long term. The collection never mixes globals and site levels.

The `site` field

Protection levels have a site. It’s null on a global level, and on a site level it gives you the site’s ID:

{
  "id": "plvl_e8f3ad0a07e47566",
  "cover_level": { "amount": 2000000, "currency": "GBP", "formatted": "£20,000.00" },
  "prices": [
    {
      "billing_period": "weekly",
      "price": { "amount": 999, "currency": "GBP", "formatted": "£9.99" },
      "stripe_price_id": "price_123"
    }
  ],
  "site": { "id": "site_14b419f1096013f1" },
  "stripe_product_id": "prod_Sj6us30iGDiaXO",
  "public": true
}

site is expandable, so ask for the full site object when you need more than the ID:

GET /2025-09/protection_levels?site_scoped=true&expand=site

Note the stripe_product_id too — each site copy has its own, which is why the duplicates appear in your Stripe account.

Setting base prices

Base prices are still written to global levels, and we mirror each change down to every site copy:

POST /2025-09/protection_levels/{id}/base_price

Passing the ID of a site copy returns 404. Site copies can’t be priced independently during preparation — that’s what keeps a customer’s price the same whichever route they come through. After activation this reverses: site levels become writable and global levels are rejected.

Creating and updating orders

Right now, orders accept either a global protection ID or a protection ID belonging to the order’s site. After activation, only the latter.

POST /2025-09/orders

{
  "site": { "id": "site_14b419f1096013f1" },
  "line_items": [
    {
      "type": "protection",
      "quantity": 1,
      "price": { "amount": 2999 },
      "item": { "id": "plvl_e8f3ad0a07e47566" }
    }
  ]
}

Other order fields are omitted here for brevity. The protection level is the one listed above, and it belongs to the site the order is for — that pairing is the whole change. Two rules to code against:

Resolve the site first. Pick the protection level from the site the order is for, not from a stored global ID.
A protection level from the wrong site is rejected, the same as a global one, once you’re activated.

Deals follow the same rule. A protection line item on POST /2025-09/deals or PATCH /2025-09/deals/{id} must reference either an account-level protection level or one belonging to the deal’s site.

If your integration holds a hardcoded or cached protection level ID anywhere, that’s the thing most likely to break. Find it now.

Webhooks

Event types and API version are unchanged:

protection_level.created
protection_level.updated

Which resource they describe follows your phase:

Phase	Global level saved	Site level saved
Preparation	Event fires	No event
Activated	No event	Event fires, with its site

So during preparation you’ll keep receiving events for globals exactly as you do now, and replication won’t flood your endpoint. At activation the resource in the payload becomes a site level.

What doesn’t change

Existing orders and subscriptions. They keep the protection level IDs they were created with. We don’t rewrite stored references, and historical resources keep returning the IDs you already have.
Prices your customers pay. Site copies start identical to their globals and are kept in sync until activation.
Tax. Not affected by this change.
API version. Everything here is 2025-09.
The Back Office and Storefront, until activation.

Getting help

Email api_support@stora.co with your account name and what you’re building. We’re happy to review your integration changes before you ship them, and to switch your account over early if you’re ready ahead of us.

Booking flow

See where protection line items sit in the end-to-end order flow.

Webhooks

Configure endpoints and check which API version your payloads use.

Getting started

Concepts

Working with the API

Building integrations

Resources

Migrating to site-scoped protection levels

Why

The two phases

Preparation

Activation

Affected endpoints

Listing protection levels

The `site` field

Setting base prices

Creating and updating orders

Webhooks

What doesn’t change

Getting help

Booking flow

Webhooks

​Why

​The two phases

​Preparation

​Activation

​Affected endpoints

​Listing protection levels

​The site field

​Setting base prices

​Creating and updating orders

​Webhooks

​What doesn’t change

​Getting help

Booking flow

Webhooks

Why

The two phases

Preparation

Activation

Affected endpoints

Listing protection levels

The `site` field

Setting base prices

Creating and updating orders

Webhooks

What doesn’t change

Getting help