SAT · Validate RFC

Validating an RFC, from format to the SAT registry.

Try the structural validation free, right here. When you need to know whether the RFC exists at SAT, is active and can invoice, the API answers it in a single call, with a risk level ready for your logic.

Request access → View documentation ›

official SAT statusrisk level per responsezero retention

Technical questions? Talk to an engineer on WhatsApp — 0% bots.

valida-un-rfcFREE · IN YOUR BROWSER

Type an RFC (12 or 13 characters)

Structural validation in your browser — we don't send your RFC to any server. The SAT status is answered by the API.

The API response

Not just "valid": a risk level ready to decide.

Every validation returns the RFC's status in the SAT registry and classifies it into a risk level. Your code uses it directly to approve, flag or stop —no parsing messages.

NONE Valid and invoiceable Exists in the registry and is authorized to issue and receive invoices. Safe for automated approval. type: "SUCCESS" · isBillable: true

LOW Exists, but restricted It's in the registry but can't invoice today —typically a company that hasn't completed its fiscal onboarding, or is suspended. The taxpayer is real. type: "RFC_NOT_INVOICEABLE"

CRITICAL Not registered The RFC is not in the SAT registry: never issued, or a typo or fabricated value. Don't invoice or extend credit without verifying. type: "RFC_NOT_FOUND"

Beyond the risk, the response includes the taxpayer type (individual or legal entity), the isBillable flag and the official SAT message. One switch over the risk level and your onboarding decides on its own.

Raw infrastructure · 100% REST API

One call. Always-live data.

We query SAT on every call, no cache: the status is from this moment, not yesterday's copy. Same envelope as every OrigoID service.

Risk level, not just a data pointNONE / LOW / CRITICAL — your approval logic consumes it directly.

Invalid format = no chargeA malformed RFC is rejected with INVALID_REQUEST and billable: false — you don't spend a credit on junk.

Zero retentionThe query is validated, answered and discarded. Without storing the data, in any region.

View documentation ↗

valida-rfc
          
          
          
        
const res = await fetch("https://api.origoid.com/mex/fiscal/v1/rfc-validations", {
  method: "POST",
  headers: {
    "x-api-key": process.env.ORIGOID_API_KEY,
    "content-type": "application/json",
  },
  body: JSON.stringify({ rfc: "GARM900101HDF" }),
});

const result = await res.json();import os, requests

res = requests.post(
    "https://api.origoid.com/mex/fiscal/v1/rfc-validations",
    headers={
        "x-api-key": os.environ["ORIGOID_API_KEY"],
        "content-type": "application/json",
    },
    json={"rfc": "GARM900101HDF"},
    timeout=30,
)
result = res.json()curl -X POST https://api.origoid.com/mex/fiscal/v1/rfc-validations \
  -H "x-api-key: $ORIGOID_API_KEY" \
  -H "content-type: application/json" \
  -d '{"rfc": "GARM900101HDF"}'Response with the risk already classified
{
  "status": "OK",
  "type": "SUCCESS",
  "data": {
    "rfc": "GARM900101HDF",
    "isValid": true, "isBillable": true,
    "taxpayerType": "PERSONA_FISICA",
    "riskLevel": "NONE",
    "officialMessage": "RFC válido, y susceptible de recibir facturas"
  },
  "billable": true
}

Why OrigoID

The official data is the same. The difference is everything else.

Several providers validate RFC. What changes: how fresh the data is, whether they turn it into a ready decision, and what happens to your counterparty's data afterward.

◈

Always-live dataNo cache: the SAT status is from this very moment. An RFC that changes today, your query today knows it.

⚑

Risk, not just statusNONE / LOW / CRITICAL: the response comes ready for your approval logic, without you parsing SAT messages.

⊘

Zero retentionThe query is validated, answered and discarded. Without storing the data.

Published pricingThe price per validation drops with your volume — all public, no "contact us". See pricing

FAQ

What people usually ask us.

How do I validate an RFC against SAT?

Two levels: the structural validation (12 or 13-character format, date and homoclave) works offline — the demo above does it free in your browser. The real validation against SAT — whether it exists in the registry, is active and can invoice — is answered by the API in a single call.

What does the API response tell me?

Whether the RFC is valid, the taxpayer type (individual or legal entity), whether it can invoice (isBillable) and a risk level: NONE (valid and invoiceable), LOW (exists but restricted) and CRITICAL (not registered at SAT).

Why validate before invoicing or extending credit?

An RFC with perfect format may not exist at SAT or may not be able to invoice. Validating it first avoids SAT rejections and operating with counterparties who aren't who they claim to be.

Do you store the data I validate?

No. Every query is validated, answered and discarded, without storing the data. Zero retention across all our regions.

How much does it cost?

You start free: courtesy credits, no card. Then the price per validation drops with your volume. All plans published. Invalid format = billable: false, no charge.