Skip to main content
All LimitGuard API errors follow RFC 7807 Problem Details for consistent, machine-readable responses. Every error has a type, title, status, and detail field — making automated error handling straightforward for both human developers and AI agents.
The type field is always "about:blank" in the current API version. Future versions may introduce specific problem type URIs.

Status Code Reference


Error Response Format

Standard Error

All non-2xx responses return RFC 7807 problem details:

Validation Error (422)

Field-level validation errors return a detail array instead of a string. Field names are sanitized — internal paths are not exposed:
When detail is an array, iterate over it to surface all field errors at once. This avoids fixing one error only to encounter the next on retry.

400 Bad Request

Cause: A required request body field is absent entirely, or the request body is missing.
Fix: Check that your request includes all required fields. For /v1/entity/check, both entity_name and country are required. Verify you are sending Content-Type: application/json and a valid JSON body.
Cause: The request body cannot be parsed as JSON — often a trailing comma, unclosed brace, or non-UTF-8 encoding.
Fix: Validate your JSON before sending. Use json.dumps() in Python or JSON.stringify() in JavaScript rather than constructing JSON strings manually.
Cause: The Content-Type header is missing or set to a value other than application/json on a POST endpoint.Fix: Always include -H "Content-Type: application/json" on POST requests.

401 Unauthorized

Cause: The request reached an authenticated endpoint without an X-API-Key header, and no X-PAYMENT header was provided either.
Fix: Add X-API-Key: lg_live_xxxxxxxxxxxxxxxxxxxx to every request. Free endpoints (health, key creation, well-known routes) never require authentication.
Cause: The key was valid but has since been revoked or expired.Fix: Create a new key via POST /v1/keys/create. Keys are returned once — if lost, create a new one.
Cause: A sandbox key (lg_test_) is being used without the X-LimitGuard-Mode: sandbox header against a live endpoint, or vice versa.Fix: Use lg_live_ keys for production. lg_test_ keys automatically activate sandbox mode regardless of headers.

402 Payment Required

HTTP 402 is a protocol response, not just an error. LimitGuard implements the x402 V2 micropayment protocol. When you receive a 402, the response body is not an RFC 7807 error — it is a payment requirements object.
For AI agents, 402 is the expected first response when no payment or API key is provided. The correct flow is: receive 402 → build payment → retry with X-PAYMENT header.

Payment Requirements Response

x402 Payment Flow

1

Receive 402

Parse the accepts array. Choose a network (chainId) your agent can pay on.
2

Check the amount

The amount field uses 6 decimal places. 50000 = $0.05 USDC. Verify your wallet has sufficient balance before signing.
3

Build EIP-3009 signature (EVM) or SPL transfer (Solana)

Sign a TransferWithAuthorization with a unique nonce and a validBefore 5 minutes in the future. See the x402 Protocol guide for full code examples.
4

Retry with X-PAYMENT header

Base64-encode your payment payload and attach it as X-PAYMENT. Retry the exact same endpoint and body.

Common 402 Sub-Cases

Cause: The amount in your payment object is less than the minimum required for the endpoint and quality tier.
Fix: Use the amount value from the 402 response exactly. If using a non-default X-Response-Quality tier, the required amount changes — cached requires less, enhanced requires more. See the pricing table for per-endpoint amounts.
Cause: The validBefore timestamp in the EIP-3009 signature has passed. Signatures are valid for 5 minutes.Fix: Rebuild the payment with a fresh timestamp. Do not cache signatures for reuse — build a new one per request.
Cause: The same nonce was used in a previous request within the last 5 minutes.
Fix: Generate a cryptographically random 32-byte nonce for every request. Never reuse nonces, even if the previous request failed.
Cause: The EIP-712 signature does not verify against the claimed sender address, or the Solana signature is malformed.Fix: Ensure the sender field matches the wallet that signed the transaction. Verify the EIP-712 domain parameters match exactly: name: "USD Coin", version: "2", chainId as integer, verifyingContract as the USDC contract address.
Cause: The chainId in your payment is not in the accepted list.Fix: Use one of the four supported chain IDs: eip155:8453 (Base Mainnet), eip155:84532 (Base Sepolia), solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp (Solana Mainnet), or solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1 (Solana Devnet).
For testing x402 without spending real USDC, use Base Sepolia or Solana Devnet. Both are listed in the accepts array from sandbox and test environments.

403 Forbidden

Cause: Your API key tier does not include access to the requested endpoint. For example, /v1/kyb/check and /v1/compliance/* are only available on pro and enterprise tiers.
Fix: Upgrade your tier or use a tier-appropriate endpoint. See the pricing page for tier access matrix.
Cause: An lg_test_ key is being used but the request is routed to live data sources.Fix: Use lg_live_ keys for production. Test keys are sandboxed — they only return mock data.
Cause: The key was provisioned as read-only (e.g., a webhook consumer key) and is attempting a mutating operation.Fix: Use the correct key for the operation, or create a new key with the required permissions.

404 Not Found

Cause: A lookup endpoint (e.g., GET /v1/reputation/history/{entity_hash}) was called with an entity hash that does not exist in the system.
Fix: Entity hashes are generated by LimitGuard from the entity data. Run a POST /v1/entity/check first to create the entity record, then use the returned entity_hash for subsequent lookups.
Cause: A DELETE /v1/webhooks/{webhook_id} or test call was made with an unknown webhook_id.Fix: Use GET /v1/webhooks to list all registered webhooks and confirm the correct webhook_id.
Cause: The URL path does not exist — often a typo (e.g., /v1/entity/checks instead of /v1/entity/check) or a missing version prefix.Fix: All API endpoints are under /v1/. Refer to the API Reference for the exact path of each endpoint.

409 Conflict

Cause: A webhook with the same URL is already registered for your API key.
Fix: Use GET /v1/webhooks to check existing registrations. If you want to update events for an existing webhook, delete it first and re-create with the new configuration.

422 Unprocessable Entity

422 errors occur when the request is syntactically valid JSON but the field values fail business-logic validation. The detail field is always an array of field-level errors.
422 responses are sanitized — internal field paths and database details are never exposed. The field name matches the key in your request body.

Common Validation Errors

Cause: country is not a valid ISO 3166-1 alpha-2 code, or uses the alpha-3 format.Fix: Use two-letter uppercase codes: NL, BE, DE, FR, US. Not NLD, Netherlands, or lowercase nl.
Cause: entity_name is fewer than 2 characters or more than 255 characters.Fix: Pass the legal entity name as registered. Single-character values and very long strings are rejected.
Cause: kvk_number contains non-numeric characters or is not exactly 8 digits.Fix: KVK numbers are always 8 digits: "12345678". Do not include spaces, dashes, or the KVK: prefix.
Cause: iban fails structural validation (country prefix, check digits, or length for the given country).Fix: Pass a complete IBAN including country code and check digits: "NL91ABNA0417164300". Strip spaces before sending.
Cause: vat_number does not match the expected format for the given country prefix.Fix: Include the country prefix: "NL123456789B01", "BE0123456789". Format rules vary by country — see the European Commission VIES guidelines for country-specific formats.
Cause: wallet_address is not a valid EVM (0x…, 42 chars) or Solana (base58, 32-44 chars) address.Fix: Validate the address client-side before sending. EVM addresses must be checksummed or all-lowercase hex. Solana addresses must be valid base58.
Cause: domain contains a protocol prefix, path, or query string instead of a bare hostname.Fix: Send the bare domain only: "acmecorp.nl" — not "https://acmecorp.nl/about?lang=en".
Cause: events array in POST /v1/webhooks contains an unrecognized event name.Fix: Use events from the supported list: trust_score.updated, compliance.alert, entity.flagged, risk.threshold_exceeded. Check GET /v1/webhooks for the current supported list.

429 Too Many Requests

LimitGuard enforces two independent limits: a per-minute rate limit and a monthly quota.

Rate Limit Response

Retry-After Header

Every 429 response includes a Retry-After header with the number of seconds to wait:

Rate Limits by Tier

Monthly Quota Exceeded

When your monthly quota is exhausted, the detail changes:
Fix: Upgrade your tier or switch to x402 pay-per-use for the remainder of the month. Monthly quotas reset on the first of each month UTC.
Use the X-Response-Quality: cached header where acceptable — cached responses do not consume monthly quota if the entity was already scored within the cache TTL.

500 Internal Server Error

Cause: An unhandled exception occurred server-side. This is always a LimitGuard bug, never a client error. Fix:
  1. Note the Request ID from the detail field.
  2. Retry with exponential backoff — most 500s are transient.
  3. If the error persists for more than 5 minutes, check api.limitguard.ai/health for service status.
  4. Report persistent 500s to support@limitguard.ai with the Request ID.
500 errors on write operations (webhook creation, compliance subscription) should not be retried blindly — the operation may have partially succeeded. Check the resource state first with a GET before retrying.

503 Service Unavailable

Cause: Planned maintenance window or a cascading failure in a critical dependency (e.g., the sanctions list provider is unreachable and the circuit breaker is open). Fix:
  • Check Retry-After header if present.
  • Subscribe to status updates at api.limitguard.ai/health.
  • For x402 users: the circuit breaker fallback (cached wallet verification) handles most dependency failures transparently. A 503 indicates a more severe outage.

Error Handling Patterns

x402 Auto-Payment Handler

For AI agents that need to handle 402 responses automatically:

Debugging Checklist

  • Confirm the header name is exactly X-API-Key (capital X, capital A, capital K)
  • Confirm the key value starts with lg_live_ or lg_test_
  • Check for leading/trailing whitespace in the header value
  • Verify the key has not been revoked — create a new one at POST /v1/keys/create
  • Check that country is exactly 2 uppercase characters: "NL" not "nl" or "Netherlands"
  • Check that entity_name is at least 2 characters
  • For kvk_number: digits only, exactly 8 characters, as a string: "12345678" not 12345678
  • For iban: strip all spaces before sending
  • The detail array in the response will list every failing field — read all of them before retrying
  • Run GET /v1/usage/summary with your key to see your current tier
  • Check the pricing page for which endpoints are available on your tier
  • /v1/kyb/check, /v1/compliance/*, and enhanced quality tier require pro or higher
  • Confirm validBefore is at least 60 seconds in the future (use now + 300)
  • Confirm chainId in the payment payload exactly matches the one from the 402 response
  • Confirm recipient matches — do not substitute your own address
  • Confirm amount matches or exceeds the required amount
  • Generate a new random nonce for every attempt — do not reuse
  • Confirm the USDC contract address matches the network (Base Mainnet vs Sepolia differ)
  • 500 on entity checks is usually a transient timeout in a data source (e.g., KVK API slow response)
  • Retry up to 3 times with exponential backoff: 1s, 2s, 4s
  • If the error persists, try X-Response-Quality: cached to bypass live source queries
  • Include the Request ID from the error body when contacting support

Free Endpoints (Never Error on Auth)

These endpoints always return 200 and never require authentication or payment. They will not return 401, 402, or 403:

Further Reading

Rate Limits

Per-tier limits, burst handling, and quota management

x402 Protocol

Full x402 implementation guide with EVM and Solana examples

Authentication

API keys, sandbox mode, and key management

Sandbox

Test all error scenarios for free without quota