Work / Project 01

C# · React · REST · SOAP · SaaS

La Lista Negra
del SAT

A tax-compliance platform that tells Mexican businesses whether a supplier or customer sits on the SAT blacklist — before an invoice turns into a blocked declaration.

At its best, this project generated the (f-word) impressive revenue of $6.00 USD per user per month; now it's free and can handle tens of thousands of requests per second.

SAT
Blacklist
Daily
Official SAT sync
01 —

Motivation

The problem
Who it is for
Why it had to exist

In Mexico, landing on the SAT’s “lista negra” (Art. 69-B) is not just a reputation hit. If you invoice with a supplier marked as Presunto or Definitivo, those operations can bounce when you file — and your own compliance is suddenly at risk.

The official lists exist, but they are awkward to search, slow to operationalize, and almost useless when you need to check hundreds of RFCs, or do it from inside another system. Accountants, CFOs, and developers were still doing this by hand.

The motivation was simple: make a high-stakes public dataset usable — a search people can trust every day, plus APIs so other software can check before they book the invoice.

02 —

Initial ideas

Product bets
What we built first
What came later
01 · A public search, not a PDF

Start with a web search anyone can use: RFC in, status out. Unlimited lookups on the portal, updated every day from SAT publications.

02 · Meet systems where they already live

Expose both REST and SOAP so modern apps and older ERP / CFDI stacks can query the same source. Ten free API lookups a day; paid bulk for Excel and high volume.

03 · Status is not a yes/no

Surface oficio number, Presunto vs Definitivo vs Desvirtuado, and Diario Oficial dates — the details that actually matter when you decide whether to keep a supplier.

04 · Put the check next to the invoice

A Chrome extension so validation happens in the browser, not after someone has already copied an RFC into a spreadsheet.

03 —

Screenshots

RFC search on the portal
01 · Portal Search
The public RFC search — the first product people actually used, before any API existed.
REST API documentation
02 · REST & SOAP API
Developer surface: REST lookup by RFC and a SOAP endpoint for legacy integrations.
Chrome extension
03 · Chrome Extension
Checking a taxpayer without leaving the browser — the same data, closer to the work.
04 · MCP Data Scanner
An MCP scanner built to validate freshness and ensure the dataset stays in sync with SAT publications daily.
04 —

Lessons & learnings

01

Public data is not a product until you operate it.

The SAT already published the list. The work was reliability: daily ingest, a stable RFC contract, and a result people could act on — not a one-off scrape.

02

SOAP was not optional.

REST was the obvious choice. The paying integrations lived in older stacks. Shipping both APIs was slower; it was also how the product left the demo stage.

03

Trust is the feature.

A wrong “clear” on a blacklisted RFC is worse than downtime. Freshness, validation messages, and showing Presunto vs Definitivo mattered more than extra UI.

04

Self-serve first, bulk later.

Unlimited portal search proved demand. Bulk Excel and higher API limits became a conversation with people who already needed the tool — not a guess at day one.