Consumer migration guide

Who should read this

Use this guide if you already integrated Pomelo and still:

• install a manual snippet by default
• read mixed routes as if they were fully available or fully locked
• consume deprecated /v1/me mirrors
• send deprecated public API date parameters
• hardcode collection_profile, plan capabilities, or route classes

Canonical replacements

Old pattern	Canonical path now	Status	Sunset / review
Hand-authored snippet with runtime config in HTML	Use the dashboard-generated single script tag	migrate now	immediate
Read plan_id from GET /v1/me	Read product.runtime_plan_id	deprecated mirror	no removal before 2026-07-03T00:00:00Z
Read retention_days from GET /v1/me	Read product.product_retention.api_retention_days	deprecated mirror	no removal before 2026-07-03T00:00:00Z
Send start / end to public /v1/* routes	Send from / to	already removed from the public runtime	migrate now
Read only availability.sections on overview, acquisition, or actions	Read availability.readModel first, then availability.sections	migrate now	immediate
Hardcode collection_profile or route classes in the client	Read product, product_configuration, and availability instead	migrate now	immediate

Snippet migration

Preferred path:

1. Copy the generated snippet from the dashboard.
2. Paste the single analytics script tag in your site head.
3. Keep collection profile, autocapture, and tenant settings in Pomelo.

If your framework injects scripts from code instead of pasting raw HTML, render the same contract:

• https://cdn.pomeloanalytics.com/latest/analytics.js
• the data-site-id from Pomelo

Do not embed runtime configuration JSON in your app. The SDK loads the active site configuration from Pomelo at startup.

Do not rely on legacy snippet attributes such as:

• data-autocapture-ui
• data-autocapture-forms
• data-autocapture-errors
• data-capture-localhost
• data-allow-params

See also: SDK Integration.

Public /v1/* requests must already use from and to. Only the internal dashboard /metrics/* proxy still uses start/end under its own shared contract.

Mixed route migration

Read mixed routes in this order:

1. availability.readModel
2. availability.sections

Interpretation:

• availability.readModel.strictSafe is the usable baseline always returned in Strict
• availability.readModel.extended is the enriched layer that Extended unlocks
• availability.sections describes whether those enriched slices are available, locked, or partial for the selected period

Do not treat a mixed HTTP 200 as “everything succeeded”.

See also: Strict, Extended & Mixed Reports.

Non-retroactivity

Switching a site from Strict to Extended is prospective only.

That means:

• future compatible data can become richer
• older periods are not backfilled
• an already open tab may still run the older runtime until reload

What to avoid hardcoding

Do not hardcode:

• collection_profile
• plan capabilities
• route classes
• mixed-route slice availability
• deprecated /v1/me mirrors

Backend route ids such as audience_summary or technology are internal read model identifiers, not extra public API routes.