Authentication
All Gett API requests must be authenticated using a Bearer token in the Authorization header.
Code
Getting Your API Key
Your partner account is provisioned by Gett during onboarding — account setup is not self-serve. Contact our partnerships team to get started.
Once your account exists and a Gett operator has invited you, your key is already waiting in the Developer Portal — you do not need to ask anyone to send you the value. Sign in with the email address you were invited on, and the page lists every key issued to your organization, grouped under a Live or Sandbox heading.
If that page is empty, see Why can't I see a key? — an empty page has two quite different causes.
Environments
Sandbox and production share one base URL — your API key determines the environment. Each key is bound to a single environment, and a key from one environment will not act on the other's data.
| Base URL | https://api.gett.co (all environments) |
| Environment | Determined by your API key — Live or Sandbox |
There is no separate sandbox host. Provision a sandbox key to develop and test against sandbox stores; swap it for your production key to go live — the base URL never changes. Sandbox and production draw on the same rate limit.
Key Management
Manage your API keys from the Developer Portal. For each key you can:
- Copy the value — keys stay readable in the portal, so a mislaid key is a lookup, not a re-issue
- Rotate (Roll) a key — mints a new value and invalidates the old one immediately
- Delete a compromised or unused key
- Rename its label, to tell one integration's key from another's
Minting a brand-new key is not self-serve. Keys are issued by a Gett operator when your Live or Sandbox environment is created, so ask your Gett contact if you need an additional one. Rotating a key you already hold needs nobody's help and can be done at any time.
Roll is not a way to recover a key you have mislaid. Rolling invalidates the key your integration is currently sending, and anything still using the old value starts receiving 401 responses. If you cannot find your key, read it off this page instead.
Who Can See a Key
Key access follows the individual developer who was invited, not your organization's membership list. The two are separate mechanisms, and this is the single most common source of confusion:
- A Gett operator invites a named email address to your partner account. That address — once it has signed in at least once — can see and manage that environment's keys.
- Belonging to your organization in the portal does not by itself grant sight of a key.
- To give a colleague access, ask your Gett contact to invite their address. To remove access, ask for it to be withdrawn.
- Rate limits are shared across all keys belonging to the same organization.
- Rolling or deleting a key affects everyone using it — coordinate with your team first.
Why Can't I See a Key?
An empty API Keys page has two causes. They look identical and need different fixes:
| Cause | Fix |
|---|---|
| No environment has been provisioned for your organization yet | Contact your Gett representative to have a Live or Sandbox environment created |
| A key exists, but the address you signed in with has not been granted access to it | Ask your Gett contact to invite this email address, then sign in again |
If you were invited before you had ever signed in, sign in first and then ask for the invitation to be re-sent. Access cannot attach to an account that does not exist yet, so the first invitation will have had nothing to attach to.
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
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.