Changelog
Release notes for the Tokeflow REST API and Bridge SDK — new features, changes, fixes, and any breaking changes, in reverse-chronological order.
This is the running record of changes to the Tokeflow platform — the REST API and the Bridge SDK. Entries are listed newest first, each one dated and grouped by Added, Changed, and Fixed.
Tokeflow is the orchestration layer behind your platform: the API and SDK shapes documented in this reference are stable, and we evolve them carefully. Most releases are additive — new fields, new enum values, new endpoints — and these can appear within the current major version (v1) at any time. Build clients that ignore unknown fields so additive changes never break you.
Breaking changes are always called out explicitly with a Breaking label and ship under a new API version prefix (for example /api/v2). They are never introduced silently into an existing version. Subscribe to release notes before you depend on any behavior not documented in this reference.
New to Tokeflow? Start with the Quickstart for an end-to-end payment, then read the API reference overview for the wire format and conventions.
How to read this changelog
| Label | Meaning |
|---|---|
| Added | New endpoints, resources, fields, enum values, or SDK capabilities. Backward compatible. |
| Changed | Behavior or defaults that changed in a backward-compatible way. |
| Fixed | Corrections to bugs or inconsistencies. |
| Breaking | A change that requires action. Only ever ships under a new version prefix. |
Each entry notes whether it affects the API, the SDK, or both.
2026-09-04 — Subscription reactivation and billing clarity
New subscription controls and clearer billing behavior across the REST API and the Dashboard. All changes are backward compatible.
Added
REST API v1 (API) and Dashboard
- Reactivate a subscription — a new endpoint that calls off a scheduled cancellation and keeps a live subscription on its plan, on both the public API and the merchant Dashboard. It is also the remedy when a customer tries to start a plan they already hold.
- Actor attribution on subscription transitions: admin-triggered changes now carry an
actorsnapshot of the dashboard user who performed them. - Documented billing holds and the one live subscription per plan rule in the Subscriptions lifecycle.
Changed
- Change offer (API): after a plan change,
billing_cyclenow re-syncs to the new offer's cycle instead of keeping the previous value. - Refunds (API): clarified that
pendingrefunds count against the refundable balance, and that a refund with no definitive provider result stays in doubt — the transaction remainsrefund_pending— rather than being released. - Webhooks (API): documented the full retry window — an endpoint that fails every attempt is retried across roughly 26 hours before the delivery is abandoned — and that each delivery is timestamped when it settles.
2026-08-13 — Expanded API reference
A broad documentation update covering more of the /api/v1 surface, plus a new Dashboards section for the session-authenticated Dashboard and Customer Portal endpoints. No behavior changed — this release documents endpoints that were already live.
Added
REST API v1 (API)
- Merchants (
mrc_) — manage merchants and their team members within an organization. - API Keys (
ak_) — create, list, inspect scopes for, and revoke API keys programmatically. - Webhook Endpoints — register endpoints, inspect deliveries, and rotate signing secrets over the API.
- Sessions & Tokens (
tok_) — the server-side session and tokenization endpoints behind the Bridge SDK. - Connectors (
conn_) and Routing Profiles — connect payment providers and define smart-routing rules and fallback order. - Payment Providers, Audit Logs, and Health.
- New endpoints on existing resources: delete a customer, create a payment instrument, and administratively cancel a subscription.
Dashboards (API)
- Documented the session-authenticated Merchant Dashboard, Organization Dashboard, and Customer Portal endpoints — the surfaces behind the Tokeflow Dashboard and the self-service customer portal. These authenticate with a Dashboard session (JWT bearer) or a portal magic-link session, not with
sk_/pk_API keys.
Changed
- The API reference overview resource-group list now includes the newly documented resources.
These pages are published in English first; the pt-BR and es translations follow. Until then, those locales show the English version of the new pages.
2026-06-23 — Public API v1 & Bridge SDK
The first public release of the Tokeflow platform: a stable, versioned REST API and a client-side SDK for collecting payment data in the browser. Everything in this reference is generally available as of this release.
Added
REST API v1 (API)
The full /api/v1 surface is live at https://api.tokeflow.com. One consistent envelope, one set of conventions, across every payment provider you connect.
- Customers (
cust_) — create and manage payers, including documents (cpf,cnpj,passport,tax_id) and contact details. - Checkout Sessions (
cks_) — hosted and embedded checkout flows with line items, customer identification, and a streamed event timeline. - Transactions (
tx_) — create, retrieve, capture, and void payments acrosscredit_card,debit_card,pix,boleto, andwalletmethods. - Refunds (
ref_) — full or partial refunds against captured transactions. - Orders (
ord_) — order records that group transactions across API, checkout, and renewal flows. - Subscriptions (
sub_) — recurring billing with lifecycle, dunning, pause/resume, and offer changes. - Payment Instruments (
pi_) — saved payment methods on file for merchant-initiated and repeat charges. - Catalog — product families (
pfa_), products (prd_), offers (ofr_), offer prices (opr_), and offer transitions (oft_).
Authentication & key scoping (API)
- Organization and Merchant API keys. Every key is scoped to exactly one entity. A Merchant key infers its merchant automatically; an Organization key spans every merchant in the org and targets one with the
merchant_idparameter. See Authentication. - Secret and public keys. Secret keys (
sk_…) authorize server-to-server calls; public keys (pk_…) are restricted to client-safe scopes and are safe to ship in browser code. Permissions follow aresource:actionmodel. See Environments and keys.
Platform conventions (API)
- Idempotency. Send an
Idempotency-Keyheader (oridempotency_keybody field) on create and charge mutations — notablyPOST /transactions— and replays return the original result instead of duplicating. See Idempotency and rate limits. - Webhooks with signed delivery. Normalized, provider-agnostic event notifications, each signed with an
X-Tokeflow-Signatureheader (HMAC-SHA256) so you can verify authenticity before acting. See Webhooks. - Standard envelopes, errors, and pagination. A consistent
success/data/metaenvelope, a stable machine-readable error catalog, and page-based pagination across every list endpoint. See the API reference overview.
Bridge SDK (SDK)
The @tokeflow_com/bridge-js Bridge SDK collects sensitive payment data in the browser and exchanges it for a short-lived token reference (tok_…) — card data is encrypted in the browser and never touches your servers. See the Bridge SDK overview.
- Card collection with prebuilt, themeable secure elements. See Elements and Tokenization.
- PIX, Apple Pay, and Google Pay — every enabled method produces the same kind of token reference. See Payment methods.
- Checkout context — read the priced items, selected currency, enabled methods, and saved instruments from an open checkout session. See Checkout.
- Localization — built-in
enandpt-BRpacks with per-element string overrides. See Localization. - React bindings — first-class provider, hooks, and element components. See React.
- Public-key auth — the SDK authenticates with a publishable key only; secret keys stay on your server.
Release at a glance
This is the inaugural entry. Future releases — new endpoints, fields, enum values, and SDK capabilities — will be appended above this one as they ship.
Next steps
- Quickstart — an end-to-end payment.
- API reference overview — base URL, auth, envelopes, and conventions.
- Bridge SDK overview — collect and tokenize payment data in the browser.
- Webhooks — receive and verify signed events.