The reality of integrating AFIP in 2024
If you are looking for a clean, well-documented integration with maintained official SDKs, AFIP is not what you expect. Argentina's tax authority web services API is a SOAP system from the early 2000s with digital certificates, separate homologation environments, and errors that sometimes have no description.
AFIP web services architecture
For electronic invoicing the relevant services are WSAA (Authentication and Authorization Web Service) and WSFEv1. WSAA gives temporary access tickets that last 12 hours. WSFEv1 receives the XML with invoice data and returns the CAE (Electronic Authorization Code).
The digital certificate: the first obstacle
You need a digital certificate linked to the taxpayer's CUIT. The process: generate an RSA key pair with openssl, create a CSR, upload it to the AFIP portal, and wait for AFIP to issue the certificate. We store the certificate and key as secrets in Coolify and mount them as PEM-format environment variables.
The plugin architecture we chose
We implemented the integration as an independent plugin with a well-defined interface: emitInvoice, queryInvoice, getLastInvoice. Internally the plugin handles authentication, WSAA token caching, XML construction and SOAP communication.
What the AFIP XML doesn't tell you
The FchVtoPago field is required for class B invoices but not class A. Amounts must be sent with exactly two decimal places. Error code 10016 appears when there is a certificate authentication problem, not a date issue as the description says.
WSAA token caching
The WSAA token lasts 12 hours but each call has 300-800ms latency. We cache the token in memory: if it expires in less than 10 minutes, we renew it preemptively. In production, the first invoice issued with a new point of sale must be number 1.