What Shipped on the Highnote API: July to October 2026

"One integration" is an easy API promise to make. Proving what happens when the platform changes is harder, because the evidence usually lives in release notes rather than product pages.

Our developer documentation presents the platform through a single GraphQL API, with one endpoint and one key across issuing, acquiring, and money movement, operating on a shared core ledger.

One API Means Subtracting, Not Just Adding

On 23 July we shipped a unified payment transaction API: authorize, charge, and reverse mutations that take credential inputs directly. On 11 August we deprecated the legacy payment mutations that it replaced, including the separate authorize, charge, network token, payment method token, and cancel operations, and published migration guidance alongside them. On 27 August, we moved the 3D Secure data exchange, authentication, and challenge mutations to the same credential object, and removed paymentMethodTokenId from their inputs.

Adding another endpoint is the easy direction. Consolidating five that customers already use is the harder one. It means writing migration guidance, supporting two paths during the transition, and absorbing the support load that follows.

That is the expensive version of a one-API claim, and it is the version worth looking for. A platform accumulating parallel ways to do the same thing is not converging on one API. It is describing one.

Three New Rails, No New Integrations

The modularity claim is testable, because new payment rails are exactly the case where a bolted-on architecture shows itself.

FedNow, 24 September. Originated and non-originated transfer support, with notifications, statuses, and reserve-related ledgers. On 12 October, FedNow transfer types were added to transaction search.

Non-originated wire transfers, 13 October. Simulation, types, and notification events, plus wire-related transaction search sources.

RTP and ACH, through September. Additional RTP and unified transfer failure reasons on 12 September, non-verified external US bank accounts accepted as an ACH source the same day, a non-originated RTP transfer simulation on 14 August, and an instant-funds option for transfers with its own ledgers on 28 September. External 3D Secure authentication input for transfers landed on 10 September.

Each arrived inside the existing transfer model, using the same underlying API structure rather than introducing a separate rail-specific integration. The changelog records them as transfer types and unified transfer behavior, added to the same transaction search and notification surfaces that were already there. For a developer already working with Highnote transfers, the change is an expansion of the existing model rather than a second payments stack.

That is what adding capabilities without adding integrations looks like in practice, and it is checkable against the dates.

What Else Shipped This Quarter

Four other areas moved substantially.

Acquiring. 3D Secure support arrived on 1 September, covering payment card credentials, authentication status, sessions, and tokens across both authorization and charge flows. Enhanced data for acquiring followed on 29 September, adding the Visa purchase ID format and line-item data to authorize, capture, and charge. Earlier, on 30 July, business creation and onboarding APIs shipped for ISO, merchant, and money movement onboarding, with inputs for reserves and processing capability; on 13 August, we extended them with contracts, financial reserves, and merchant identifiers on applications.

Flexible credentials. The capability first appears in the public changelog on 7 August, with provisioning, card reissuing, activity, and attempt events. Instant credit followed on 14 August with activation, strategies, and status events. Statements arrived on 20 August. In weeks, the public API surface expanded across provisioning, credit, activity, and statements.

Disputes. The card payment dispute lifecycle went in across late July and August: a disputes query with filters and pre-arbitration stages on 23 July, then the workflow itself on 24 July, covering issuer-initiated simulation, questionnaires, acceptance, finalization, and evidence upload and submission. Through August came sorting, response-due filtering, evidence types, previous-status fields, network recovered amounts, and partially-won outcomes. Notifications for provisional-credit-retained outcomes landed on 8 September.

Compliance and identity. Identity verification results, terminated-merchant screening, and business underwriting on product applications on 17 July. Jurisdiction and verification document inputs across US business and person profiles on 19 August. A compliance screening capability for payment instruments on 22 September. Card authentication contacts, with binding channels, addresses, scoping, and revocation, on 18 September.

Two smaller items worth naming. Mastercard enhanced travel data went in on 17 August, covering trip legs, rail, car rental, lodging, travel agency fees, and taxes, which extends the commercial card issuing work for online travel companies announced in April. A new partner bank was added in September. Product lines of business arrived on card products on 5 October.

Why GraphQL

A piece like this is worth very little if it cannot say where the architecture does not help.

Transaction execution and data retrieval have genuinely different shapes. Executing a payment needs predictable, idempotent, auditable calls, where the request is explicit, the contract is narrow, and the same call twice doesn't produce two charges. Retrieving data wants flexibility across related entities: a cardholder, their account, recent transactions, and current balances, assembled for a screen that may change next sprint.

Where GraphQL earns its place is the second shape. A single query returning a cardholder with their account, transactions, and balances replaces several round trips and the client-side assembly that goes with them. When the screen changes, the query changes, not the backend.

REST's constraints are a feature in the first place. Explicit endpoints are easier to reason about under load, easier to instrument, and easier to audit after the fact. The narrowness that looks like a limitation when you are building a dashboard is a guardrail when you are moving money.

A company could reasonably weigh those differently and build on REST. Plenty have, for defensible reasons. What a GraphQL-first platform owes its developers is not a claim that the choice is universally correct, but a clear account of where it pays and where it costs.

For us, the payoff is the shared data model underneath. Accounts, cards, balances, and ledger events resolve through the same graph, which is why a new transfer type can arrive without a new integration. That is the same property this article has spent three sections documenting.

What to Ask Any Platform About Its API

Including us.

• Is there one endpoint and one key, or one per product? The answer tells you what your integration looks like in two years.
• What happens to your code when the provider adds a capability? New field, new mutation, or new integration are three very different answers.
• Is there a public, dated changelog? A public, dated changelog is itself evidence of how a platform evolves and how clearly customers can see those changes.
• Does the sandbox behave like production? Including failure cases, simulated declines, and dispute flows, not only the happy path.
• When something is deprecated, what is the migration path? Deprecation without guidance is a cost transferred to you.

The third question is the quiet one. Everything else on this list is easier to verify once the answer is yes.

The Next One

The changelog that produced it is public, it is dated, and it keeps running.

Check it out at docs.highnote.com/changelog, or start with the developer documentation if you want the shape of the platform before the detail.

Talk with our team about building on it.

FAQs

Does Highnote Use REST or GraphQL?

Highnote's developer documentation presents the platform through a single GraphQL API, with one endpoint and one key across issuing, acquiring, and money movement. Accounts, cards, balances, and ledger events share one data model, allowing new capabilities to be added to the existing graph.

Where Can I See What Changed in the Highnote API?

The API changelog is published at docs.highnote.com/changelog. It lists each change with its date and covers new mutations, deprecations, field additions, notification events, and response codes.