Skip to main content
You can connect Pocketsflow to almost any external store, platform, or internal tool using two building blocks:
  1. The HTTP API — to create checkout sessions and read/write data.
  2. Webhooks — to react when something happens (a sale completes, a subscription renews, a refund is issued).
This section shows how to combine them into a working integration, with a complete WooCommerce example and a generic pattern you can adapt to any platform.

The building blocks

API keys

Authenticate server-to-server with a pk_live_… / pk_test_… key.

Checkout sessions

POST /checkout/sessions returns a hosted URL to redirect buyers to.

Webhooks

Subscribe to events like order.completed and customer.created.

Metadata

Attach your own IDs so you can correlate Pocketsflow orders with yours.

Example repositories

Clone a complete, runnable example — a checkout embed plus a signature-verifying webhook receiver — and adapt it to your platform.

Subscriptions example

Embed a subscription checkout and handle the subscription lifecycle webhooks.

One-time products example

Embed a product checkout and handle order.completed / order.refunded webhooks.

The standard pattern

Almost every “sell through my own store / platform” integration follows the same five steps:
1

Create an API key

In the dashboard, go to Developers → API keys and create a key. Store it as a secret on your server.
2

Map your products to Pocketsflow products

Each item you sell maps to a Pocketsflow productId. Create products in the dashboard or via POST /products, and store the resulting productId alongside your own product records.
3

Create a checkout session at purchase time

When a buyer checks out, call POST /checkout/sessions with the productId, your successUrl / cancelUrl, and a metadata object containing your order id. Redirect the buyer to the url you get back.
4

Let the buyer pay on Pocketsflow

Pocketsflow hosts the checkout and handles payment, tax, and receipts. After payment the buyer is redirected to your successUrl.
5

Confirm the sale with a webhook

Register a webhook for order.completed. When it fires, verify the signature, read your order id back out of metadata, and mark the order paid in your system.

Why metadata matters

The metadata you pass when creating a checkout session is echoed back on the resulting order and in every related webhook payload. This is how you correlate a Pocketsflow order with the order in your own system — without it, you’d have no reliable way to know which of your orders a webhook refers to.

Develop and test locally

Build against a pk_test_… key first so no real money moves, then promote to pk_live_…. To receive webhooks on your machine, expose your local server with a tunnel (ngrok, cloudflared) and register the public URL as a webhook endpoint. The full walkthrough — keys, first call, tunnel, signature verification, and a go-live checklist — is in Developer setup.
Building the integration with an AI editor? Start with the MCP setup guide so the agent can call the API as your account, and give it these docs as context — see Claude Code, Cursor, and Windsurf.

Common questions

Read your own id back out of metadata (for example metadata.external_order_id). It’s echoed on the order and every related webhook. Never rely on ordering or timing.
Treat webhooks as the source of truth, but reconcile as a backstop: list recent orders via the API and match on your metadata id. Keep handlers idempotent so a re-send is safe.
Yes — the custom platforms pattern (create a checkout session, redirect, confirm via webhook) works for any store, membership site, or no-code tool.

Pick a guide

WooCommerce

A complete, step-by-step WooCommerce integration with PHP examples.

Any other platform

The generic redirect + webhook pattern, with Node and PHP examples.

Developer setup

Keys, test mode, first API call, and local webhook testing.

MCP setup guide

Build and operate your store with an AI agent.