Use annotated console walkthroughs to find each screen, configure it and check the result.
API v1Updated
1. Prepare your App’s configuration
Select Sandbox, configure origins and verify the customer identity.
Connect the current App and Sandbox
Integrations → SDK setup
Configuration illustration using example data; use the current Console for exact controls.
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
Configuration illustration using example data; use the current Console for exact controls.
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 current Feature configuration. Products use their own version rules; Offering and Paywall publication is independent.
Define a metered Feature
Products & Billing → Features
An earlier isolated editor illustration, with no persistence or live-service calls. Current Features take effect on save and have no published version.
1
Define the Feature, then configure product allowances
Current metered Features declare usage_type, filters and aggregate in config. Products reference the internal UUID; browser presentation does not replace backend authorization and metering.
Check the resultFeatures use a public id, type and config. Saving updates the current definition without publishing a version.
4. Configure Products
Configure actual Prices and Entitlements. Integrate grants or purchase independently, without first creating a Funnel.
Product catalog illustration (earlier UI)
Products & Billing → Plans
Configuration illustration using example data; use the current Console for exact controls.
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 resultUse the Product version returned after saving. Purchase independently through previewAttach/attach. Free defaults initialize by eligibility; paid trials require verified billing.
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
Configuration illustration using example data; use the current Console for exact controls.
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 resultFeature saves current configuration; use the Product terms returned after saving. Accepted usage retains its pricing facts; actual consumption uses atomic balance APIs.
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
Configuration illustration using example data; use the current Console for exact controls.
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 a compatible SDK. 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.
Confirm payment through the operation status, then refresh holdings. Check supported payment channels before enabling purchases.