Builder resource

The API-First Product

Add Plandalf Offers to a React app, keep Stripe as the processor, and send purchase events into Postmark, Customer.io, and the rest of your operating stack.

Use this as the builder map for an API-first implementation: when to create products, how prices attach to an offer, where checkout belongs, and which webhooks should drive access, receipts, and lifecycle work.

The goal is not another vague integration page. This is a practical guide for using Offers, Automations, invoices, payment options, and integrations together inside a real product flow.

Built for: Dev tool startups, API products, B2B SaaS with a console

This page is the builder map: patterns, responsibilities, recipes, and product decisions for adding Plandalf to an API-first product. Exact method signatures belong in the SDK checkout docs, API reference, and webhook docs.

The Numi API Keys settings page used to create organization API keys. — Create and manage organization API keys in the Numi app before making protected API requests.

The Numi Developer API documentation with sidebar navigation and SDK method reference. — The dedicated docs surface owns exact SDK method reference. This stack page stays focused on what to build and where each responsibility lives.

Architecture

Treat Plandalf Offers as the commerce layer between your product and the payment processor. Your application owns the product experience. Plandalf owns offer configuration, checkout state, pricing rules, buyer identity, invoices, and the events that drive fulfilment.

Site React Buyer clicks the CTA on your page. Checkout Plandalf Buyer opens the embedded checkout/modal. Payment Stripe Buyer submits payment in Plandalf. Email Postmark The same Plandalf purchase event fires. Automation Customer.io The same Plandalf purchase event fires.

Stage System Handoff

Site React Plandalf opens from that page with the selected offer context.

Checkout Plandalf Plandalf validates the offer, applies pricing logic, and emits checkout events.

Payment Stripe Plandalf sends the payment request to Stripe, then records the completed purchase event.

Email Postmark Plandalf Automation sends the event and customer fields to Postmark.

Automation Customer.io Plandalf Automation sends the event payload to Customer.io.

How This Stack Makes The Sale Work

The API-First Product is useful when each tool has a clear job: the audience surface creates intent, Plandalf turns that intent into a configured offer, Stripe collects payment, and the follow-up tools receive the purchase context they need.

Where the buyer starts

React owns the attention layer. Keep the editorial page, newsletter block, landing page, or product screen focused on why the buyer should act, then hand the buying decision to Plandalf Offers.

React Offers Buy button

What the buyer is purchasing

Plandalf should own the offer, products, prices, checkout mode, coupons, order bumps, upsells, invoice settings, and confirmation behavior so Stripe is not the only durable record.

Products Prices Coupons Invoices Stripe

What happens after payment

The purchase event should drive fulfilment, receipts, lifecycle email, CRM updates, tax context, and reporting. Customer.io, Postmark should receive commerce context instead of a bare form submission.

Automations Sequences Customer.io Postmark

Choose The Pattern

Start by deciding which business moment you are building. The technical implementation changes depending on whether checkout starts inside the product UI, from a public marketing page, or from your own catalog system.

Launch an in-app upgrade flow

Use when: Your product already has an authenticated app and needs a buyer to upgrade without leaving the product.

Build: Create an offer, mount the buying surface beside the upgrade CTA, identify the buyer, and grant access only after the purchase event.

Offers Feature gates React app integration SDK checkout

Sell from a marketing page

Use when: Your app has a public sales page and checkout should open from the pricing, template, or product page.

Build: Use the offer as the commercial source of truth, keep the page copy in your site, and let Plandalf handle checkout state, payment handoff, invoices, and follow-up.

Hosted checkout Checkout templates Coupons Invoices

Sync your own catalog

Use when: Your product system already creates plans, SKUs, packages, or entitlements.

Build: Push stable product and price records into Plandalf, map them to offers, then use purchase events to reconcile access in your app.

Products Prices Offer products docs Webhooks

Build The Offer Layer

The offer is the commercial object your product points at. It should describe what the buyer can purchase, how checkout appears, which price rules apply, what invoice gets recorded, and what automation happens after purchase.

Use a stable offer for each plan, product, template, package, or upgrade path.
Attach products and prices before you wire the buying moment into the app.
Set invoice, automation, coupon, bump, upsell, and confirmation behavior where the seller can inspect it.

The Numi offer editor with layout, product, theme, automation, invoice, and settings controls. — The offer editor is where the checkout surface, products, automation, invoices, and display mode come together.

Configure The Controls Sellers Will Touch

An API-first build should not hide commercial controls in code. Sellers still need a place to adjust automation, checkout templates, order bumps, upsells, coupons, and the blocks that appear inside the offer before developers wire the SDK into the app.

The Numi offer editor automation tab showing sequence controls beside the checkout canvas. — Automation is configured beside the offer, so purchase-triggered workflows stay attached to the buying surface. Link sequences, webhooks, and post-purchase automations from the same product surface.

The Numi checkout element palette showing content, interactive, and selling blocks. — Checkout templates expose reusable blocks for product lists, product cards, add-ons, buttons, forms, and offer content.

The Numi selling blocks panel showing order bump controls. — Order bumps are configured as selling blocks rather than one-off front-end code.

The Numi selling blocks panel showing upsell controls. — Upsells can be planned as part of the offer instead of bolted on after checkout.

The Numi coupon discount settings panel. — Coupons keep discount behavior inspectable for sellers and reusable across checkout flows.

Wire The Buying Moment

Your product should decide when the buyer is ready. Plandalf should decide what the checkout means. Keep the product UI focused on the buying moment, then let the offer carry the checkout mode, product, price, invoice, and automation context.

Inside the appUse for upgrades, seat expansion, feature gates, templates, credits, or API plan changes.

On a public pageUse for pricing pages, product pages, launch pages, and template galleries.

From backend stateUse when your system already knows the product, customer, entitlement, or account context.

Plan The Data Contract

The useful part of an API-first integration is not the button. It is the agreement between your app, Plandalf, the payment processor, and follow-up tools about which object owns each piece of commerce state.

Object Primary owner How Plandalf uses it

Customer Your app Receives identity and buyer fields so checkout and follow-up stay attached to the right person.

Offer Plandalf Packages products, prices, checkout mode, invoices, coupons, bumps, upsells, and confirmation state.

Product and price Shared Use stable keys so app entitlements, invoices, and automation events point at the same commercial object.

Payment Stripe Plandalf keeps checkout and invoice context while the processor handles the charge.

Purchase event Plandalf Starts fulfilment, CRM updates, lifecycle sequences, receipts, and internal notifications.

Actual Product Surfaces

These are the app surfaces a builder should expect to touch before the SDK install: products and prices, integrations, and invoices. The screenshots are from the product, so this section can explain where implementation decisions live instead of showing abstract mockups.

The Numi products page showing a product, price, and Stripe connection status. — Products and prices are visible app records, not hidden implementation details. Start with Products, Prices, and the Stripe connection.

The Numi integrations page showing Stripe, PayPal, Stripe test mode, and TaxJar connection options. — Payment and tax integrations stay inspectable in the app before the SDK is wired into production. Keep Stripe, PayPal, TaxJar, and Avalara visible to operators.

The Numi offer invoices page showing invoice status, customer, amount, and line item information. — Invoices preserve the commercial record after checkout, including line items and status. Tie checkout back to custom invoices, PDF invoices, and invoice email.

Payment Configuration

API-first checkout still needs visible operator controls. Before a developer reaches for SDK checkout methods, the seller should be able to confirm the payment processors, payment options, tax integrations, and sandbox routing that the offer will use.

The Numi integrations settings page showing Stripe, PayPal, Stripe test mode, TaxJar, and Avalara connection options. — Payment processors and tax services are configured in the app before checkout traffic reaches production. Link Stripe, PayPal, TaxJar, and Avalara from the integrations surface.

The Numi Stripe payment methods settings page showing card, wallet, bank transfer, and buy now pay later options. — Stripe payment methods let sellers choose which cards, wallets, bank transfers, and pay-later options appear in checkout. This belongs with payment options, hosted checkout, and Stripe docs.

Compare The Pattern

An API-first build is different from using a processor-only checkout or a standalone funnel tool. Use these pages when a builder is deciding whether Plandalf Offers should sit inside the product stack or whether a narrower checkout product is enough.

Plandalf vs Stripe Checkout

Compare with Stripe Checkout. Use this when you need Stripe payments plus offer configuration, invoices, post-purchase automation, and seller-operated checkout changes.

Stripe integration Payment options Hosted checkout

Plandalf vs Gumroad

Compare with Gumroad. Use this when your product already has its own app, catalog, customer identity, and fulfilment path instead of needing a marketplace-style checkout product.

Products SDK checkout Webhooks

Plandalf vs SamCart

Compare with SamCart. Use this when checkout needs offer automation, product context, invoices, and post-purchase workflows rather than a separate funnel tool beside the business.

Order bumps Upsells Automations

Plandalf vs Shopify

Compare with Shopify. Use this when the business is selling software, access, templates, subscriptions, or services and does not need a full storefront catalog.

Checkout templates Invoices Integrations

ThriveCart comparison ThriveCart alternatives ClickFunnels comparison ClickFunnels alternatives Kajabi comparison Kajabi alternatives PayPal comparison PayPal alternatives Zapier comparison Zapier alternatives

Implementation Recipes

Use these recipes the way a developer would use product-specific SDK docs: choose the job, confirm the product surface, then move into API reference, SDK checkout, webhooks, events, and integration docs only when the implementation shape is clear.

Mount checkout inside a React upgrade CTA

Use when: Use this when the buyer is already signed in and the upgrade should happen inside your product rather than on a separate pricing page.

Create the offer with products, prices, checkout templates, coupons, order bumps, and upsells already configured.
Install the SDK in the React app and pass buyer identity before opening checkout.
Open the hosted checkout or embedded checkout surface only after the buyer clicks the upgrade CTA.
Listen for the purchase event or webhook before granting access to the account, workspace, or feature gate.

React integration SDK install SDK checkout Identify customers Feature gates

Publish a product-backed offer from your catalog

Use when: Use this when your app already has plans, packages, credits, templates, seats, or subscriptions and Plandalf should own the buying surface.

Map your catalog object to Plandalf products and stable prices before launch.
Attach the products and prices to an offer instead of improvising a one-off payment link.
Preview the checkout template, payment options, coupons, order bumps, and upsells before sending production traffic.
Use the API reference and SDK docs only for implementation details after the commercial object is clear.

Products Prices Offer products docs Pricing docs API reference

Fan purchase events into fulfilment tools

Use when: Use this when the same completed checkout needs to update access, send a receipt, notify a team, and start lifecycle messages.

Treat the purchase event as the source of truth, not the front-end success screen.
Send invoice and receipt work to the transactional email integration while lifecycle messaging goes to Customer.io or another CRM/email tool.
Route the webhook payload to your custom API for entitlement, analytics, reporting, or fulfilment.
Keep invoices, line items, payment state, customer identity, and coupon context attached to the event.

Webhooks SDK events Postmark Customer.io Purchase event fanout

Verify payment, tax, and invoice records before launch

Use when: Use this when the checkout is technically wired but the business record still needs to survive refunds, support tickets, and reporting.

Confirm Stripe, PayPal, Stripe test mode, TaxJar, and Avalara are connected or deliberately left off.
Choose the payment methods that should appear in checkout, including cards, wallets, bank transfers, and pay-later options.
Run the hosted checkout flow with test payment settings and verify invoice records are created with the expected line items.
Check that payment state, tax context, invoice email, PDF invoices, and customer fields are available after purchase.

Stripe PayPal Payment options Tax Invoices

Linked Implementation Map

Use this map when The API-First Product turns from an idea into implementation work. Every linked feature, integration, docs page, workflow, comparison, template, and tool is a next step a builder or agent can follow from this stack.

Product surfaces

Configure these Plandalf features before sending buyers into the stack.

API Developer/API SDK Developer/API Integrations Automation Automation Automation Purchase automations Automation Sequences with multiple similar triggers and any set of actions Automation Notifications Notifications Analytics Analytics Metadata Data Customer identify Data Form data Data Stripe integration Payments Payment options Payments Buy button Checkout Modality Developer/API Totally custom checkout layouts Checkout Custom styles and themes Checkout Preview sessions Sessions Test sessions Sessions

Integrations

The tools that own the audience, payment, delivery, tax, CRM, or follow-up path.

React Stripe The complete payments platform for the internet. Postmark Customer.io

Docs handoff

Move from stack planning into exact setup, SDK, API, and webhook reference pages.

Offers overview Understand Plandalf Offers: hosted checkout pages, embedded checkout flows, products, prices, add-ons, order bumps, upsells, save offers, and purchase context. Products Attach products and prices to offers so checkout sessions, invoices, and integrations carry clean catalog context. Pricing models Model one-time prices, subscriptions, tiered pricing, volume pricing, trials, discounts, and promo-driven price changes. Hosted checkout Plandalf's hosted checkout — managed URL, theme-able down to fonts and layout, with test and preview sessions. Save offers Present a discount, plan switch, pause, or deadline-bound offer when a subscriber starts a cancellation path. Stripe Connect Stripe as the payment account behind Plandalf offers, then test checkout, products, prices, and payout behavior before going live. Developer API reference Reference the main SDK methods, HTML attributes, FlowHandle events, and protected API authentication model. Webhooks Start Plandalf automations from generated catch URLs or send outbound HTTP requests from automation actions. SDK checkout API Understand the public checkout endpoints the Plandalf SDK calls for offer loading, session creation, session lookup, mutations, and discounts. Install the SDK Load the Plandalf browser SDK on any site, app, page builder, or framework route. React SDK Use PlandalfProvider and React hooks to present offers, identify customers, check gates, and render checkout experiences. Live events Use FlowHandle events and DOM events to observe checkout starts, purchases, completions, and cancellations. Identify customers Attach Plandalf checkout sessions to logged-in users with email identity or signed JWT identity. Configure the SDK Configure frame style, test mode, size, promos, identity, session continuity, metadata, properties, and close behavior.

Recipes and sequences

Use these when the sale needs fulfilment, lifecycle, webhook, or automation depth.

Purchase event webhook fanout Fan a single purchase event out to custom APIs, SDK-built apps, email systems, analytics, and fulfillment services. Checkout started to abandonment recovery Recover a checkout that opened but did not complete by sending the buyer and offer context to the email or automation tool. Sell a Webflow product with Stripe Checkout Wire a Plandalf hosted checkout into a Webflow site, accept Stripe payments, and fulfill on completion.

Comparisons

Decision pages for buyers choosing between Plandalf and narrower checkout, funnel, storefront, or automation tools.

Plandalf vs Stripe Checkout Use this when you need Stripe payments plus offer configuration, invoices, post-purchase automation, and seller-operated checkout changes. Plandalf vs Gumroad Use this when your product already has its own app, catalog, customer identity, and fulfilment path instead of needing a marketplace-style checkout product. Plandalf vs SamCart Use this when checkout needs offer automation, product context, invoices, and post-purchase workflows rather than a separate funnel tool beside the business. Plandalf vs Shopify Use this when the business is selling software, access, templates, subscriptions, or services and does not need a full storefront catalog. ThriveCart comparison Compare Plandalf with ThriveCart when this stack overlaps with a processor, funnel, storefront, course, or automation tool. ThriveCart alternatives Use the ThriveCart alternatives page when the buyer is evaluating replacement options. ClickFunnels comparison Compare Plandalf with ClickFunnels when this stack overlaps with a processor, funnel, storefront, course, or automation tool. ClickFunnels alternatives Use the ClickFunnels alternatives page when the buyer is evaluating replacement options. Kajabi comparison Compare Plandalf with Kajabi when this stack overlaps with a processor, funnel, storefront, course, or automation tool. Kajabi alternatives Use the Kajabi alternatives page when the buyer is evaluating replacement options. PayPal comparison Compare Plandalf with PayPal when this stack overlaps with a processor, funnel, storefront, course, or automation tool. PayPal alternatives Use the PayPal alternatives page when the buyer is evaluating replacement options. Zapier comparison Compare Plandalf with Zapier when this stack overlaps with a processor, funnel, storefront, course, or automation tool. Zapier alternatives Use the Zapier alternatives page when the buyer is evaluating replacement options.

Templates and tools

Adjacent pages that help turn the stack into an implementation plan.

Webflow + Stripe Checkout A ready-to-clone Plandalf checkout template designed for Webflow sites paying via Stripe. Writers & creators Drop a buy button inside the post. Sell the upgrade in the same scroll. Stripe fee calculator See exactly what Stripe takes from every transaction — and what your customer needs to pay for you to net what you want.

Operational Recipes

These are the practical recipes a builder usually needs after the checkout opens. They are intentionally product-level: the SDK docs can own function names, while this page explains the workflow you are trying to implement.

Grant access after purchase

Trigger: Checkout completed

Action: Mark the workspace, account, seat, course, template, or API plan as active in your product database.

Webhooks SDK events Feature gates

Send transactional receipts separately from lifecycle email

Trigger: Invoice or purchase recorded

Action: Postmark handles receipts, while lifecycle tools handle onboarding and expansion.

Invoices Emailing invoices Postmark Customer.io

The Numi sequences screen showing automated workflow configuration. — Sequences turn the purchase event into onboarding, fulfilment, alerts, and lifecycle follow-up.

Start a customer lifecycle sequence

Trigger: Purchase event carries product, price, offer, buyer, and coupon context

Action: Send onboarding, activation, renewal, save-offer, or expansion messages without treating the checkout as a generic form submit.

Sequences Automations Coupons Postmark

The Numi offer invoices records view showing customer invoice rows and payment status. — Invoice records preserve the buyer, line item, payment state, and support context after purchase.

Keep support and finance records useful

Trigger: Invoice created or payment state changes

Action: Store invoice identifiers, line items, tax context, and customer fields so refunds, support questions, and reporting have a durable record.

Custom invoices PDF invoices TaxJar Avalara

Hand Off To SDK Docs

This stack resource should not become the SDK reference. The SDK docs should own method signatures, auth headers, payload examples, error states, and versioned install instructions. Link to them when a builder is ready to implement.

Future docs handoff Use this page to choose the integration shape. Use the React SDK docs for browser methods, protected API routes, webhooks, and copy-paste examples.

Builder Checklist

Before shipping the integration, verify these decisions. If one is unclear, the checkout may open, but the business workflow after purchase will still be brittle.

01Offer selectedEvery buying moment points to a clear offer, not an improvised payment link.

02Identity mappedYour product can reconcile the buyer, customer, workspace, account, or entitlement after purchase.

03Event path chosenFulfilment starts from a purchase event or sequence, not from a front-end success screen alone.

04Records preservedInvoices, line items, payment state, and customer fields are available for support and reporting.