fiscaliacoreThe DGII pipe your product was going to build.

What fiscaliacore is, exactly ​

A stateless signing + submission bridge between your product and the Dominican Republic's DGII e-Facturación services. You hold the fiscal data (invoices, emisor profiles, .p12 certificates); we sign what you hand us and forward to DGII. You get back the signed XML and DGII's receipt.

                       (1 account per integrator company)
                                      ↓
    [ your product ]  ─────────►  fiscaliacore  ─────────►  [ DGII ]
          ↑                         (stateless)                  ↑
  (your end customers —                                   (the fiscal authority)
   RNC holders, invisible to us)

What it looks like to call us ​

Three lines to issue an e-CF, from session open to TrackID:

# 1. Open a 15-minute signing session with your customer's .p12.
SESSION=$(curl -s -X POST https://api.fiscaliacore.com/api/v1/sessions \
  -H "X-Api-Key: $YOUR_KEY" \
  -F certificate=@customer.p12 \
  -F password=$P12_PASSWORD \
  | jq -r .bearer)

# 2. Issue an e-CF — typed JSON, no XML to build yourself.
curl -s -X POST https://api.fiscaliacore.com/api/v1/ecf/issue-stateless \
  -H "Authorization: Bearer $SESSION" \
  -H "Content-Type: application/json" \
  -d @invoice.json
# { "trackId": "07a3e9...", "estado": "EN_PROCESO", "signedXml": "<ECF>..." }

# 3. Poll for DGII's verdict (or wait for the ACECF push to your webhook).
curl -s https://api.fiscaliacore.com/api/v1/ecf/$TRACK_ID/status \
  -H "Authorization: Bearer $SESSION"
# { "estado": "ACEPTADO", "mensajes": [] }

No XAdES manipulation, no certificate-chain validation, no XSD wrangling, no managing the DGII session token rotation. The form-shape you see above is what you build against — the build-payload sandbox generates it interactively if you'd rather click than type.

Build it yourself? Here's the math. ​

DGII e-Facturación cert is non-trivial. We did it. Here's what's on the receipt:

Our $499/mo Business tier costs less than one week of a senior engineer's salary in DR. We sized it that way deliberately.

Who this is for ​

Companies whose software needs to issue, receive, or approve Dominican e-CFs on behalf of their own customers — POS vendors, ERPs, accounting SaaS, payment processors, anyone who wants a hosted DGII pipe instead of building + certifying one internally.

You are an integrator. Your end-customers (the RNC holders) stay inside your product. They never see fiscaliacore. We only ever see transactions — never a relationship.

What we actually do ​

1. Sign. Open a session with a .p12 + password; we hand back an opaque bearer token good for 15 minutes. Every signing call reuses that token. Keys stay in memory; nothing is written to disk.
2. Submit to DGII. Send us a typed payload (e-CF issuance, RFCE summary, ACECF commercial approval, ANECF cancellation). We build the XML per the official XSD, sign with the session key, POST to the correct DGII endpoint for the right environment, return DGII's response plus the signed XML for your records.
3. Receive from DGII. Your customers' RNCs get mapped to per-tenant subdomains ({rnc}.ecf.fiscaliacore.com). DGII sends inbound e-CFs, ACECFs, and cancellations there; we verify XAdES, forward to your registered callback with an Ed25519-signed envelope, proxy the response back.

Everything else — invoice history, audit logs, customer profiles, billing, retry on outage — lives in your product.

Status — what's live, what's coming ​

What's running in production today (2026-05-25):

See the architecture phase plan for the full refactor timeline.

Pricing in one line ​

Free Sandbox tier (100 e-CFs/month, CERT env only). Paid tiers start at $49/mo for 5,000 e-CFs and step down per-unit as you scale. Hard cap protects you from runaway scripts. Full matrix →

Get started ​