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-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