type, title, status, and detail field — making automated error handling straightforward for both human developers and AI agents.
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 adetail array instead of a string. Field names are sanitized — internal paths are not exposed:
400 Bad Request
Missing required field
Missing required field
/v1/entity/check, both entity_name and country are required. Verify you are sending Content-Type: application/json and a valid JSON body.Malformed JSON body
Malformed JSON body
json.dumps() in Python or JSON.stringify() in JavaScript rather than constructing JSON strings manually.Unsupported Content-Type
Unsupported Content-Type
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
Missing X-API-Key header
Missing X-API-Key header
X-API-Key header, and no X-PAYMENT header was provided either.X-API-Key: lg_live_xxxxxxxxxxxxxxxxxxxx to every request. Free endpoints (health, key creation, well-known routes) never require authentication.Revoked or expired key
Revoked or expired key
POST /v1/keys/create. Keys are returned once — if lost, create a new one.Test key in production
Test key in production
lg_test_ was sent to the production API, which refuses it: 401 Test keys not accepted in production.Fix: For mock data use a sandbox key (lg_sandbox_..., free from POST /v1/keys/create with "tier": "sandbox"); for real data use an lg_live_ key. There is no sandbox header: X-Limitguard-Mode is ignored.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.X-PAYMENT header.Payment Requirements Response
x402 Payment Flow
Receive 402
accepts array. Choose a network (chainId) your agent can pay on.Check the amount
amount field uses 6 decimal places. 850000 = $0.85 USDC. Verify your wallet has sufficient balance before signing.Build EIP-3009 signature (EVM) or SPL transfer (Solana)
TransferWithAuthorization with a unique nonce and a validBefore 5 minutes in the future. See the x402 Protocol guide for full code examples.Retry with X-PAYMENT header
X-PAYMENT. Retry the exact same endpoint and body.Common 402 Sub-Cases
Insufficient payment amount
Insufficient payment amount
amount in your payment object is less than the minimum required for the endpoint and quality tier.amount value from the 402 response exactly. If using a non-default X-Response-Quality tier, the required amount changes — cached requires less. See the pricing table for per-endpoint amounts.Expired payment signature (validBefore exceeded)
Expired payment signature (validBefore exceeded)
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.Nonce replay detected
Nonce replay detected
Invalid payment signature
Invalid payment signature
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.Unsupported chain
Unsupported chain
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).x402 error codes
A 402 that rejects a payment carrieserrorCode in its body beside error; the facilitator endpoints /x402/verify and /x402/settle return the same values as invalidReason. This table is generated from the API’s X402ErrorCode enum.
403 Forbidden
Entity report with a sandbox key
Entity report with a sandbox key
POST /v1/reports/entity (and the MCP get_compliance_report tool) was called with a sandbox key. Reports are built only from real checks.lg_live_ key or pay per call with x402.Operator route
Operator route
/v1/admin/*). Customer keys carry the least-privileged role, so the API answers 403 with Insufficient role or Insufficient permissions.Fix: None needed on your side: these routes are not part of the customer API.Watchlist without an API key
Watchlist without an API key
/v1/watchlist) belong to an API key’s own tenant. A call that reached them without a key-bound tenant, for example one paid only by x402, is answered 403 Tenant context required.Fix: Call the watchlist routes with an API key.Entity report errors
POST /v1/reports/entity and GET /v1/reports/{report_id} answer errors as RFC 7807 problem details whose type links to the entries below. Each body also carries instance (the request path) and errorCode.
404 Not Found
Entity not found
Entity not found
GET /v1/reputation/history/{entity_hash}) was called with an entity hash that does not exist in the system.POST /v1/entity/check first to create the entity record, then use the returned entity_hash for subsequent lookups.Webhook not found
Webhook not found
DELETE /v1/webhooks/{webhook_id} or test call was made with an unknown webhook_id, or with the ID of a webhook another API key registered.Fix: Use GET /v1/webhooks to list all registered webhooks and confirm the correct webhook_id.Unknown endpoint path
Unknown endpoint path
/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.422 Unprocessable Entity
422 errors occur when the request is syntactically valid JSON but the field values fail business-logic validation. For field validation thedetail field is an array of field-level errors; a few checks made after validation (such as the webhook URL check) return a single string detail instead.
Common Validation Errors
Invalid country code
Invalid country code
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.entity_name too short or too long
entity_name too short or too long
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.Invalid KVK number format
Invalid KVK number format
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.Invalid IBAN format
Invalid IBAN format
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.Invalid VAT number format
Invalid VAT number format
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.Invalid wallet address
Invalid wallet address
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.Invalid domain format
Invalid domain format
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".Invalid webhook event type
Invalid webhook event type
events array in POST /v1/webhooks contains an unrecognized event name.Fix: Use event types from the list in the Webhooks guide: sanctions.match.new, trust.score.changed, trust.level.downgrade or certificate.expired. There is no * wildcard. Only sanctions.match.new is sent today; delivered_events in the registration response lists which of yours are live.Invalid webhook URL
Invalid webhook URL
url in POST /v1/webhooks is not https://, its host does not resolve, or it resolves to a private, loopback, link-local, reserved or cloud-metadata address. This error carries a plain string detail instead of the field array above:detail values: "URL must use HTTPS" and "Cannot resolve hostname '<host>': ...".Fix: Use a public https:// URL whose host resolves in public DNS.429 Too Many Requests
Limitguard enforces two independent limits per key: a per-minute limit and a rolling 24-hour limit. A verified x402 payer has a per-minute limit only.Rate Limit Response
Retry-After Header
Every 429 response includes aRetry-After header with the number of seconds to wait:
Rate Limits by Tier
Daily Limit Reached
When a key hits its rolling 24-hour limit, thedetail names it:
Retry-After, top up to a higher tier for a higher limit, or pay per call with x402, which has no daily cap. The monthly request caps on keys are abuse limits, not a usage allowance you buy.
500 Internal Server Error
- Note the
Request IDfrom thedetailfield. - Retry with exponential backoff — most 500s are transient.
- If the error persists for more than 5 minutes, check api.limitguard.ai/health for service status.
- Report persistent 500s to support@limitguard.ai with the Request ID.
503 Service Unavailable
- Check
Retry-Afterheader 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
Recommended Client Logic
x402 Auto-Payment Handler
For AI agents that need to handle 402 responses automatically:Debugging Checklist
Getting 401 even with a valid key?
Getting 401 even with a valid key?
- Confirm the header name is exactly
X-API-Key(capital X, capital A, capital K) - Confirm the key value starts with
lg_live_orlg_sandbox_(lg_test_keys are refused in production) - 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
Getting 422 but my JSON looks correct?
Getting 422 but my JSON looks correct?
- Check that
countryis exactly 2 uppercase characters:"NL"not"nl"or"Netherlands" - Check that
entity_nameis at least 2 characters - For
kvk_number: digits only, exactly 8 characters, as a string:"12345678"not12345678 - For
iban: strip all spaces before sending - The
detailarray in the response will list every failing field — read all of them before retrying
Getting 403 but my key is valid?
Getting 403 but my key is valid?
- Run
GET /v1/usage/summarywith your key to see your current tier - Check the pricing page for which endpoints are available on your tier
/v1/kyb/checkand/v1/compliance/*requireproor higher
x402 payment keeps returning 402?
x402 payment keeps returning 402?
- Confirm
validBeforeis at least 60 seconds in the future (usenow + 300) - Confirm
chainIdin the payment payload exactly matches the one from the 402 response - Confirm
recipientmatches — do not substitute your own address - Confirm
amountmatches 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)
Intermittent 500 errors on entity checks?
Intermittent 500 errors on entity checks?
- 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: cachedto bypass live source queries - Include the
Request IDfrom the error body when contacting support