Getting SAT tax data out of TaxDown Devolución Impuestos

Sign-up asks for an email, then the taxpayer's RFC and SAT password, and the app immediately returns a preliminary result — that flow, described on the app's own store page, tells you where the data lives. None of TaxDown's value sits on the phone. It sits in the SAT's systems: the annual declaration, the issued and received CFDI behind it, the computed favorable balance, and the refund the app then pursues. An integrator who wants that data is really asking for a reliable, consented read of one taxpayer's SAT record, kept current as the refund moves.

So the work we recommend leads with reconciliation, not a one-time dump. A taxpayer files once, but the refund (devolución) changes state for weeks afterward and the Buzón Tributario can post a requerimiento at any point. We build the read around a freshness window that tracks those changes, and deliver it as source you run. The route and the deliverable are below.

What sits behind a TaxDown account

Each row maps to a real surface the app touches through the SAT, named the way taxpayers and the SAT name it.

Authorized routes to the data

Three routes apply here. We arrange the access and consent for whichever one fits, as part of the engagement.

1. User-consented credential read of the SAT portal

The same material TaxDown collects — RFC with the CIEC (Contraseña) — drives an authenticated session against the SAT portal to read declarations, the favorable balance, and refund status. Reachable: most of what a taxpayer sees on screen. Effort: moderate; the session and form flow are the work. Durability: good, since the CIEC is the taxpayer's own stable key. We set up the consented account or a test taxpayer with you during onboarding.

2. SAT mass-download web service (e.firma)

For CFDI in volume, the SAT publishes a documented mass-download service (descarga masiva) that authenticates with the e.firma — the .cer and .key pair plus its password. Reachable: every issued and received invoice for a period, as signed XML. Effort: lower, because the protocol is documented. Durability: high. This is the cleaner path when invoice history is the goal.

3. Authorized protocol analysis of the app's own traffic

Where the app exposes something its backend computes that the portal does not hand back directly — a preliminary estimate, a plan-specific view — we analyze the app's authenticated traffic under your authorization and implement that interface. Effort: higher. Durability: tracks the app's release cadence, so we pair it with a re-check step.

For most briefs we'd anchor on route 1 for the declaration and refund lifecycle and add route 2 when bulk CFDI matters; route 3 fills specific gaps rather than carrying the integration.

What you receive

The headline is code that runs against these surfaces, not a binder.

• Runnable source — Python and Node.js clients for the SAT session, the declaration and refund reads, and the mass-download flow, with retry and back-off handling for the SAT's slow windows.
• A reconciliation runner that diffs saldo a favor and devolución status against the last snapshot, plus webhook-style callbacks you can point at your own queue when a state changes.
• Automated tests covering auth (CIEC and e.firma), an empty-balance taxpayer, a pending refund, and a posted Buzón requerimiento — so a SAT-side change shows up as a failed assertion rather than quietly wrong numbers.
• A normalized schema that flattens CFDI XML and the declaration into stable JSON, so a TaxDown-sourced taxpayer looks the same as any other in your model.
• Then the documentation: an OpenAPI description of the endpoints we stand up, an auth-flow write-up of the CIEC and e.firma chains, and a short data-retention note for the credentials.

A reconciliation pass, in code

Illustrative — field names and shape confirmed during the build, not a published contract. This is the freshness check at the centre of the integration: open a consented SAT session, read the current refund state, and emit only what changed.

def reconcile_refund(taxpayer, snapshot_store):
    # session from the taxpayer's own credentials (CIEC here; e.firma for bulk CFDI)
    sat = sat_session(rfc=taxpayer.rfc, contrasena=taxpayer.ciec)

    actual = sat.get_declaracion_anual(ejercicio=taxpayer.ejercicio)
    # -> { "rfc", "ejercicio", "saldoAFavor", "estatusDevolucion", "fechaActualizacion" }

    prev = snapshot_store.last(taxpayer.rfc, taxpayer.ejercicio)
    moved = (prev is None
             or prev["saldoAFavor"]      != actual["saldoAFavor"]
             or prev["estatusDevolucion"] != actual["estatusDevolucion"])

    if moved:
        snapshot_store.put(taxpayer.rfc, actual)        # keyed on rfc+ejercicio
        emit("refund.changed", actual)                  # downstream queue picks it up

    # buzon notices are pulled the same pass; a requerimiento is its own event
    for nota in sat.get_buzon_tributario(since=prev and prev["fechaActualizacion"]):
        emit("buzon.requerimiento", nota)

    return actual

Keeping refund state fresh

A refund is not a value, it is a lifecycle. The SAT runs an automatic refund path for many favorable balances once a declaration is filed with a CLABE, and the status walks through review before money lands. If you poll on the filing date and stop, you miss the part that matters. We set the cadence against the events that actually move: the declaration once a year, CFDI as they accrue, and the refund and Buzón notices on a tighter loop during the weeks a return is in flight. The reconciliation above keeps that cheap, because a quiet day reads one record and writes nothing.

Consent and the Mexican data rules

Two regimes apply. Mexico's Ley Fintech put open finance on the books — Article 76 obliges financial entities to expose standardized APIs for third-party access. In practice the framework opened with low-risk "datos abiertos" rules (published 2020, per the regulator and tracker sources below) while the transactional-data provisions remain pending; the build does not depend on those unfinished rules, it depends on the taxpayer's own consent to read their record. The CNBV, working with Banxico, is the authority here. Separately, the RFC and SAT credentials are personal data under the LFPDPPP, so we treat them as such: explicit consent for a stated purpose, encryption at rest, access logging, data minimization, and deletion when the work ends. An NDA covers the handling where you need one.

Engineering details we handle

Three things specific to this app that we account for, so they do not surprise you later.

• Two credential types, one session layer. The CIEC reads the portal; the e.firma drives the mass-download service. We build the auth layer to accept either from the consenting taxpayer and route each request to the surface that material can reach, rather than forcing one credential to do both jobs.
• The refund clock, not the filing date. Because the devolución changes state after filing, we design the sync around its lifecycle and the Buzón, with the freshness window set so a status change is reconciled on the next pass instead of waiting for the following tax season.
• Plan tiers change what is visible. The app's FLEX, PRO and Full plans expose different levels of follow-up and advice (the PRO and Full prices are quoted in pesos on the listing). We scope the integration per plan so a feature that only exists on one tier is not assumed everywhere.

How this mapping was built

Drawn from the app's Play Store description and sign-up flow, the SAT's own documentation on the CIEC, e.firma and mass-download service, and current write-ups of Mexico's open-finance framework. Checked against these sources:

• TaxDown Devolución Impuestos on Google Play
• Banco de México — regulation of financial technology institutions
• CNBV open-finance technical and consent guidelines (case study)
• SAT mass download of CFDI with e.firma (FIEL)

Compiled by OpenFinance Lab's interface engineering team, checked 2026-06-02.

Tax apps in the same orbit

Same category, useful when one model needs to cover several Mexican tax tools at once. Listed for context, not ranked.

• Heru — automates monthly and annual SAT declarations for freelancers and Resico taxpayers; holds the same SAT-sourced income and deduction data.
• Fixat — online accountants for individuals, working from the RFC and password to file and keep clients current with the SAT.
• Konta — automated bookkeeping and tax filing for Mexican small businesses, built on CFDI and declaration data.
• ContPAQi — long-standing Mexican accounting software with deep CFDI and electronic-invoicing records.
• Contabilízate — automated accounting for Mexican taxpayers, centred on CFDI and SAT filings.
• Taxfix — guided mobile tax returns; answers-driven filing with advisor support, the same shape of personal tax data.
• Accountable — tax and invoicing for the self-employed, with an in-app advisor over personal tax records.
• Wundertax — online tax-return preparation for employees and the self-employed.
• Keeper Tax — AI-led expense tracking and filing for freelance and contractor income.

Questions integrators ask

Can you reconcile a taxpayer's saldo a favor and devolución status on a schedule, or only on demand?

Both. Refund processing at the SAT moves over days and weeks after a declaración anual is filed, so we usually build a scheduled reconciliation that compares the current saldo a favor and devolución status against the last stored snapshot and only acts on the delta. On-demand pulls are wired the same way for a single taxpayer when you need an answer immediately.

Which SAT authentication material do you build the TaxDown integration against — Contraseña/CIEC or e.firma?

Whichever the consenting taxpayer provides. The CIEC (Contraseña) covers portal-scoped reads of declarations and refund status; the e.firma (.cer plus .key and its password) is what the SAT mass-download web service expects for CFDI in bulk. We design the session layer to take either and store the material encrypted and data-minimized.

Does TaxDown's annual filing cycle mean the integration sits idle most of the year?

No. The declaración anual is once a year, but CFDI accrue all year, the Buzón Tributario can post requerimientos at any time, and a refund can change state weeks after filing. We size the refresh cadence to those events rather than to the filing date, so the freshness window stays tight outside of tax season too.

How do you treat the RFC and SAT credentials under Mexican data-protection law?

As personal data under the LFPDPPP. Credentials are held encrypted, scoped to the consented purpose, logged on access, and retained only as long as the integration needs them. Consent records and an NDA cover the handling where the engagement calls for it.

Interface evidence

Pricing is plain. Source-code delivery starts at $300, billed only after the integration lands and you have checked it; the pay-per-call hosted option carries no upfront fee — you call our endpoints and pay for what you use. Either way the build cycle is one to two weeks, and you bring only the app name and what you need from its data. Tell us the target and the data you want at our contact page.