Use annotated console walkthroughs to find each screen, configure it and check the result.
SDK 0.0.1Updated
1. Prepare your App’s configuration
Select Sandbox, configure origins and verify the customer identity.
Connect the current App and Sandbox
Integrations → SDK setup
Isolated fixture capture of current components; no persistence or live-service calls.
1
Prepare trusted identity and origins
An Owner, Admin or Developer with App access and apiKeys:write configures a server key and the complete HTTPS origin for app.example.com. The backend verifies its user; the browser receives only a customer token.
Check the resultActual progress comes from persisted App facts. This empty fixture does not prove a live connection.
2. Grant current key permissions
The server key and browser customer token have separate authorization boundaries.
Choose current key permissions
Integrations → SDK setup → Create Key
Isolated fixture capture of current components; no persistence or live-service calls.
1
Grant only required permissions
Keep secret keys on the trusted backend. Separate read permissions from consumption. A customer token cannot select another customer through parameters.
Check the resultThe secret is shown once in the creation response. This dialog creates no key and contains no credential.
3. Save current feature definitions
Save access, metered and credit configurations directly. Products pin internal evidence snapshots when published.
Define a metered entitlement
Products & Billing → Entitlements
Isolated fixture capture of current components; no persistence or live-service calls.
1
Define the entitlement, then pin its version
Save and activate the generations metered feature, then configure its allowance in a Product. Browser reads are for display; the trusted backend authorizes and meters actual work.
Check the resultFeatures are access, metered or credit. Current operations are save, archive and restore, without separate publication. This illustration shows configuration; Products still pin evidence snapshots.
4. Configure and publish Products
Memberships and topups use the current Product model. Grant or purchase through a Funnel.
Current products and immutable versions
Products & Billing → Plans
Isolated fixture capture of current components; no persistence or live-service calls.
1
Check pinned versions and actual holdings
The list uses scoped server search and 50-row cursor pages. Publication is not payment. Use readHoldings to check actual holdings.
Check the resultPublished Products pin entitlement versions. Grant or purchase through a Funnel; default free contracts require configured eligible group versions; automatic trials have separate policies.
5. Save current credit rates
Default rates affect future consumption. Explicit plan rates and frozen operations retain their prices; execute on the trusted backend.
Configure current credit rates
Products & Billing → Entitlements → credit
Isolated fixture capture of current components; no persistence or live-service calls.
1
Separate quotes from execution
quoteBalance provides a read-only estimate. The trusted backend uses mutateBalance for consume, reserve, confirm, release or refund and retains the original idempotency key.
Check the resultRates publish with an immutable entitlement version. There is no separate legacy Credit Pool. Consumption uses the atomic balance protocol.
6. Edit owned screens
Design each screen independently. Buttons emit outputs; server authentication and business nodes control execution.
Edit a Funnel-owned screen
Funnels → Screen design
Isolated fixture capture of current components; no persistence or live-service calls.
1
Publish the graph and verify a real run
Design each independent screen for desktop first. Check modal, sheet, fullscreen, inline and content locales. Start on the trusted backend, then present with a controller and showFunnelRun.
Check the resultScreens present content and emit outputs. Server graph nodes control authentication, offers and payment. Editor previews do not write customer data.
Connect and verify
Use the current candidate SDK matching this deployment. Verify your user on the backend and issue a customer token.
Use readHoldings and readLedger to reconcile actual access and balance. Publication or a preview does not grant access.
Start a published Funnel on the backend. Retain the original requestId and show it with a controller and showFunnelRun. Verify the received screen event.
Only verified payment facts and durable receipts establish fulfillment. Real Auth/RLS, Sandbox billing and native stores require separate evidence.