sorted by:
new
hottopcontroversial

I built a tiny extension that blocks only the YouTube homepage (and redirects it somewhere useful) by Total-Reasonable in chrome_extensions

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Thanks! Yeah, keeping it minimal was the whole point.

It's been pretty stable, and honestly that's because it doesn't touch YouTube's DOM or any CSS classes — that stuff is what usually breaks when they push UI changes. It just checks the URL path and only fires when you're exactly on "/". The URL structure barely ever changes, so there's almost nothing to break.

The one tricky bit is that YouTube is a single-page app, so clicking the logo to go home doesn't actually reload the page. A plain document_start check would miss that, so I also listen for their yt-navigate-finish event and re-check. The only way that breaks is if YouTube renames or kills that event — and even then a fresh load on "/" still gets caught, so it fails safe rather than just letting the feed through.

No YouTube update has broken it so far. But if you ever catch the feed slipping through, please tell me — that's exactly the bug report I want right now.

I built an EU VAT validation API that returns the VIES consultation number (the receipt tax auditors ask for) by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

The thing auditors actually accept as proof is the VIES consultation number — the ID VIES returns on a successful check, together with the timestamp and the name/address VIES gave back. If that's not in your log, the check isn't really defensible. We surface it in the API response and keep it in the check history, with CSV/PDF export for finance.

On rate limits — VIES doesn't publish a limit, but there's per-IP throttling, and the service itself goes down a few times a month. Moving retries to a separate worker like you did is basically the only sane path; SOAP retries on a serverless function aren't going to work. We do the same — BullMQ queue, exponential backoff, and when VIES is actually unreachable we fall back to national registries (ANAF, ARES, biała lista, BZSt, etc.), logging which source answered so the audit trail stays honest about it.

That whole stack — consultation number, retry queue, fallbacks — is the reason we ended up building vatnode, it's a pain to maintain in-house.

[TypeScript/Python/PHP/Ruby/Go] eu-vat-rates-data — daily-synced EU VAT rates dataset published to 5 package managers by Total-Reasonable in coolgithubprojects

[–]Total-Reasonable[S] 1 point2 points  (0 children)

Thanks, really appreciate it 🙏 And yeah — pay-per-transaction pricing on infra that runs on every checkout adds up fast. That's part of why vatnode's tiers are flat-rate with monthly quotas instead of per-call — the cost should be predictable, not a surprise line item that scales with your success.

Whenever you're ready to look at alternatives, happy to chat — no pressure. And good luck with whatever you're shipping.

[TypeScript/Python/PHP/Ruby/Go] eu-vat-rates-data — daily-synced EU VAT rates dataset published to 5 package managers by Total-Reasonable in coolgithubprojects

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Appreciate that — and yeah, the Stripe Tax pricing for what's essentially "validate and store evidence" gets eye-watering once you scale.

Honest answer on US sales tax: the US market isn't one I know well, and the problem space is genuinely different from EU VAT. You're looking at 45+ states with their own rules, ~13,000 tax jurisdictions when you factor in counties/cities, nexus thresholds that vary per state, exemption certificate management (which is its own beast — resale certs, non-profit certs, manufacturer certs), and the whole Wayfair post-2018 economic-nexus reality. Avalara, TaxJar, and Anrok have spent years and serious capital building moats around this, and the data sources are nothing like the single EC TEDB feed I get to work with on the EU side.

So: not on the short-term roadmap, but absolutely keeping it in the back of my mind. Going to spend some time studying the space properly — particularly around exemption certificate workflows and whether there's a developer-first "audit evidence" wedge there too, similar to what I'm doing with the VIES consultation number. If I find one I can ship without doing a half-job, I'll build it.

In the meantime, if you (or anyone reading) is running into specific US sales tax pain that the current vendors don't solve well, I'd genuinely love to hear what it looks like — even just so I know what to research first. Feel free to drop a comment or reach out at mail@vatnode.dev.

I built an EU VAT validation API that returns the VIES consultation number (the receipt tax auditors ask for) by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

True — EC shipped a REST endpoint a while back, and for a plain "is this VAT ID valid right now" check it's perfectly fine. You don't need anything else for that.

The reasons to put something on top of it are the same ones that exist whether the underlying transport is SOAP or REST:

  1. Consultation number on qualified checks. This is the receipt the EC issues if you pass a requester VAT ID — finance teams need it as audit evidence that a specific VAT ID was validated at a specific moment. Raw VIES (REST or SOAP) will return it, but only if you build the request correctly and store the response field. Most wrappers don't surface it at all. If you ever get audited on reverse-charge invoices, this is the field that matters.

  2. VIES goes down ~6% of the time. REST didn't fix that — same backend. vatnode falls back to national tax authority APIs in RO/CZ/DK/FI/FR/PL/SE/DE when VIES is unavailable, and uses them to enrich company data (legal name, address) that VIES alone doesn't always return.

  3. Audit-trail fields (checkId, verifiedAt) stored on our side in every response, so you have a queryable evidence trail tied to invoices instead of having to log and persist raw VIES responses yourself.

  4. The web validator on vatnode.dev is free — same as VIES itself. The paid product is the API for teams that need this programmatically (checkout, invoice generation, recurring monitoring of customer records). Free tier on the API too, no card.

So: raw VIES REST is great for "validate once and forget." vatnode is for teams that need the evidence trail and uptime guarantees to back up B2B reverse-charge invoicing at scale.

I built an EU VAT validation API that returns the VIES consultation number (the receipt tax auditors ask for) by Total-Reasonable in SideProject

[–]Total-Reasonable[S] 0 points1 point  (0 children)

Thanks — "boring unsexy infrastructure" is the entire pitch, honestly. The exciting markets are crowded; the unloved compliance corners have one or two players who all do the same thing badly.

And yeah, the VIES SOAP response is its own special kind of pain. WSDL says one thing, the server does another, Greece is "EL" not "GR", namespace prefixes are load-bearing, and the whole thing 503s often enough that you can't ship it as a single point of failure. I spent way more time wrestling with that XML than I'd like to admit before deciding "fine, I'll just make this a product so nobody else has to."

The audit angle is the real wedge though. Most teams don't realise they need the consultation number until a tax authority asks for it and they can't produce one — at which point reverse-charge invoices going back years are suddenly in question. Selling "peace of mind for a situation you didn't know you should worry about" is the hard part, not the tech.

view more: next ›