🇨🇱 Chile

This sheet assumes you know the xPOS-Core communication protocol. Here we only document what is specific to Chile.

Summary

Aspect	Value
country code	cl
Tax authority	SII
Pattern	A — XML with XSD
Supported inputType	json, xml, xdoc, txt
Output	Tax XML (DTE) signed with TED
Supported flows	Mixed (sync-async) and Asynchronous — see below

🔀 Supported flows

Chile can operate under two integration models. The difference lies in who dialogues with the SII, and it is chosen in the xPOS configuration. From the POS's point of view, the invocation protocol is the same in both models (same endpoint, same parameters, same response structure); what changes is the internal behavior and how the official status is obtained.

To understand the complete choreography with diagrams, see xPOS Global Architecture.

Comparison table

Aspect	Mixed model (sync-async)	Asynchronous model
Who sends to the SII	xPOS Core	Gosocket Cloud
When the official status is known	xPOS Core queries the SII after submission	Managed by the Gosocket cloud
Retries against the SII	Done by xPOS Core	Done by the Gosocket cloud
Echo fields (statusCode, statusDescription, statusMessage) in the initial response	Empty in the first response. Filled in when xPOS Core queries the status.	xPOS Core does not return them (it does not dialogue with the SII).
/api/v1/status	Returns the updated tax status after the xPOS query to the SII.	xPOS Core cannot deliver the final tax status. It is queried directly in the Gosocket Inbox portal, Issued section.

Mixed model (sync-async)

Step-by-step flow:

1. POS → xPOS Core: sends the document (POST /api/v1/process-documents).
2. xPOS Core: validates XSD/Schematron, assigns folio and signs with TED.
3. xPOS Core → SII: delivers the DTE and receives an acknowledge of receipt. The DTE remains in the Inbox without tax status.
4. xPOS Core → POS: responds confirming that the document was accepted for processing.
5. Later: xPOS Core queries the status at the SII and updates the DTE in the Inbox (Issued).
6. POS → xPOS Core: retrieves the official status via GET /api/v1/status.

When to choose it

When the customer wants xPOS to directly control communication with the SII (retry logic, local auditing) and has stable connectivity to the tax authority.

Asynchronous model

Step-by-step flow:

1. POS → xPOS Core: sends the document (POST /api/v1/process-documents).
2. xPOS Core: validates XSD/Schematron, assigns folio and signs with TED.
3. xPOS Core → Gosocket Cloud: delivers the DTE to the Gosocket API and receives an acknowledge from the cloud.
4. xPOS Core → POS: responds and synchronizes the Inbox (Issued).
5. Gosocket Cloud → SII: the cloud sends the DTE asynchronously, manages retries and reconciles the official status.

When to choose it

When the customer prefers not to worry about connectivity with the SII (the cloud manages retries and errors) or when the POS network toward the SII is unstable.

How the model is configured

The selection between mixed model and asynchronous model is defined in the Gosocket administration portal during the customer's implementation stage. xPOS Core receives that flag through the onboarding data: it is not a parameter that travels in each call to /api/v1/process-documents.

XSLT mapping

XSLT	Use
input_to_dte_cl.xslt	json and xml inputs → XML <root> → Gosocket XML.
other_to_dte_cl.xslt	txt input → Gosocket XML. Does not go through input_to_dte.
xdoc_to_dte_cl.xslt	xdoc input → Gosocket XML. Does not go through input_to_dte.
dte_to_fiscal_cl.xslt	Gosocket XML → SII tax DTE.
custom_response_cl.xslt	Generates custom_response when applicable.

Document types (typeDoc)

WebSocket example uses typeDoc=39 (electronic receipt).

typeDoc	Document
33	Electronic invoice
34	Electronic exempt invoice
39	Electronic receipt
41	Electronic exempt receipt
52	Electronic dispatch guide
56	Electronic debit note
61	Electronic credit note

Chile-specific response fields

Chile returns a reduced subset of the core: the SII responds asynchronously in both models, so the initial response never brings the echo fields. The only distinctive thing about Chile is the format of the visual code.

Field	Status	Notes
barcodeBase64	✓	PDF417 in base64 (not QR — Chile uses PDF417 for the TED).
barcodeText	–	Chile does not return the text representation of the PDF417.
countryIdentificationCode	–	Not returned.
statusCode / statusDescription / statusMessage	–	They do not come in the initial response. In the mixed model they are filled in with GET /api/v1/status after the xPOS query to the SII. In the asynchronous model xPOS Core never returns them: the final tax status is queried in the Gosocket Inbox portal (Issued section).
applicationResponse, timeGeneration, timeValidation	–	Same (asynchronous in both models).
contingencyCode	–	Chile does not use contingencyCode in the xPOS Core response.

WebSocket example

Illustrative values. The structure is real; the data are examples. This is the initial response from xPOS Core; it applies to both flows (mixed and asynchronous) and does not bring the SII echo — that status is queried later (see Supported flows).

{
"env": "sbx",
"operation": "consolidate",
"typeDoc": 39,
"country": "cl",
"inputType": "json",
"origin": "<issuer taxId>",
"document": { /* boleta electronica */ }
}

Particular notes

• Signed TED: the response brings the TED (Electronic Document Stamp) signed and embedded in the output.
• Status re-retrieval:
  • In the mixed model, use GET /api/v1/status with transactionId or folio + typeDoc to obtain the updated tax status.
  • In the asynchronous model, xPOS Core cannot deliver the final tax status. The query is made in the Gosocket Inbox portal, Issued section.