ATverify

Caching

30-day TTL for valid responses, 24-hour TTL for invalid. How to bypass cache when you need a fresh lookup.

Every successful validation is cached. Hitting the cache returns in ~2ms and doesn't count against your quota.

TTLs

Response typeTTL
valid: true30 days
valid: false24 hours
registry_unavailable5 minutes (soft fail)

Why 30 days? Most companies' VAT status doesn't change often, but monthly re-verification is a common compliance requirement. 30 days lets you cache for ~one month with a buffer for business logic.

Detecting cache hits

Every response includes meta.cached and meta.source_status:

{
  "data": {
    "valid": true,
    "vat_number": "IE6388047V",
    "verified_at": "2026-04-10T09:14:29Z"
  },
  "meta": {
    "cached": true,
    "source": "vies",
    "source_status": "cached",
    "latency_ms": 2,
    "request_id": "a1b2c3d4-..."
  }
}

data.verified_at always reflects the original registry fetch time, even on cache hits.

meta.source_status is "live" for fresh lookups, "cached" for cache hits, or "degraded" when the registry was unavailable and we fell back to a cached result.

Bypassing cache

For compliance workflows requiring a fresh registry call, add cache=false as a query parameter:

curl "https://api.vatverify.dev/v1/validate?vat_number=IE6388047V&cache=false" \
  -H "Authorization: Bearer vtv_live_xxx"

Each bypass counts as a live registry call (uses quota). Use sparingly.