STORE DOMAIN: <your-store>.myshopify.com
PORTAL LINK: <the link you copied under Storefront & Portal > Customer Portal in Subi>This site sells through Shopify's Storefront API. The store uses the Subi app for subscriptions and memberships. Subi puts its plans on the Shopify products as selling plans, and Shopify's checkout creates the subscription when a cart line carries one. Make the site sell them. Never hardcode a plan id or a plan price.1. Read the plans. Wherever the site fetches products from the Storefront API, add these fields to the product query:
   requiresSellingPlan
   sellingPlanGroups(first: 10) { nodes { appName name sellingPlans(first: 20) { nodes { id name recurringDeliveries } } } }
   and on each variant:
   sellingPlanAllocations(first: 20) { nodes { sellingPlan { id name } priceAdjustments { price { amount currencyCode } compareAtPrice { amount currencyCode } } } }
   If the site uses a private Storefront access token, keep it on the server.2. Show the plan's own price. For a subscription or membership option, show priceAdjustments[0].price from the selected variant's sellingPlanAllocations for that plan. That is the price Shopify charges at checkout. If a second price adjustment is returned, show it as the price from later orders. Where the page has a price written in for a subscription or a membership tier, replace it with the value from the API. Offer a subscribe option only on a product that returns a selling plan; a product that returns none is sold as a one-time purchase only.3. Membership tiers. Each tier's Join button maps to a variant of the membership product and one of the selling plans allocated to that variant (match by the variant and plan names the API returns). Where a variant has more than one plan (for example 6 months and 12 months), show one Join option per plan. The button adds that variant with that selling plan. A membership product returns requiresSellingPlan true, so it is never added without one.4. Put the plan on the cart line. In cartCreate and cartLinesAdd, send each subscription line as { merchandiseId: <variant id>, quantity: 1, sellingPlanId: <selling plan id> }, with both ids exactly as the API returned them (gid://shopify/ProductVariant/... and gid://shopify/SellingPlan/...). A one-time line has no sellingPlanId. In the response, ask for cart { id checkoutUrl lines(first: 20) { nodes { id quantity sellingPlanAllocation { sellingPlan { id name } } } } }, userErrors { field message } and warnings { code message }. If userErrors is not empty, show the message and do not open checkout. Never turn a subscription line into a one-time line on your own. Show each line's plan name in the cart, then send the shopper to cart.checkoutUrl.5. A way back in. Add a "Manage my subscription" link to the footer and to the account or member area, pointing to the PORTAL LINK above. Subscribers skip, pause and cancel there. Do not build those actions on this site.6. Test before any button goes live. In a preview, for every tier and every subscribe option: add it to the cart, check that the cart response has sellingPlanAllocation set on that line, open checkoutUrl and check that the checkout shows the item as a subscription with the right price and delivery frequency. Do not place an order. Tell me which checks passed and which failed, and change nothing else on the site.

Add a server function that receives Subi webhooks at /api/subi-webhook (a Supabase Edge Function in Lovable, a server route in Replit).1. Read the raw request body before parsing any JSON. Compute HMAC-SHA256 of the raw bytes with SUBI_WEBHOOK_SECRET, encode the result as base64, and compare it with the X-Subi-Hmac-Sha256 header in constant time. If they differ, answer 401 and stop.
2. Answer 200 within 10 seconds and do any slow work after answering. Do not redirect: a 3xx answer counts as a failed delivery.
3. Keep SUBI_WEBHOOK_SECRET and SUBI_API_KEY as server secrets. Never send either to the browser.
4. Webhooks name the customer by their Shopify customer ID (subscription_contract.customer_id). For the email, call GET https://api.subi.co/public/v1.0/subscribers/<customer_id>/ from this server function with the key in the X-Api-Key header.
5. Read the event name from the X-Subi-Topic header. On SUBSCRIPTION_CREATED and SUBSCRIPTION_RESUMED, give access only if one of subscription_contract.lines has the membership product's product_id. On SUBSCRIPTION_PAUSED and SUBSCRIPTION_CANCELED, take access away unless the customer still has another active contract with that product: list GET https://api.subi.co/public/v1.0/subscription-contracts/?customer_id=<customer_id>&status=ACTIVE and read each one with GET https://api.subi.co/public/v1.0/subscription-contracts/<id>/, the only call that returns its lines.
6. Use the X-Subi-Event-Id header so the same event is handled only once.
7. Subi sends no login token, so this endpoint must accept requests without one (in a Supabase Edge Function, turn off JWT verification for it). Tell me the full https URL to register in Subi.