All RAIL API requests are authenticated with API keys. Each key is scoped to an application , and every evaluation made with it is governed by that application’s policy. Keys appear in your usage logs.
To see which application a key belongs to and the policy governing it, call GET /config Getting an API key
Open your dashboard
Go to your Dashboard and navigate to the API Keys section.
Generate a key
Click Generate Key . Keys start with rail_ and are shown exactly once. Copy yours immediately. Your key will not be shown again after you close the dialog. Store it securely before leaving the page.
Using the API key Pass your key as a Bearer token in the Authorization header on every request:
Authorization: Bearer YOUR_RAIL_API_KEY
Full cURL example:
curl -X POST https://api.responsibleailabs.ai/railscore/v1/eval \ -H "Authorization: Bearer YOUR_RAIL_API_KEY" \ -H "Content-Type: application/json" \ -d '{"content": "Your AI-generated text here", "mode": "basic"}'
SDK authentication Both SDKs accept the API key at client construction and attach the header automatically:
from rail_score_sdk import RailScoreClient import os # Pass key directly (fine for scripts) client = RailScoreClient( api_key = "YOUR_RAIL_API_KEY" ) # Recommended: read from environment variable client = RailScoreClient( api_key = os.environ[ "RAIL_API_KEY" ])
Environment variables Never hardcode API keys in source files. Use environment variables and keep keys out of version control.
Local (dotenv)
Vercel / Edge
Docker
# .env — add to .gitignore, never commit this file RAIL_API_KEY = YOUR_RAIL_API_KEY
from dotenv import load_dotenv import os load_dotenv() api_key = os.environ[ "RAIL_API_KEY" ]
Add via Vercel Dashboard > Settings > Environment Variables . Variable name: RAIL_API_KEY Never prefix the variable with NEXT_PUBLIC_. That would expose it in the browser bundle.
// Server-side only const apiKey = process . env . RAIL_API_KEY ;
# Pass at runtime — never bake secrets into image layers docker run -e RAIL_API_KEY=YOUR_RAIL_API_KEY my-app # docker-compose.yml services: app: image: my-app environment: - RAIL_API_KEY= ${ RAIL_API_KEY }
Key management You can create multiple keys for different environments (production, staging, CI). Manage all keys from your dashboard .
Action When to use Generate key New environment, onboarding a new service, or rotating credentials on schedule Rename key Add context like “production-chatbot” or “staging-ci” for usage tracking Revoke key Suspected leak, employee offboarding, or decommissioning a service. Takes effect immediately.
Zero-downtime rotation: Generate a new key, deploy it to your service and verify it works, then revoke the old key. Swapping takes seconds.
Rate limits Rate limits are applied per API key. Exceeding the limit returns HTTP 429.
Plan Requests / min Requests / day Free 10 100 Pro 60 5,000 Business 300 50,000 Enterprise Custom Custom
Security best practices
Never expose keys in client-side code. Browsers are public. Always call the API from your backend or serverless function.Store keys in environment variables, never hardcoded in source files or Docker images.Add .env to .gitignore before the first commit so keys are never accidentally pushed.Use separate keys per environment. If staging is compromised, production stays safe.Revoke immediately if exposed. Generate a replacement first, then revoke.Rotate on a schedule. Periodically regenerating keys limits the blast radius of any undetected leak. Auth error responses Status Error Fix 401Missing or malformed Authorization header Add Authorization: Bearer … 401Invalid API key Verify the key starts with rail_ and is copied correctly 403API key revoked or inactive Generate a new key from the dashboard 429Rate limit exceeded Reduce request frequency or upgrade plan
What’s next
Quickstart Make your first evaluation request in under 5 minutes.
Credits & Pricing Understand how credits are charged per call.
API Reference Full parameter reference for all endpoints.
Dashboard Manage keys, view usage, and monitor credit balance.
