Authentication

v2 uses the same API keys as v1 — same format, same test/live split, same header. If you already call v1, you already have a working credential.

curl -X POST https://api.textilecredit.com/v2/rfq/request \
  -H "Authorization: Bearer tx_live_a1b2c3d4.your_secret_here" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

Everything in v1 authentication about key format, rotation, and keeping secrets server-side applies unchanged.

The alpha allowlist

On top of a valid key, your partner record must be allowlisted for v2. This is deliberate: it means a client that starts rendering v2 calls can't move real traffic onto the new venue until we've enabled it for you.

A valid key that isn't allowlisted gets:

{
  "error": {
    "code": "forbidden",
    "message": "This API key is not enabled for the RFQ beta",
    "request_id": "req_…"
  }
}

Ask us to enable it. Nothing about your v1 access changes either way.

Scopes

Same scope model as v1, and the same two scopes you already use for trading:

Scope	Grants
trades:write	POST /v2/rfq/request, POST /v2/rfq/{id}/submit
trades:read	GET /v2/rfq/{id}

A key without the scope for an endpoint gets 403 forbidden, exactly as on v1.

Unauthenticated endpoints

GET /v2/health and GET /v2/openapi.json need no credential, so monitors and codegen can reach them.

Test vs live

Keys are environment-scoped and the environment is baked into the prefix, same as v1: tx_live_… for mainnet corridors, tx_test_… for testnet. A test key against a mainnet chain (or the reverse) is a 400.

The BSC testnet cNGN ↔ USDT corridor is the one to integrate against — see Testnet (BSC). An RFQ corridor still has to be enabled there and have a maker online, so if you get no_makers_online on testnet, tell us rather than assuming your request is wrong.