FraudEG API Authentication: Keys, Headers, and Security

Every request to the FraudEG REST API must be authenticated with an API key passed as a Bearer token in the Authorization header. There are no cookies, no OAuth flows, and no session management to set up — just a single header added to every call. This page explains how to get your key, how to use it correctly, and how to keep it secure.

API Key Authentication Model

FraudEG uses static API keys as Bearer tokens. When you include your key in the Authorization header, FraudEG verifies the key, identifies your account and environment, checks the key’s permissions, and then processes your request — all before any fraud logic runs. The expected header format is:

Authorization: Bearer <YOUR_API_KEY>

There is no token expiry by default. Keys remain valid until you manually revoke them from the dashboard, which means keeping them secret is critical.

Getting Your API Keys

API keys are managed in the FraudEG dashboard:

Log in to dashboard.fraudeg.com.
Go to Settings → API Keys.
Click Create new key.
Enter a descriptive label (for example, production-backend or staging-payments-service).
Select the environment: Live or Test.
Click Generate. Your key is shown once — copy it immediately and store it in a secrets manager or environment variable.

Create separate API keys for each environment and each service. For example, use one key for your production payments service, another for your staging environment, and another for local development. This limits blast radius if a key is ever compromised, and makes it easy to rotate one key without disrupting others.

Live Keys vs. Test Keys

FraudEG issues two classes of API key, distinguished by their prefix:

Key type	Prefix	Environment	Behavior
Live	`feg_live_sk_...`	Production	Scores real transactions, affects live fraud models, billed per request
Test	`feg_test_sk_...`	Sandbox	Mirrors production behavior, no real data, no billing

Always use a test key during development, integration testing, and CI pipelines. Use a live key only in your production environment, and only in server-side code.

Authenticating API Requests

Pass your API key in the Authorization header on every request. The examples below all call POST /v1/transactions/score, but the same header applies to every FraudEG endpoint.

curl -X POST https://api.fraudeg.com/v1/transactions/score \
  -H "Authorization: Bearer feg_test_sk_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"amount": 5000, "currency": "USD"}'

const response = await fetch('https://api.fraudeg.com/v1/transactions/score', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.FRAUDEG_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ amount: 5000, currency: 'USD' })
});

const data = await response.json();

import requests
import os

response = requests.post(
    'https://api.fraudeg.com/v1/transactions/score',
    headers={
        'Authorization': f'Bearer {os.environ["FRAUDEG_API_KEY"]}',
        'Content-Type': 'application/json'
    },
    json={'amount': 5000, 'currency': 'USD'}
)

data = response.json()

Notice that all three examples read the key from an environment variable (process.env.FRAUDEG_API_KEY / os.environ["FRAUDEG_API_KEY"]) rather than embedding it as a string literal. This is the expected pattern in production code.

Security Best Practices

Follow these rules to keep your API keys secure: Use environment variables or a secrets manager. Never write an API key as a string literal in your source code. Use environment variables locally and a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, etc.) in production. Keep keys server-side only. FraudEG API calls must be made from your backend. Your API key grants full access to your account — it must never appear in browser JavaScript, mobile app binaries, or any client-side code. Use one key per service. Scope each key to a single application or service. When you need to rotate or revoke a key, only that one service is affected. Rotate keys proactively. Rotate keys on a regular schedule (every 90 days is a reasonable baseline) and immediately if you suspect any exposure. Audit key usage. The FraudEG dashboard shows last-used timestamps and request counts per key. Review this regularly and revoke any keys that are no longer in use.

Never embed API keys in frontend code. If your API key appears in client-side JavaScript, a mobile app bundle, a public Git repository, or browser developer tools, treat it as compromised immediately. Go to Settings → API Keys in the dashboard, revoke the exposed key, and generate a new one. All FraudEG API calls must originate from your server.

Rotating and Revoking Keys

To rotate a key:

Go to Settings → API Keys in the dashboard.
Create a new key with the same label and environment as the one you are replacing.
Update your environment variable or secrets manager entry with the new key.
Deploy the updated configuration to your service.
Once the new key is confirmed working, return to Settings → API Keys and click Revoke next to the old key.

To immediately invalidate a key (for example, after a suspected leak):

Go to Settings → API Keys.
Find the key and click Revoke.
Confirm the revocation. The key stops working instantly — ongoing requests using it will immediately receive 401 Unauthorized responses.

Authentication Error Responses

FraudEG returns standard HTTP error codes for authentication and authorization failures:

401 Unauthorized

Returned when the Authorization header is missing, malformed, or contains an invalid or revoked key.

{
  "error": {
    "code": "UNAUTHORIZED",
    "message": "Invalid or missing API key. Include a valid Bearer token in the Authorization header.",
    "docs_url": "https://docs.fraudeg.com/authentication"
  }
}

Common causes:

The Authorization header is not present in the request.
The key has been revoked from the dashboard.
The key string was truncated or corrupted (check for extra whitespace or missing characters).
You are using a test key against the production environment URL, or vice versa.

403 Forbidden

Returned when the API key is valid but does not have permission to access the requested resource. This can happen if the key was created with restricted scopes.

{
  "error": {
    "code": "FORBIDDEN",
    "message": "This API key does not have permission to access the requested resource.",
    "docs_url": "https://docs.fraudeg.com/authentication"
  }
}

Common causes:

The key was created with a limited scope that excludes the endpoint you are calling.
You are attempting to access account-level resources (for example, key management endpoints) with a restricted key.

If you encounter a 403 you do not expect, go to Settings → API Keys, check the key’s assigned scopes, and create a new key with the appropriate permissions.

Get Started

Core Concepts

Guides

Platform

FraudEG API Authentication: Keys, Headers, and Security

API Key Authentication Model

Getting Your API Keys

Live Keys vs. Test Keys

Authenticating API Requests

Security Best Practices

Rotating and Revoking Keys

Authentication Error Responses

401 Unauthorized

403 Forbidden

​API Key Authentication Model

​Getting Your API Keys

​Live Keys vs. Test Keys

​Authenticating API Requests

​Security Best Practices

​Rotating and Revoking Keys

​Authentication Error Responses

​401 Unauthorized

​403 Forbidden

API Key Authentication Model

Getting Your API Keys

Live Keys vs. Test Keys

Authenticating API Requests

Security Best Practices

Rotating and Revoking Keys

Authentication Error Responses

401 Unauthorized

403 Forbidden