Environments
Development, staging, and production API access — how they differ and how to obtain keys for each.
Nepex exposes the API in three environments: DEVELOPMENT, STAGING, and PRODUCTION. Each API key is tied to exactly one of these. A development key only authenticates against Nepex’s development endpoints; staging and production keys work only against their matching Nepex URLs. Using the wrong key for a URL is a common integration mistake — keep keys labeled and stored separately.
Development — For building and testing integrations against Nepex’s non-live environment. Browser calls from http://localhost and http://127.0.0.1 are typically allowed. Server-to-server calls from scripts or CI often do not send an Origin header; follow the same patterns Nepex documents for your stack.
Staging — For pre-go-live validation with your staging sites and backends. You should register the HTTPS origins you will call from (for example your staging portal URL). Requests that include an Origin header must match an origin you have saved for that environment on the Nepex travel website.
Production — For live traveller traffic. Origin rules are strict: browser-based calls must come from origins you have explicitly allowlisted. Backend-only integrations should still follow Nepex’s guidance on headers and TLS.
Getting keys per environment: After API access is enabled for your partner account, sign in at nepextravels.com, open Profile, and use the API / integration settings for each environment. Enter allowed origins (and optional webhook URL) for that tier, then Generate a key. Store each key under a clear name in your secrets manager (for example nepex-platform-staging-2026) so environments are never mixed.
If authentication consistently fails, double-check that you are using the base URL Nepex gave you for that environment together with the matching key. For persistent issues, contact Nepex support with the environment name and approximate time of failed requests (never send your API key).
- Never use a production key against a development or staging base URL, or vice versa
- Use different webhook URLs per environment so test callbacks do not reach production systems
- Regenerate keys after team changes or suspected leakage; old keys stop working once revoked