TradeVowConnectRequest API access

Developer access guide

Your account. Your integration credentials.

Apply and verify

The Site and all documentation are public. Complete the Access application, accept the terms and privacy notice, and verify your business email with the TradeVow six-digit code. Verified applications receive sandbox eligibility. Live access requires explicit review and approval. Already registered? Use TradeVow email sign-in on the same Access page.

Codes expire after ten minutes, allow five attempts, and can be resent after 60 seconds. Limits also apply per email (five requests/hour) and privacy-preserving client identifier (20/hour). Codes are single-use; requesting another invalidates the previous one.

Create, rotate and revoke keys

Choose a name, environment and the minimum approved scopes. Sandbox keys begin with tv_test_; live keys begin with tv_live_. Both include 256 random bits. The full secret is displayed once; copy it directly into your server-side secret manager. Never include it in source control, browser code, URLs or logs.

Keys expire after 90 days by default and may be configured through the API for up to one year. There are at most five active keys per organisation/environment. Rotation immediately revokes the old key and returns one replacement; use a separate new key for a staged, overlapping deployment. Revocation takes effect immediately for subsequent authentication.

Create/rotate requests require a UUID idempotencyKey in the JSON body. Retain it for an identical retry. A processed retry returns metadata with secret: null; lost secrets cannot be recovered. Use a new UUID for a different operation.

X-TradeVow-API-Key: <your server-held key>

Sessions and account API

Account management uses a first-party Secure, HttpOnly, SameSite=Lax cookie, separate from API keys. Sessions expire after seven days, or 24 hours idle. Sign-out revokes the active session. Account API responses are never cached. Browser mutations require the exact origin https://connect.tradevow.com; Postman should send this Origin header and use its cookie jar.

Use the Postman collection and Postman variables. Keep OTP and API-key values confidential and store them in Postman Vault. Institutional transaction access requires an approved API key, the required permission and authorisation for the requested transaction. Confirm availability for other business APIs before integration.

Approved scopes

Scope names match the A–I contracts. A key must pass organisation, account, environment, expiry and current approval checks as well as its operation scope. API-key approval does not bypass transaction authorisation or business-policy decisions.

A · Partner & organisation APIs

partner_profile:read, organizations:read, organizations:write, partner_connections:write

B · KYB & trust APIs

verifications:read, verifications:write, verification_decisions:write

C · Transaction APIs

transactions:read, transactions:write, transactions:activate, transaction_parties:write

D · Trade instrument APIs

trade_instruments:read, trade_instruments:write

E · Evidence & document APIs

evidence:read, evidence:write, evidence:verify, evidence_packs:read

F · Logistics & execution APIs

shipments:read, shipments:write, execution_events:write

G · Compliance & rules APIs

corridor_rules:read, compliance:read, compliance:write

H · Finance-readiness APIs

finance_readiness:read, funding_applications:write, funding_decisions:write

I · Settlement APIs

settlements:read, settlements:write, payment_events:write

Errors and webhook security

{"error":{"code":"RATE_LIMITED","message":"Please wait before requesting another code."}}

400 indicates invalid fields; 401 an invalid or expired session/key; 403 an origin, approval or scope denial; 404 an inaccessible key; 409 an idempotency conflict or key limit; 429 a request-rate limit; and 503 temporary service/delivery unavailability. Retry transient failures with backoff, retaining the same idempotency UUID for a mutation.

Access webhooks are internal transport, not browser integration endpoints. Server-to-server payloads use authenticated encryption, route-bound timestamps and single-use request IDs. The encrypted transport retains no execution payloads for these workflows. Registered callback URLs do not initiate outbound callbacks in this release; future A–I event integrations must verify the documented event signatures.

Open API access →