Going live · Subby Docs

Request live access, then work through the checklist before real customers subscribe through Subby's subscription engine.

When your integration works end to end in sandbox, request live access and work through this checklist before real customers subscribe through Subby.

Request live access

Go to Dashboard → Developers → Go live.
Tell us about your business: registered name, what you sell, expected monthly subscribers and collection volume, and your website.
Choose your API plan: Starter, Growth or Scale. For Enterprise, talk to sales.
Complete business verification if you haven't already.
Submit.

We review requests within 2 business days. You'll get an email when you're approved, and live keys become available in Developers → API keys. You can keep building in sandbox the whole time.

Launch checklist

Keys and configuration

[ ] Live secret key stored in your production secrets manager, not in code.
[ ] Live publishable key (pk_live_) used only in the browser, WordPress plugin or Shopify app.
[ ] Checkout origins added to the live publishable key allow-list.
[ ] Base URL set to https://api.mysubbyapp.com/v1 in production, and sandbox everywhere else.
[ ] Each internal service uses its own restricted key with the smallest scope it needs.
[ ] Nobody on the team has a live key on their laptop.

Plans

[ ] Plans recreated in live with correct amounts in kobo.
[ ] retry_logic and reminders reviewed for each plan. The defaults suit most monthly plans, but weekly or per-delivery plans usually need shorter intervals.
[ ] escalation_on_failure matches what your product actually does when someone doesn't pay.
[ ] Reminder copy previewed in Dashboard → Nudge templates.

Webhooks

[ ] Live webhook endpoint created. Remember the sandbox endpoint doesn't carry over.
[ ] Live whsec_ secret stored in production.
[ ] Signatures verified on every request, with the timestamp check.
[ ] Handler returns 2xx quickly and processes on a queue.
[ ] Handler skips duplicate event.ids.
[ ] Handler copes with events arriving out of order.
[ ] Alerts set up for failing deliveries.

Reliability

[ ] Every POST sends an Idempotency-Key.
[ ] 429 responses are retried after Retry-After with jitter.
[ ] 5xx responses and timeouts are retried with backoff and the same idempotency key.
[ ] You log X-Request-Id for every failed request.
[ ] Your code ignores unknown fields, event types and enum values.

Usage and cost

[ ] You've estimated monthly write requests: roughly 2–3 per new subscriber, plus your own updates and actions.
[ ] You aren't polling with write requests. Status checks use webhooks and GET.
[ ] Usage alert recipients set in Developers → Usage → Alerts.
[ ] You know your plan's included nudges and how many your retry schedule is likely to send.

Customer experience

[ ] Checkout success and cancel URLs point to your production site.
[ ] Your product removes and restores access correctly on subscription.paused, subscription.recovered and subscription.cancelled.
[ ] Customer support knows where to find a customer's subscription and charges in the Subby dashboard.

After launch

Watch Developers → Request logs and Webhooks → Deliveries closely for the first few days.
Run a small real transaction with a team member's card and cancel it, so you've seen the full live flow once.
Subscribe to the changelog and status page.