Saved Successfully.

webcore fusion

NDC API Management & Agent Readiness

Autonomous AI agents are about to start shopping and booking against your NDC APIs. fusion runs the front door of that channel - the API keys, partner plans and per-agency limits that decide who may call it and how hard - and answers the two questions behind that decision: does your NDC implementation hold together, and is this channel safe to point an agent at?

The Gateway The Two Lenses

A defect list and a distribution decision are not the same document

Offer & Order Integrity Assurance

Most test tooling produces one score. That is the wrong shape for this problem. An expired offer that silently reprices is a bug for the integration team. An offer that silently reprices when an autonomous agent accepts it is a commercial exposure. fusion reports both, separately, from the same run, so the engineering team gets a defect list and the distribution team gets an answer.

Coming soon

fusion is coming soon. The suite, the test case library, the order guards and the gateway's key management, partner registry, plans and routing are built; carrier execution, report signing and the gateway's rate, quota and look-to-book enforcement are in development. We are onboarding a small number of design partners who want to shape it, talk to us if that is you.

  • Offer integrity
  • Fare rules
  • Branded fares
  • Ancillaries
  • Order truthfulness
  • Agent pattern stress
  • Trust, scope & injection
  • Order state guards
  • CI gate
  • API key management
  • Partner registry & plans
  • Per-agency throttling
  • Look-to-book ceiling
  • Azure APIM cut-over
webcore fusion test case library listing agent pattern stress and offer integrity test cases with their isolated variable and severity

Carrier NDC API readiness

Does the implementation hold together?

The first lens is an engineering lens. Does a priced offer stay priced? Do fare rules and branded fare attributes survive the journey from shopping to order? Does an ancillary that cannot be fulfilled surface as a failure rather than a partial success?

Findings here are defects for the carrier's integration team, ranked critical, major or advisory, each tied to the single variable the test case isolated.

Agent readiness

Is this channel safe for an agent?

The second lens is a distribution lens. An autonomous agent retries, runs concurrently, fans out across permutations and will accept whatever it is told is true. That behaviour finds things a human tester never would.

Findings here are not a bug list. They are the input to a decision about whether to open the channel, and on what terms.

Inside the suite

Test cases as data, guards as functions, verdicts as evidence

Nothing in fusion is a compiled test method with an opinion buried in it. Test cases are data, each isolating exactly one variable. Guards are pure functions over order state. Every number in a report is a projection of run results, never hand-assembled. The gateway's registry is data too: plans, partners, keys and routes that every gateway node reads as one snapshot.

Offer integrity

Does the offer mean what it says?

Fare rules, branded fare attributes and ancillaries checked from shopping through to order, whether what was displayed is what gets sold.

Agent pattern stress

The way an agent actually behaves

Replayed idempotency keys, concurrent acceptance of one priced offer, shopping fan-out cost, throttling that returns an empty offer set instead of saying it throttled, and cached offers that no longer price.

Order truthfulness

Confirmed means confirmed

Whether a partly fulfillable order is reported as fully created, and whether a confirmation is backed by a real order rather than an optimistic response.

Trust, scope and injection

The channel's boundaries

Whether a handle stays bound to who presented it, and whether content coming back through the channel can influence an agent it should not be able to reach.

G1 & G2

Priced offer, not expired

Order creation accepts only a priced offer reference, never a search-stage handle. Acceptance after the price guarantee expires returns a typed error — never a silent reprice, under any code path.

G6 & G8

Truthful, and bound

An order is reported confirmed only against a response carrying a real order, and an offer handle stays bound to the party that was shown it.

G3, G4, G5, G7

Specified, in development

Reprice as a separate decision, human confirmation above a material change threshold, mandatory idempotency keys, and one flight per priced offer. Specified in full so the gap stays visible.

Never overstated

4 of 8 implemented

A guard that is not implemented is never reported as enforcing. The product tells you what it does not yet cover rather than letting you assume it does.

Watch it run

Live progress

A run streams its progress as it executes, so a long suite is not a black box until it finishes.

Compare and diff

Regression against a baseline

Compare a run against a previous one and see what changed. A regression is a diff, not an impression.

Two scores, one report

Readiness report

Carrier API readiness and agent readiness, each broken down by category, with failures listed most severe first and the evidence attached.

Gate the release

CI integration

Start a run from a build pipeline, poll it, and act on a single verdict and exit code — so agent readiness sits in the release process rather than in an annual audit.

Keys you can rotate

Shown once, hashed forever

Keys are issued from the admin panel and stored only as a SHA-256 hash and a displayable prefix - not in the audit trail, not in a log, not in the database. Each partner has a primary and a secondary slot, so rotation is issue, move, revoke: no outage, no shared spreadsheet. Keys imported from Azure APIM keep working unchanged.

Partners, agencies and plans

Who is calling, on what terms

A partner is an agency, an aggregator with many sub-agencies, or your own internal channel. Each is on a plan - rate, burst, daily and monthly quota, allowed NDC operations - with overrides at partner and agency level, and every effective limit records where it came from.

Throttle by agency, not just by key

The key names the partner; the message names the agency

The IATA number or AgencyID in the NDC message is mapped to the key's partner, so an aggregator's sub-agencies are controlled individually and an unmapped one is still bounded by the key. Rate, quota and a look-to-book ceiling that only ever touches AirShopping - never the booking - are the next drop.

Shadow, then enforce

Cut over from Azure APIM without an agency noticing

A new route starts in shadow: every decision computed and recorded, every request forwarded. Import your APIM subscriptions, run side by side until the registry is complete, enforce route by route, retire APIM when nothing depends on it. A refusal is an NDC-shaped Errors element with a GW- code, which every NDC client already parses.

Demand and funnel

Search to offer to order

Where demand arrives, where it converts and where it leaks — measured over the same search, offer and order data the harness already observes.

Partner hierarchy

Aggregator, sub-agent, agency

Traffic attributed down a real partner hierarchy rather than flattened, so an aggregator's behaviour and its sub-agents' behaviour are distinguishable.

Usage and compute

What the channel costs

Shopping fan-out is not free. Usage and compute reporting makes the cost of serving a partner visible next to what that partner books.

Carrier-scoped throughout

By construction

Every query is carrier-scoped and redaction happens before a record leaves the carrier estate. Raw NDC payloads never sit in database columns.

Order state machine guards

What a run found, and what would have been stopped

A run tells you what the carrier did. The guards tell you what fusion would have prevented. They are pure functions over order state with no transport types on the surface, which means they can be reasoned about, tested in isolation, and are not quietly coupled to whichever protocol an agent happens to arrive on.

Each guard carries its specification in the product, including the ones not yet implemented, so the gap between what is enforced and what is intended is always on the page.

webcore fusion order state machine guards G1 to G8 with their specifications and implementation status

The FUSION Gateway

Who may call your NDC API, on what limits, and where the calls go

fusion issues and validates the API keys agencies use to reach your NDC API, holds the partner registry and plans behind them, applies per-agency limits, and forwards each request to your own NDC services unchanged. It replaces the Azure API Management subscription-key store most carriers run in front of NDC today - and because the channel is then authenticated, everything else fusion reports is about a known agency rather than whatever a log column happened to carry.

Agencies & aggregators

Send the same subscription-key header they send to APIM today. Nothing changes on their side.

→
FUSION Gateway - run by you, inside your estate

Every request passes the same six steps. The key is stripped, your backend credential attached, the body streamed byte for byte. No SQL on the request path.

  • context
  • route
  • key
  • agency
  • admission
  • forward
→
Your NDC services

AirShopping, OfferPrice, OrderCreate and the rest receive exactly the bytes the agency sent.

Partners, agencies, keys, plans, overrides, routes and the audit trail are managed from the fusion control plane at Admin > Gateway. Every gateway node reads that registry as one in-memory snapshot and reloads only when it changes, so a database outage degrades freshness, never availability.

webcore fusion Admin > Gateway > Keys page: a partner's primary and secondary key slots, each key shown as a prefix with its issue date, expiry, last use and live status, a revoke control, and the issue-a-key form

Carrier-operated, by design

Webcore builds, ships and supports the gateway. You run it in front of your own services, on your availability terms. Webcore does not sit on your revenue path, and the gateway is optional: the assessment side of fusion works without it.

Fail-safe, not fail-open

A node that loses the database keeps serving on the last registry it loaded. A backend credential that does not resolve is a 503, never a request forwarded naked. Two nodes minimum, a readiness probe for the load balancer, and shadow mode as the incident switch.

Refusals an NDC client understands

A refused request gets an NDC Errors element with a GW- code, the owner FUSION, a correlation id and, for a throttle, a Retry-After. No bespoke error format for an aggregator to learn.

Gateway status

Key issuance and validation, the partner registry, plans and overrides, routes, forwarding, agency resolution from the NDC message, shadow mode and the admin pages are built. Rate and quota limits, the look-to-book evaluator, the decisions view and the APIM subscription importer are in development. Nothing here is reported as enforcing before it is.

webcore fusion runs screen showing test case execution progress for a carrier profile

Built to sit inside the carrier

Your data does not leave your estate

fusion is carrier-embedded by design. Every query is scoped to the carrier, redaction happens in process before any record leaves, credentials are vaulted rather than configured, and raw NDC payloads are stored outside the database with only a path and a content hash kept in SQL.

It is a standalone application, deployed independently, and the gateway is a second, separate deployable you choose to run: the control plane never references it, and neither bundles the booking tool or the certification tool. No harness, monitoring or gateway code goes anywhere near the products that run in airline production.

Works with

Part of the Webcore NDC toolchain

fusion is one of six Webcore products. These are the ones it sits next to.

webcore latitude

latitude proves your NDC integration works. fusion asks the harder question of whether the channel behind it is safe to open to an autonomous agent.

NDC Sandbox

webcore certifi

certifi certifies a named partner against a published programme. fusion assesses the channel itself, independently of who is calling it.

NDC Certification Tool

webcore nucleus

Findings become work. Readiness gaps can be tracked as a delivery backlog rather than a report nobody owns.

Project & Delivery Management

Shape it with us

fusion is coming soon. We are working with a small number of carriers who want agent readiness solved before the traffic arrives, not after - and who want API management built for an NDC channel rather than adapted to one.
Tell us what your distribution team is worried about.