Readiness API

Use readiness as a checklist

GET /api/developer/readiness summarizes the signed-in developer account. GET /api/developer/storefront/readiness focuses on its brand website. GET /api/developer/products/{productId}/readiness inspects a product for its actual owner or a platform administrator.

These handlers use the signed-in account identity, not an arbitrary effective workspace owner. A team invitation or selected-product assignment does not make a teammate the product owner. A product check can return FORBIDDEN even when another product-management endpoint permits that teammate.

Read the reasons, not only the score

The response includes scope, status, goLiveReady, completionPercent, generated_at, categories, blockers and warnings, plus derived checklist/next-action information. Each category includes its status, weight, evidence and suggested actions. Common areas include product/delivery setup, Brand Manager and Website Builder, marketplace placement, billing, settlements, commerce and email readiness.

A ready response is not publication, provider activation, a guaranteed live checkout, or a native plugin runtime certification. Warnings can concern optional marketplace participation. Review the individual category and product capabilities rather than treating every warning as a universal launch requirement.

Do not poll these as a zero-write health check

Some diagnostic paths can initialize or refresh supporting settlement/sender records. They are private account diagnostics, not a public uptime probe. Do not publish raw evidence, account configuration or private product results. For provider readiness, use the relevant setup workflow and confirm its current state.