API keys
Bearer authentication
TrustShield API requests are designed to use the standard Authorization header. The same pattern works across command line tools, backend services, mobile gateways, and future SDKs.
Authorization: Bearer <api_key>curl $NEXT_PUBLIC_API_BASE_URL/api/public/analyze/url \
-H "Authorization: Bearer $TRUSTSHIELD_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com/login"}'Credential lifecycle
Key rotation and future OAuth
API keys are the simplest credential model for server-to-server integrations. Enterprise OAuth can be added later for workspace delegation and fine-grained authorization without changing the application integration pattern.
Store API keys in a server-side secret manager or encrypted environment configuration.
Use separate credentials for development, staging, and production environments.
Rotate keys on a planned schedule and immediately after suspected exposure.
Limit scopes by module when scoped credentials are available.
Record correlation IDs for support without logging raw secrets or sensitive payloads.
Authorization header
Send the bearer token with every API call. Requests without authentication should be treated as unauthenticated and handled with a user-safe error state.
Never expose credentials
Do not place TrustShield API keys in frontend JavaScript, Android resources, public CI logs, screenshots, crash reports, or support tickets.