> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.
# API Connectors
> Point an integration you have already built at Fluz — without rewriting it.
If you already send gift card orders to Tango, Runa, or InComm, you do not have to rebuild anything to buy from Fluz. Change your base URL, change your credential, and keep the code you already wrote.
That is what an **API adapter** does.
## What an API adapter is
We mapped our API calls onto theirs. Every operation your vendor exposes — create an order, check an order, read a balance — has a Fluz operation behind it, and the adapter sits in between doing the translation in both directions.
The result is that the integration you already built against Tango, Runa, or InComm now buys from Fluz instead. You keep your request shapes, and a successful response comes back in the shape your parser already expects.
Two things are Fluz's rather than your vendor's: error responses and order status values. Both are covered in [Connector behaviour](/connector-behaviour).
Think of a travel plug adapter. The appliance does not change. The wall socket does not change. Something in between makes the two fit.
## How the mapping works
Your request arrives shaped like the vendor's. The adapter translates the route and the fields into the equivalent Fluz operation, executes it against Fluz supply, then translates the result back into the response shape your code already expects.
### Operation mapping
Each connector page publishes the full table for its vendor. Tango Card, as an example:
| Operation | Your existing call | Fluz endpoint |
| :------------------------ | :--------------------------------- | :--------------------------------- |
| Create order | `POST /v2/orders/` | `POST /v2/orders/` |
| Get order | `GET /v2/orders/:referenceOrderID` | `GET /v2/orders/:referenceOrderID` |
| Get all orders | `GET /v2/orders` | `GET /v2/orders` |
| Get balance, all accounts | `GET /v2/accounts` | `GET /v2/accounts` |
| Get balance, one account | `GET /v2/accounts/:accountId` | `GET /v2/accounts/:id` |
Paths and verbs are preserved deliberately. The point of the adapter is that your routing layer does not have to know anything changed.
### Field mapping
Tango Card again, as an example:
| Field in your request | What Fluz does with it |
| :-------------------- | :----------------------------------------------------------------------------------------------------------------------------- |
| `utid` / brand code | **Resolved against the Fluz catalog. See the warning below** |
| `amount` | Purchase amount |
| `externalRefID` | Accepted. Correlate the order using `referenceOrderID` from the response |
| `accountIdentifier` | Orders are funded from the account your API key is issued for. Request one key per account if you split funding across several |
| `customerIdentifier` | Kept for compatibility with your existing request shape |
**Tango and InComm return complete results synchronously.** The call does not return until the purchase has finished, which can take up to 150 seconds, so set your client's read timeout above that. Runa is asynchronous by default: it returns a reference ID immediately and you read the order once it completes. Send `X-Execution-Mode: sync` to wait for the full result instead. Both are covered in [Connector behaviour](/connector-behaviour).
### Per-vendor request constraints
Your vendor's request shape is accepted as it stands, but a few values are fixed. Email delivery to the recipient must be off, orders are single-recipient and single-product, and Runa orders must be funded from the account balance in USD. A request that breaks one of these is rejected.
The full list is on [Connector behaviour](/connector-behaviour). Read it alongside your connector page's request examples before you cut over.
## What changes, and what does not
| | Before | After |
| :--------------------------------------------------- | :--------------- | :------------------------------------ |
| Request shapes | Vendor's schema | **Unchanged** |
| Successful response shapes | Vendor's schema | **Unchanged** |
| Base URL | Vendor's host | Fluz adapter host |
| Credential | Vendor's key | Your Fluz API key |
| Order status values | Vendor's | **Fluz's. Update your status checks** |
| Error responses | Vendor's schema | **Fluz's envelope** |
| Brand identifiers (`utid`, brand slug, product code) | Vendor's catalog | **Fluz's catalog — must be remapped** |
| Rates and discounts | Vendor's | Fluz's |
| Supplier of record, invoicing, reconciliation | Vendor | Fluz |
**Brand identifiers are the one thing you must change.** The adapter does not translate the vendor's product catalog into Fluz's. A Tango `utid` of `U561593` is not the same card as a Fluz `utid` of `1800FL-US`. Map your brand list against the Fluz catalog before you cut over, or your orders will succeed and deliver the wrong card.
## Switching in three steps
Point your existing client at the Fluz adapter host for your vendor. For Tango Card that is `https://api-adapter.staging.fluzapp.com/tangocard` in staging and `https://api-adapter.fluzapp.com/tangocard` in production, instead of `https://integration-api.tangocard.com/rass`. Both hosts are listed on every connector page.
Every connector uses HTTP Basic authentication with your Fluz API key: `Authorization: Basic `. Drop the vendor's username and password.
Swap your vendor product codes for their Fluz equivalents. Everything else — paths, verbs, request bodies, response parsing — stays as it is.
## Available connectors
**Documented and available.** Tango Card, Runa, InComm — each with a published endpoint comparison and request examples.
**Beta.** Stripe, Worldpay, TSYS, Checkout, Braintree, TabaPay, Finix, Authorize.net, Sola / Cardknox. Contact sales for early access and endpoint details.
**Beta.** Venmo and PayPal. Contact sales for early access and endpoint details.
Gift card connectors are the mature family and the only one with published operation-level documentation today. Each gift card connector page lists the exact operations that are implemented, alongside the original vendor endpoint they correspond to.
## Coverage is per-operation
**The adapter implements the operations listed on each connector page, and only those.** Each one is a purpose-built translation for that operation rather than a blanket pass-through.
If an operation does not appear in the endpoint comparison table on a connector page, it has not been built yet.
Before you begin, list every vendor endpoint your integration calls today and check each one against the connector page. If something you depend on is missing, tell your Fluz contact before you start — most gaps are small additions, but they need to be scoped.
## Connectors are separate from the Fluz GraphQL API
This trips people up, so it is worth stating plainly. Fluz has two distinct developer surfaces, and they do not share credentials.
| | API Connectors | Fluz API |
| :---------------- | :--------------------------------------- | :---------------------------------------------------- |
| Protocol | REST, shaped like the vendor | GraphQL |
| Authentication | Basic, with a Fluz API key | Bearer, with a User Access Token |
| Credential source | Issued by Fluz on request | Self-serve in the Developers section of the dashboard |
| Scope | The operations your old vendor supported | The full Fluz platform |
**Connector keys are not dashboard keys.** The API key you generate in the Developers section of the Fluz dashboard will not authenticate against a connector, and vice versa. Connector credentials are provisioned by Fluz. Contact your Fluz representative to request one.
## When to use a connector, and when not to
You have a working vendor integration in production, you want Fluz supply and Fluz rates quickly, and you do not want to spend an engineering cycle on the switch. Time to live is measured in days.
You want the full platform: virtual cards, wallets and spend accounts, transaction data, webhooks, cashback rates, offer quoting, and the complete merchant catalog. None of that is reachable through a vendor-shaped interface.
A common path is to start with a connector to get volume flowing, then migrate to the [Fluz API](/overview) as you adopt capabilities the old vendor never had.
## Getting access
API Connectors are currently offered as a beta program. Contact your Fluz representative or email sales to request connector credentials and confirm operation coverage for your vendor.
## Pick your vendor
Orders and account balances. Basic auth, synchronous responses.
Orders and currency balances. Synchronous and asynchronous execution modes.
Immediate orders, order detail, card retrieval, and program balance.