Sandbox testing
Three try-it-live utilities live under /app/*. They share a contract:
.p12 and passwords never leave the request. — the sandbox contractThat contract is the whole point. The sandbox is where you verify shapes and signatures before you spend your CERT quota on real DGII submissions. Each utility is independent of the others — sign in, click, get a result, leave.
What "no quota burn" means Free forever
The sandbox utilities never count against your monthly e-CF quota. They do not submit anything to DGII. They run signature math + JSON validation locally (in your browser or in a stateless API call that returns the result and discards everything).
The only sandbox utility that can hit DGII is the postulación signer — and only because DGII requires a signed postulación XML as the very first step of certification. We sign it for you with your .p12; uploading the result to DGII's portal is on you.
Sign Paso 1 postulación XML
What it does: takes DGII's .xml (the one they email you with your Solicitud aprobada notice) + your .p12 cert + your cert password, returns a signed XML you upload back to DGII.
Why you need it: DGII won't issue you a CERT-env identity until you prove you can XAdES-sign with the cert you registered. This is that proof.
How to use it:
Sign in at /app/login and navigate to Dashboard → Sandbox → Sign Paso 1 postulación XML.
Upload your DGII-issued postulación XML (the one with
<postulacion>as root, signed by DGII).Upload your
.p12certificate file. This is your DGII-issued production cert or a CERT-env cert obtained via DGII's preview certifier — fiscaliacore doesn't care which.Enter the cert password. Submit.
Download the signed XML. Upload it to DGII's portal at the URL they emailed you with the
Solicitud aprobada.
Behind the scenes: we unlock the .p12 in memory, XAdES-sign the document inline (enveloped, RSA-SHA256, inclusive C14N), return the bytes, and discard the key + password the moment the response sends. Nothing about the cert or signature is persisted.
If signing fails: the most common cause is a .p12 that's actually a .pfx from Windows certificate export with a non-PKCS#12 wrapper. Re-export with openssl pkcs12 -export from a .pem + .key pair and try again.
Inspect signature New
What it does: paste any signed e-CF / ACECF / ARECF / RFCE XML into a panel, get a verification breakdown on the right — digest match, signing time, cert subject, KeyInfo presence.
Why you need it: when DGII pushes you an ACECF (or another emisor submits an e-CF to your receiver gateway), you want to verify it before persisting. The structural-inspection result tells you what fiscaliacore would do server-side — without you having to spin up a verification call.
How to use it:
Sign in and navigate to Dashboard → Sandbox → Inspect signature.
Paste the signed XML into the left panel. The right panel updates as you paste.
Read the verdict at the top — a green box (everything checks out), an orange box (warnings, e.g. expected signature element absent), or a red box (parse error or structural violation).
The key-value table below lists every parsed attribute: signature algorithm, digest method, canonicalization method, signing time (from XAdES
<SigningTime>if present), KeyInfo subject, RNC extracted from the cert'sSubjectSN, and the digest the document hashes to.
What it does NOT do: cryptographic verification against a trusted cert chain. The structural checks tell you "this document has all the right pieces and they're internally consistent." A full trust-chain verification — does the signing cert trace back to DGII's root CA, is it still valid, is it not revoked — happens server-side when fiscaliacore processes the document on your behalf.
For most "is this XML well-formed and complete" debugging, structural inspection is what you want.
Build payload New
What it does: an interactive form that walks you through composing an EcfIssueRequest payload. As you fill fields, the right panel renders the JSON live + an equivalent curl you can copy and run.
Why you need it: your first integration spike is usually 80% spent on "what does the JSON shape look like." The API reference has the schema; this tool gives you something to actually click on.
Form sections (top to bottom):
| Section | Fields |
|---|---|
| Identification | tipoeCF (e-CF type 31..47 + RFCE), eNCF (auto-generated or paste your own), issuing RNC, environment (CERT/PROD). |
| Issuer | Razón social, sucursal, dirección — the emisor block. Defaults to your org name where we know it. |
| Buyer | Buyer RNC + razón social. For E32 you can leave RNC blank (Consumidor Final). For E46/E47 the foreign-buyer triad activates. |
| Lines | Add up to 5 line items inline — each with cantidad, descripcion, precioUnitario, indicadorFacturacion. Totals compute live. |
| Output | Toggle between JSON, curl, and HTTP — the request body, a one-liner curl with your API key + base URL filled in, or the raw HTTP request including headers. |
The Copy button on each output panel writes to your clipboard.
This builds a request payload, not a submission. Hitting "Copy" gives you a string to paste into your client / IDE / Postman. The form does not POST anywhere. Use it to bootstrap your first integration; once the shape is right, your real client takes over.
When to use each utility
| Situation | Reach for |
|---|---|
| Just got the DGII approval email, need to sign the postulación XML | Sign Paso 1 postulación |
| Received an XML from DGII or another emisor, want to verify it before processing | Inspect signature |
Building your first integration, need to see what an EcfIssueRequest looks like | Build payload |
Debugging a VALIDATION_FAILED from a real e-CF submission | Build payload to round-trip your payload through the schema |
| Want to demo the integration to a customer without involving DGII | All three — they're zero-impact |
Where to go next
- Done sandboxing? → Integration guide walks you through your first real submission.
- Heading to prod? → Production checklist.
- Just exploring? → Dashboard tour gives a guided tour of where everything lives.