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

LabelMeaning
AddedNew endpoints, resources, fields, enum values, or SDK capabilities. Backward compatible.
ChangedBehavior or defaults that changed in a backward-compatible way.
FixedCorrections to bugs or inconsistencies.
BreakingA 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 actor snapshot 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_cycle now re-syncs to the new offer's cycle instead of keeping the previous value.
  • Refunds (API): clarified that pending refunds count against the refundable balance, and that a refund with no definitive provider result stays in doubt — the transaction remains refund_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)

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

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 across credit_card, debit_card, pix, boleto, and wallet methods.
  • 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_id parameter. 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 a resource:action model. See Environments and keys.

Platform conventions (API)

  • Idempotency. Send an Idempotency-Key header (or idempotency_key body field) on create and charge mutations — notably POST /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-Signature header (HMAC-SHA256) so you can verify authenticity before acting. See Webhooks.
  • Standard envelopes, errors, and pagination. A consistent success/data/meta envelope, 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 en and pt-BR packs 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

On this page