Authentication
How to authenticate with the FX-Port API using Bearer tokens. Key permissions, prefixes, and security guidance.
All requests must include a Bearer token in the Authorization header.
Authorization: Bearer fxp_live_YOUR_KEYGet your API keys at fx-port.com/dashboard/api.
Permission levels
| Permission | What it allows |
|---|---|
| Read | Search, price, get quotes, retrieve bookings, airport lookups, balances, history |
| Read+Write | All read access plus creating bookings, paying held orders, cancelling reservations |
A read key returning 403 read_write_permission_required means the operation is state-changing
(booking, payment, or cancellation). Use a read+write key for those.
Key prefixes and environments
There is one base URL for all environments. The environment is determined entirely by the key prefix.
| Prefix | Environment | Behaviour |
|---|---|---|
fxp_live_ | Live | Real agency data and live financial ledger |
fxp_test_ | Sandbox | Isolated test bookings; balance endpoints return empty data |
External keys (issued to agencies) automatically resolve the agency identity from the key itself.
IP restrictions
You can restrict a live key to specific IP addresses in the dashboard. Recommended for production Read+Write keys.
Security guide
An FX-Port API key with Read+Write permission can create bookings and trigger real financial debits from your agency balance. Treat it with the same care as a payment credential.
Always keep keys server-side
Never expose your FX-Port API key in:
- Browser JavaScript (React client components, Vue, Angular, plain JS)
- Mobile apps (React Native, Expo, Flutter, native iOS/Android)
- Public repositories, commit history, or CI/CD environment variables visible in build logs
- Client-side
.envfiles shipped with a compiled app
Your app's backend (Node.js, Python, Go, etc.) should be the only code that ever reads and uses the FX-Port API key. If your front-end needs to trigger a booking, it should call your own authenticated backend, which then calls FX-Port on the user's behalf.
Browser/App → Your backend → FX-Port API
↑
API key lives here onlyMinimal-permission keys
Use a Read-only key for integrations that only display search results, balances, or status. Reserve the Read+Write key for the backend service that actually creates bookings.
Key rotation
Rotate keys immediately if you suspect a leak. The dashboard lets you invalidate and replace a key without downtime.
Broader security hygiene
These rules apply to every sensitive credential in your application stack, not just FX-Port keys.
- Supabase / database API keys — never expose the
service_rolekey in a browser or mobile app. Only theanonkey can be used client-side, and even that should be behind Row-Level Security policies. - Third-party vendor keys (Stripe, Twilio, etc.) — always consumed server-side. A leaked Stripe secret key or Twilio auth token can cause direct financial loss.
- WordPress and open-source CMS plugins — themes and plugins are a frequent attack vector. Credentials stored in a WordPress database are regularly exfiltrated through plugin vulnerabilities. If you run a CMS alongside your booking integration, keep credentials in separate, isolated infrastructure and audit installed plugins regularly.
- Dependency CVEs — keep your runtime and framework versions current. Subscribe to security advisories for your stack (nodejs.org/en/security, github.com/advisories) and apply patches promptly.