Build vs Buy: Should You Call VIES Yourself or Use an API?

VIES is free and public, so the first instinct is almost always the same: we'll just call it ourselves. That instinct is not wrong. For some teams it is exactly the right call. But "free" describes the endpoint, not the integration, and the gap between the two is where the real decision lives.

This is a build-vs-buy framework, not a pitch. The scope is the EU-27 plus XI (Northern Ireland), which is what VIES covers. The goal here is to enumerate the actual work honestly — what you own when you build, what you offload when you buy — so you can decide which side of the line your case falls on. For most low-stakes, low-volume cases, building is fine. The point is to know that before you commit, not after.

The "we'll just call VIES" assumption

VIES is a system run by the European Commission that routes a validation query to the relevant national VAT database and reports back what that database says. The Commission does not hold the data centrally — each member state answers for its own numbers. You can read the plain-language version on the Commission's Your Europe VIES page, and the integration details on the VIES technical information page.

The happy path really is simple: send a VAT number, get back valid or invalid, sometimes with a trader name and address. If that is all you need, and you need it rarely, you may not need anything else. The assumption only breaks down when you look at what happens off the happy path — when a national database is down, when you validate the same number a thousand times a day, or when an auditor asks you to prove a check you ran eight months ago. None of that is in the "just call VIES" mental model, and all of it is work.

What building it yourself really includes

Here is the honest inventory. None of these are dealbreakers on their own; together they are the actual scope of "building VAT validation."

The SOAP client and parsing

VIES exposes two upstream interfaces: the legacy SOAP endpoint and, more recently, an unauthenticated REST endpoint that returns JSON. Picking REST saves you the XML parsing, but nothing else about the scope below changes — you still own the error mapping, the per-country downtime and throttling, the caching, and the audit capture. Either interface offers the same two checks. checkVat gives you the basic yes/no (with a name and address depending on the member state). checkVatApprox additionally accepts requester details — requesterCountryCode and requesterVatNumber — and, on a completed lookup, returns a requestIdentifier, which is the consultation number you keep as evidence.

So even the "simple" call, on the SOAP path, means building and maintaining a SOAP envelope, posting it as XML, and parsing an XML response into something your application can use:

<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:urn="urn:ec.europa.eu:taxud:vies:services:checkVat:types">
  <soapenv:Body>
    <urn:checkVatApprox>
      <urn:countryCode>DE</urn:countryCode>
      <urn:vatNumber>123456789</urn:vatNumber>
      <urn:requesterCountryCode>FI</urn:requesterCountryCode>
      <urn:requesterVatNumber>12345678</urn:requesterVatNumber>
    </urn:checkVatApprox>
  </soapenv:Body>
</soapenv:Envelope>

That is the request. You then parse the response XML, pull out valid, the trader fields, and requestIdentifier, and map SOAP faults onto your own error model. The checkVatService WSDL is the contract. It is not hard code, but it is code you own, forever, in a serialization format most of your stack no longer speaks natively.

Downtime and retries

This is the part that surprises people. VIES has no SLA and no uptime guarantee, and because it routes per member state, availability is per-country: one national database can be down for maintenance while every other country answers fine. The Commission's own materials note that national databases go offline during backups. So "is VIES up?" is not a yes/no question — it is "is the specific country you need up right now?"

Building this well means retries with backoff, distinguishing a transport failure from a genuine invalid, and deciding what your application does when the answer is neither valid nor invalid but simply unavailable. Do you block the signup? Queue the check? Fail open or closed? Those are product decisions you have to make and encode. There is also undocumented rate/abuse throttling — hammer VIES and you can get soft-blocked, which turns "just retry" into its own failure mode. We wrote up the shape of this problem in the guide on handling VIES downtime.

Caching without breaking compliance

At any real volume you cannot call VIES on every request — for latency, for throttling, and out of basic courtesy to a shared public system. So you cache. But a VAT validation result is time-sensitive evidence: a number that was valid in March can be deregistered by August. Cache too aggressively and your "proof" is stale; cache too little and you are back to hammering VIES.

The compliance-safe version means a deliberate TTL, storing the original check timestamp (not the cache-hit time), and never letting a cached row masquerade as a fresh contemporaneous check when audit evidence is what matters. It is a small system, but it is a system with correctness rules, not a one-line memoize. More on the trade-offs in caching VIES responses.

Audit evidence you have to persist

If you validate VAT IDs to support intra-EU B2B treatment, the check is not the deliverable — the evidence is. The strongest piece VIES itself gives you is the consultation number: the requestIdentifier returned by checkVatApprox, which is contemporaneous proof that you checked a specific number, at a specific time, and got a specific reply, in a form a tax administration can accept.

Worth being precise about what it is and is not. It is evidence of the lookup. It is not a tax certification, it does not adjudicate the transaction, and it does not by itself guarantee exemption — that treatment depends on the full set of conditions for the supply, not on one reference string. Getting the consultation number requires the requester-qualified checkVatApprox path, and storing it correctly (immutable rows, requester VAT ID alongside, source recorded, nullable where a national source answered) is more work than the call that produced it. The full breakdown is in audit evidence.

National-registry fallback and enrichment

When VIES can't answer for a given country, some national tax-authority and company-registry APIs can — either as a fallback while VIES is down, or as enrichment where they return richer trader data. Each of those sources is its own interface, its own auth, its own field mapping, and its own reliability profile. Coverage changes over time as authorities publish or retire endpoints, so this is not a "write once" component either. Building it means a per-source client layer and a policy for reconciling a national answer with a VIES answer — including the fact that a national confirmation is not the same evidence as a VIES consultation number.

Ongoing maintenance

Everything above is not a one-time build. VIES changes; national endpoints appear and disappear; throttling behaviour shifts; the SOAP contract gets revised. Someone on your team owns this indefinitely, and it is the kind of infrastructure that is invisible until it breaks during a customer's checkout or an audit. The honest cost of building is not the week you spend writing it — it is the year you spend keeping it correct.

When building in-house is the right call

Building is genuinely the right answer when the shape of your need is narrow:

• You validate rarely — occasional one-off checks, not a hot path.
• You do not need audit evidence, or your risk on a wrong answer is low.
• You can tolerate VIES being down, because a failed check just means "try again later" with no business consequence.
• You have the in-house appetite to own a small SOAP integration and keep it alive.
• You want zero external dependencies for regulatory, procurement, or data-residency reasons.

If most of that describes you, a thin checkVat call against VIES is a perfectly sound choice. Don't buy infrastructure you won't use. You can read what VIES is and wire it up directly — the endpoint is public and free, and for this profile that is the end of the story.

When buying wins

Buying starts to pay off when the off-happy-path work stops being hypothetical:

• Validation is on a hot path — every signup, every invoice, every checkout — where VIES downtime becomes your downtime.
• You need audit evidence you can produce months later: consultation number, timestamp, and source, stored reproducibly.
• Per-country availability gaps are unacceptable, so you need national fallback rather than a shrug when one member state is offline.
• The maintenance time — SOAP, retries, caching correctness, fallback clients — costs more than the API does.
• You want a plain REST interface your whole stack can call without anyone learning SOAP.

An API does not replace VIES — VIES is still the underlying source. What it does is wrap VIES (and national registries where available) with reliability, caching, evidence, and a REST contract, so the six sections above become someone else's problem. Against the vatnode contract the same lookup is three lines:

const res = await fetch('https://api.vatnode.dev/v1/vat/DE123456789', {
  headers: { Authorization: `Bearer ${process.env.VATNODE_API_KEY}` },
})
const data = await res.json()

The response is structured JSON — valid, vatId, countryCode, countryName, companyName, companyAddress, checkId, verifiedAt, source, and consultationNumber — with no SOAP envelope to build or parse. The differentiators are narrow and worth stating plainly rather than overselling: a zero-config path (the requester-qualified call runs by default, so you get the consultation number without wiring up checkVatApprox yourself), and a never-null result contract (you always get a structured answer with a source, even when the call fell back to a national database). That is it. If you want to size it against the build cost, here is what an API costs; if you want a broader look at the reliability layer, there's a production VIES alternative and the VIES API reference.

A simple decision checklist

Run down this list. More boxes on the left, build. More on the right, buy.

• Volume — occasional lookups → build; hot path → buy.
• Evidence — no audit need → build; you must produce proof later → buy.
• Downtime tolerance — a failed check is harmless → build; VIES down means revenue or signups blocked → buy.
• Country gaps — EU-average coverage is fine → build; you can't accept one member state being offline → buy.
• Maintenance appetite — you'll own SOAP and fallback indefinitely → build; that time is better spent elsewhere → buy.
• Data residency / procurement — external dependency is disallowed → build; no such constraint → buy.

There is no universally correct answer. There is a correct answer for your volume, your risk, and your team.

This is general information about EU VAT and VIES, not tax advice. Whether a specific transaction qualifies for zero-rating, exemption, or reverse charge depends on facts we can't assess here — confirm the treatment of your own transactions with a qualified tax adviser.

FAQ

Can I just call VIES directly for free?

Yes, VIES is free and public, but "free" only covers the endpoint — you still own the SOAP client, downtime handling, caching, audit storage, and national fallback, which is where the real cost sits.

What's the hardest part of building VAT validation in-house?

Usually resilience and evidence — VIES nodes go down per-country regularly, and storing reproducible audit proof (consultation number, timestamp, source) correctly is more work than the happy-path call.

Is a VAT validation API worth it for low volume?

If you validate rarely and don't need audit evidence or uptime guarantees, a thin in-house call may be enough; the API pays off once downtime, compliance evidence, or maintenance time start to matter.

Does an API replace VIES?

No — VIES is the underlying source. An API wraps VIES (and national registries where available) to add reliability, caching, evidence, and a simple REST interface on top.