fiscaliacore

Appearance

Production checklist ​

The list of things to verify before your integration takes its first real fiscal traffic. Some items are technical, some are operational, none are optional if you care about uptime + auditability.

Cert day is the moment customer fiscal data starts moving through your code. Treat the cutover the same way you'd treat a payments cutover — checklist, dry run, rollback plan. — launch posture

Work top-to-bottom. Each step references the underlying API or dashboard surface so you can verify by clicking, not just by ticking.

1. Credentials + identity ​

  1. Production cert is uploaded + valid.
    POST /api/v1/certificates returns 200 with the parsed subject RNC matching your DGII-registered entity. The cert's notAfter is at least 60 days out — if it's closer, rotate now (DGII's CCSD certifier issues new ones in ~3 business days, you don't want to be doing that under deadline).

  2. Two API keys exist, with different labels.
    One in active use by your prod deployment, one ready to roll. Mint via /app/dashboard → Card 2. If you only have one, you can't rotate without downtime.

  3. Onboarding completed — fiscaliacoreTenantId is set on every business.
    Per business: GET /api/v1/businesses/{id} returns a non-null fiscaliacoreTenantId. If null, the business hasn't been provisioned and any e-CF issuance for it will 503.

  4. Subscription is ACTIVE (or you've deliberately decided to stay on Sandbox).
    GET /api/v1/platform/billing/subscription returns status: ACTIVE with a current_period_end in the future. Check the dashboard's Subscription card — Sandbox is fine for evaluation but caps at 100 e-CF/month CERT-only, so production traffic to a real RNC needs a paid tier. If your subscription is PAST_DUE, the API will block on day 8 — update your payment method in PayPal before then.

2. Receiver gateway ​

The wildcard subdomain {rnc}.ecf.fiscaliacore.com is how DGII (and peer emisores) reach you with inbound traffic — ACECFs, inbound e-CFs, semilla validations. If this isn't live, you cannot receive Aprobación Comercial messages.

  1. DNS resolves for at least one of your RNCs.
    dig +short 40209547971.ecf.fiscaliacore.com returns an A record. The wildcard cert covers it automatically.

  2. Inbound test from your laptop reaches the gateway.
    curl -i https://{rnc}.ecf.fiscaliacore.com/fe/recepcion/api/ecf returns 405 Method Not Allowed (correct — POST is the only verb). A 502 or DNS failure means routing isn't live.

  3. Your callback URL is registered and reachable.
    GET /api/v1/receivers/{rnc} returns your registered callbackUrl. Hit it from a non-VPN connection — it must return 2xx to a POST (the body shape is in Webhook v1 docs). If your URL is behind auth, fiscaliacore's Ed25519 signature on every push is your auth.

  4. The HMAC secret has been rotated post-onboarding.
    The initial secret returned at registration is OK for the first 24 hours, but should be rotated via POST /api/v1/receivers/{rnc}/rotate once you've verified your end can verify signatures. Store the new secret in your secret manager, never in code.

Webhook 404 is the most common cert-day surprise. If your callback URL points at a business whose Business row in your DB doesn't exist (RNC typo, deleted, etc.), fiscaliacore pushes an ACECF, you return 404, and the Aprobación Comercial vanishes into a retry queue. Send a dummy ACECF to your callback URL from curl before you go live — 200/204 is the only acceptable response.

3. Quotas + caps ​

  1. You know which tier you're on.
    /reference/pricing lists Developer / Growth / Business / Enterprise. The tier sets your monthly included e-CF count + overage rate. Pick deliberately — overage adds up.

  2. Your soft + hard caps are set to numbers you can sleep through.
    Default: 5× tier price (soft) / 10× tier price (hard). If your traffic is bursty, raise the soft cap so you don't get paged at 3am for a normal spike. The hard cap should still be a circuit breaker, not the operating ceiling.

  3. Cap notifications go somewhere a human reads.
    Soft-cap alerts email your admin address. Pipe that into your incident channel — soft cap means "your bill is doubling, look at this." Hard cap means "your API key just got revoked, look at this RIGHT NOW."

4. Observability ​

  1. Outbound calls are traced.
    Every POST /api/v1/ecf/issue-stateless should emit a span with the e-CF type, the TrackID, and the DGII verdict. If you can't filter your trace store by dgii.estado:RECHAZADO, you can't see your rejection rate.

  2. Inbound webhook deliveries are logged.
    Every POST to your callback URL should land in a log with: source RNC, eCF number, signature-verified verdict, persistence outcome. If your fiscaliacore push retries fire 3 times before you notice, that's an observability gap.

  3. The receiver gateway healthcheck pings every 60s.
    A simple GET https://{rnc}.ecf.fiscaliacore.com/fe/health from your monitoring should return 200. If it goes red, your inbound is down and you'll start losing ACECFs.

5. Operational hygiene ​

  1. On-call docs reference the right URLs.
    The runbook should name api.fiscaliacore.com (your API) and {rnc}.ecf.fiscaliacore.com (your receiver), not the staging URLs you used during integration. Audit your runbook for localhost and cert. prefixes.

  2. The cert renewal date is in someone's calendar.
    DGII-issued certs are typically valid for 12 months. Set a reminder 60 days before expiry. Rotation is POST /api/v1/certificates with the new .p12 — the old one is grace-period-active until the new one's session unlocks.

  3. You have a tested fallback for "fiscaliacore is down."
    If our API is unreachable for > 5 minutes, your customers can't issue e-CFs. The fallback is usually: queue the issuance request internally + retry. Do NOT silently fail the customer's invoice — DGII's contingency rules give you 24h to submit, but only if you've actually stored the intent.

  4. Production environment is switched from CERT to PROD.
    Every EcfIssueRequest carries an environment field. If your prod traffic is going to CERT, you're burning your CERT quota + your e-CFs aren't legally valid. Audit the value at your call site, not at config-load time.

Final dry run ​

Before you flip your traffic over:

  1. From a production-shaped environment, issue an E32 (Consumidor Final, small amount) to a test buyer.
  2. Wait up to 5 minutes for the ACECF push to land at your callback URL.
  3. Verify the ACECF is persisted on your side + the original e-CF's status is Aprobado.
  4. Cancel the test invoice + verify the E34 Nota de Crédito flow.

If all four steps work, you're cert-ready. If any of them fail, the failure mode shows you which checklist section to revisit.

Where to go next ​