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 type | TTL |
|---|---|
valid: true | 30 days |
valid: false | 24 hours |
registry_unavailable | 5 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.