Authentication
All Gett API requests must be authenticated using a Bearer token in the Authorization header.
Code
Getting Your API Key
API keys are issued through the Developer Portal after your organization completes partner onboarding. Contact our partnerships team to get started.
Once onboarded, any member of your organization can create API keys from the portal.
Environments
Sandbox and production use separate API keys and separate base URLs. Keys from one environment will not work in the other.
| Environment | Base URL | Purpose |
|---|---|---|
| Sandbox | https://api-sandbox.gett-tech.com | Development and testing |
| Production | https://api.gett-tech.com | Live traffic |
Sandbox rate limits are 5x higher than production to give you room during development.
Key Management
Manage your API keys from the Developer Portal. You can:
- Create new keys with optional descriptions and expiration dates
- Rotate (Roll) existing keys — generates a new key value while keeping the same key entry
- Delete compromised or unused keys immediately
Organization Scoping
API keys are scoped to your partner organization, not individual user accounts:
- All organization members can create, rotate, and delete keys
- Rate limits are shared across all keys belonging to the same organization
- Revoking a key affects anyone using it — coordinate with your team before deleting
Security Best Practices
Your API key is a secret. Never expose it in client-side code, mobile apps, or public repositories.
- Store keys securely — Use environment variables or a secret manager, never hardcode in source
- Never commit keys — Add credential files to
.gitignoreand audit your repository - Rotate periodically — Use the portal's Roll feature to rotate keys without downtime
- Separate by environment — Use distinct keys for sandbox and production
- Server-side only — Always make API calls from your backend; never from browsers or mobile apps
Error Responses
If authentication fails, the API returns a 401 Unauthorized response in RFC 9457 format:
Code
Common causes:
- Missing
Authorizationheader - Malformed header (e.g., missing
Bearerprefix) - Expired or revoked API key
- Using a sandbox key against the production endpoint (or vice versa)
A 401 is not retryable — fix the credential issue before retrying.
Consumer Authentication
The API key authenticates your platform to Gett. It does not identify the end user placing an order — that's a separate concern.
Session creation is a server-to-server call authenticated with your API key. The result is a short-lived JWT (session token) you pass to the Marketfront SDK or send to your frontend to call session-gated endpoints directly.
Per-partner identity uniqueness. Each partner has its own user namespace. The same end user signing in on two different partner storefronts resolves to two distinct Gett accounts — carts, saved addresses, payment methods, and order history are never shared between partners.
Consumer Sign-in
The mechanics of resolving a consumer's identity depend on which integration path you're using:
- Marketfront SDK partners. The embed manages sign-in inside its own UI. When an anonymous user reaches a checkout action, the embed prompts for sign-in; partners do not host the trigger. See Sessions in the SDK guide.
- Raw Marketfront API partners. All partner API calls authenticate with a server-side API key. The session/identity layer is internal to the SDK and is not part of the partner API surface.
Webhook Authentication
For inbound webhooks (Gett calling your system), authentication uses HMAC-SHA256 signatures rather than API keys. Each webhook request includes a Signature header (plus Timestamp for replay protection and API-Version for the protocol version) that you must verify before processing.
See Webhooks for signature verification details and code examples.