Tax signing, solved.
One API. 5 countries. Zero SDKs.
Manage certificates, sign each document under its country's standard — JWT RS512, XMLDSig, XAdES-EPES or XAdES-BES — and keep the full record.
$ curl -X POST /api/signatures \ -H "X-API-Key: prod_abc..." \ -H "X-Issuer-Id: aB3xKm9pQ2nR" \ -d '{ ... }' // HTTP/1.1 200 OK · 42ms{ "signature": "<?xml version="1.0"?><FE>...<ds:Signature>...</FE>", "document_id": "50601042000310123456700100001...", "document_type": "01" }
Signatures issued
5M+
electronic documents signed to date
Countries live
5
Costa Rica, Dominican Rep., El Salvador, Guatemala and Panama
Guatemala in beta
Encryption at rest
XChaCha20
Poly1305 · never in plaintext
Cache overhead
<50ms
certificates cached, ready to sign
The problem
What you have to solve before issuing your first electronic invoice.
Your country's signing method
Keeping the MH signer running in every installation, or implementing XAdES-EPES, XAdES-BES or XMLDSig by hand against the Hacienda, SAT, DGI or DGII specification. Sello Sign already has it implemented and in production.
Every client's certificate
Storing it encrypted, knowing when it expires, keeping test apart from production. Sello Sign encrypts it with XChaCha20-Poly1305, extracts the tax id and the expiry date on upload, and warns you before it expires.
Knowing what was signed, with what and when
When the authority rejects a document you need the signature, the certificate and the exact moment. Sello Sign stores every operation with its certificate and lets you verify or re-sign it from the dashboard.
Product
Everything heavy about signing for electronic invoicing, in one platform.
The method your country requires. Without implementing it.
XAdES-EPES for Costa Rica, JWT RS512 for El Salvador, XAdES-BES for Guatemala, XMLDSig for Panama and the Dominican Republic. You send the document; the signer applies the method your issuer's authority requires and signs with its active certificate.
- Multiple certificates per issuer and environment
- XChaCha20-Poly1305 encryption at rest
- Per-signature traceability with the certificate used
| Country | Authority | Document | Method | Certificate |
|---|---|---|---|---|
| Costa Rica | DGT | FE | XAdES-EPES | PKCS#12 |
| El Salvador | MH | DTE | JWT RS512 | .crt (MH) |
| Guatemala Beta | SAT | DTE / FEL | XAdES-BES | PKCS#12 / PEM |
| Panamá | DGI | FE / CUFE | XMLDSig | PKCS#12 |
| Rep. Dominicana | DGII | e-CF | XMLDSig | PKCS#12 |
And if you open another country tomorrow, it is the same POST.
Every signature logged. Every error too.
Every electronic invoicing signature is stored with the certificate used, source IP, environment, document type and result. Decode the signed content, re-verify it, or re-sign it from the dashboard — without touching your integration.
- Filters by environment, issuer, type, and result
- Configurable retention per workspace
- Access via API or dashboard
From zero to your first signature.
Four steps and one POST over plain HTTP from your electronic invoicing platform or your ERP: no SDKs to maintain, no libraries to update. Documentation in OpenAPI / Scalar — test the endpoints live in the browser.
- Granular scopes per API key
- RFC 7807 errors (Problem JSON)
- Certificates cached, < 50ms overhead
- 01
Create the issuer
The taxpayer that issues, with its country and tax id.
- 02
Upload its certificate
The MH .crt, or a .p12 / PEM depending on the country. Stored encrypted.
- 03
Generate an API key
Global or per issuer, in the test or the production environment.
- 04
POST to /api/signatures
With X-API-Key and X-Issuer-Id. You get the signature; you send it to the authority.
$ curl -X POST /api/signatures \
-H "Content-Type: application/json" \
-H "X-API-Key: prod_abc123..." \
-H "X-Issuer-Id: aB3xKm9pQ2nR" \
-d '{
"identificacion": { "tipoDte": "01", "codigoGeneracion": "..." },
"emisor": { ... },
"receptor": { ... },
"cuerpoDocumento": [ ... ]
}'Comparison
Official signer, your own build or Sello Sign?
What changes depending on how you solve signing. Verifiable facts only.
| Criterion | Sello Sign | Each authority's official signer | Build it yourself | Enterprise suites (Sovos, Edicom…) |
|---|---|---|---|---|
| Countries covered by one integration | 5 countries | One per country | The ones you implement | Varies by contract |
| Self-hosted / Docker | Yes, free | Yes, e.g. El Salvador's MH signer in Docker | Yes, on your infrastructure | By contract |
| Open source | Yes, AGPL-3.0 | Varies by authority | Your own code | Depends on the vendor |
| Per-signature audit log | Yes | Varies by authority | You build it | By contract |
| REST API with no SDK | Yes | Varies by authority | You design it | Depends on the vendor |
| Price | Free self-hosted; cloud from $0 | Varies by authority | Ongoing development and maintenance | On quotation |
Comparison based on public information at the date of publication. Third-party options vary by country, version and contract.
Pricing
Pay per signature. Or nothing, if you self-host.
Self-hosted is always free: one docker compose up and you sign without limits. The cloud charges only the volume you sign — no per-seat fee, no end-of-month surprises.
Free
Integrate, develop and run a pilot with real clients.
- Up to 3 issuers
- 500 prod signings / month
- 5,000 test signings / month
- 1 team member
- 7-day signature retention
- Community support
Pro
To migrate your first clients to production.
- 10 issuers
- 10,000 prod signings / mo
- 50,000 test signings / mo
- 3 members
- 30-day retention
- Test + production
- 10% grace buffer on your monthly quota
- Global and per-issuer API keys
- Priority email support
Enterprise
For volumes above 750k signings / month or specific requirements.
- Unlimited issuers
- Unlimited signings
- Unlimited members
- Multi-workspace
- Guaranteed SLA
- Dedicated 24/7 support
Prefer your own infrastructure? Deploy Sello Sign with Docker anywhere — no limits, no cost, forever.
View instructions on GitHubSello Sign is a signing platform for electronic invoicing: a REST API that produces the signature each tax authority requires before it accepts a document. It covers five countries — Costa Rica (DGT), El Salvador (MH), Guatemala (SAT, beta), Panama (DGI) and the Dominican Republic (DGII) — and applies the method each one mandates: JWT RS512, XAdES-EPES, XAdES-BES or XMLDSig. It is open source under AGPL-3.0 and you can self-host it with Docker.
No. Sello Sign signs the documents your electronic invoicing platform already generates. Your system builds the document with its data, catalogues and numbering, and sends it to the tax authority; Sello Sign handles only the cryptographic step: it receives the document, applies the signing method of the issuer country and returns the signature. That is why it sits behind invoicing software or an ERP, not in place of them.
Yes, for the signing step. El Salvador is the clearest case: instead of running and updating the MH signer in Docker on every install, you call an API. The same applies in the other countries, where today you would maintain a different library or binary per authority. One integration covers the five countries; sending the document to the authority is still yours.
No. Sello Sign transmits nothing to the authority, and it is neither a PAC in Panama nor a Certificador in Guatemala. It applies the issuer signature to the document and returns it; your system does the transmission and receives the official response. In Guatemala the second signature — the certification one — is applied by a SAT-authorised Certificador, and in Panama the PAC validates the document with the DGI.
No. The sello de recepción is what El Salvador's Ministerio de Hacienda returns when it accepts a DTE, and sello digital is a term from the Mexican CFDI. Sello Sign is a signer: it applies the issuer signature before the document is sent. Sello Sign is the product name, not a kind of tax seal.
The five countries in production, with their document types. Costa Rica: FE, credit and debit notes, electronic ticket. El Salvador: DTE (invoice 01, CCF 03, credit and debit notes and the other MH types). Guatemala: DTE under the FEL regime (FACT, NCRE, NDEB), in beta. Panama: FE with CUFE, including export invoices and notes. Dominican Republic: e-CF (31 tax credit, 32 consumer, notes).
One per country, and Sello Sign picks it from the issuer. El Salvador uses JWT RS512 over the DTE in JSON; Costa Rica uses XAdES-EPES; Guatemala uses XAdES-BES over the DatosEmision node; Panama and the Dominican Republic use enveloped XMLDSig. The difference: XMLDSig is the base XML signature, XAdES-BES adds the signer data, and XAdES-EPES also references a signature policy.
Yes. Sello Sign is self-hosted with Docker and docker compose: you need PostgreSQL, Redis and S3-compatible storage. A self-hosted install exposes the same signing API, signs in the same five countries and has no volume limits and no licence cost. The AGPL-3.0 licence gives you the code and the right to run and modify it.
Every certificate is encrypted with XChaCha20-Poly1305 before it is stored and is decrypted in memory only for the instant of the signature. It is never stored in plaintext and never exposed through the API. Each signature is linked to the certificate that produced it, so the log says which key signed which document. Because the product is open source, you can audit the encryption code.
Any language that speaks HTTP. There is no SDK to install and no library to update: you POST with the X-API-Key and X-Issuer-Id headers. The OpenAPI specification is published at /api/openapi and you can try the endpoints from the browser. Errors follow RFC 7807 (Problem JSON), so your client handles them the same way in every country.
Most integrations are done in under an hour. You create the issuer, upload its certificate, generate an API key and POST the document, in JSON or XML, to /api/signatures. Sello Sign picks the signing method from the issuer's country and returns the signature, the document id and the document type. There are no SDKs to install and no libraries to maintain.
The cloud starts at $0: the free plan includes issuers, production signatures and test signatures every month, enough to integrate and run a pilot. Self-hosted is free forever, with no volume limits. If you leave the cloud, the AGPL-3.0 licence lets you keep running the same software on your own infrastructure; you export your signatures through the API before you go.
Today
Your first signature, in 5 minutes.
Create an account, upload a certificate and POST to the signing API. No credit card, no sales call. Or self-host the signer with Docker today.