Docs

Consegnare una fattura che il cliente ha ricevuto tramite un canale

  • Nella sandbox
POST
/received

Dalla 0.35.0 (17 ott. 2026). Il corpo è l’XML esattamente come l’ha consegnato il canale (UBL, CII o FA(3)); nulla viene modificato e nulla viene inviato. Il file viene prima conservato, sigillato con la chiave dati del cliente, perché per legge è già ricevuto; poi i validatori del canale lo controllano, come per un invio pass-through, e il risultato arriva come evento di stato (received, poi validated o validation_failed, con direction: in) sul webhook del cliente e su GET /received/{id}/events. Un file che non supera le regole viene conservato e risulta validation_failed con gli errori; non viene mai scartato. Un file che non è una fattura da conservare viene rifiutato con 422 e non viene memorizzato nulla, come su POST /invoices/xml: un DOCTYPE (EI-XML-DTD, mai analizzato), un XML non ben formato (EI-XML-SYNTAX) oppure un documento che non è una fattura nota al canale (EI-XML-TYPE). Un controllo che non ha potuto essere eseguito (un validatore non raggiungibile) viene ritentato e, dopo l’ultimo tentativo, la fattura passa nell’elenco della Gestione degli scarti e resta received. Un cliente consegna al massimo 120 documenti al minuto e 2.000 al giorno, con qualsiasi chiave (429, non conservato sotto l’Idempotency-Key). Il file viene restituito come download (Content-Disposition: attachment).

Un documento del canale è una fattura ricevuta del cliente: per rail_id quando è indicato, per lo SHA-256 del file quando non lo è. Lo stesso documento di nuovo risponde 202 con duplicate_of; lo stesso rail_id con byte diversi risponde 409 received-id-conflict e non viene memorizzato nulla. Le fatture ricevute sono tenute separate dalle fatture che il cliente invia: non compaiono in GET /invoices, nella serie, nelle metriche né nel rapporto mensile, e non bloccano mai un invio dello stesso file. Una fattura ricevuta viene eliminata con la conservazione dei dati del cliente quando non c’è più nulla di aperto su di essa (il suo controllo è terminato, oppure una persona ha gestito la sua riga della Gestione degli scarti), ed è nell’export del cliente sotto received/. Ambito submit; una chiave cliente agisce solo per il proprio cliente.

Autorizzazione

apiKey
headerAuthorizationBearer <token>

Inviare la chiave come token bearer: Authorization: Bearer <your-api-key>. Lo stato del servizio è l’unica chiamata che non richiede una chiave.

Parametri di query

route*string

Il canale da cui è arrivato il documento.

Valore tra"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"
rail_id?string

L’id del documento presso il canale stesso (l’id del documento dell’access point, il numero KSeF, l’id di download di ANAF). Da 1 a 200 lettere, cifre e . _ : / @ + = # -.

Corrispondenza^[A-Za-z0-9._:/@+=#-]{1,200}$
client?string

Il cliente che l’ha ricevuta. La chiave dell’operatore lo indica (se omesso, il cliente local dell’operatore); una chiave cliente può ometterlo o indicare il proprio cliente, e qualsiasi altro risponde 403.

Corrispondenza^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$

Parametri di intestazione

Idempotency-Key*string

Una chiave univoca per ogni richiesta logica (va bene un UUID). Una chiave che inizia con erp: (la erp:{connector}:{scope}:{entity}:{id} di una ricetta di trasporto ERP, con la chiave dell’operatore o di un cliente) non ha finestra; viene conservata con la sua prima risposta finché il cliente, o la fattura che ha creato, non viene eliminato, così un documento modificato consegnato di nuovo dopo settimane riceve comunque 409 idempotency-conflict. Una chiave simile è accettata solo su un export del connettore ERP (POST /invoices con un connector che questa versione legge, un export che sia un oggetto JSON non vuoto, e con la chiave dell’operatore client); su qualsiasi altra richiesta, un documento canonico, POST /invoices/xml o un annullamento, risponde 400 idempotency-key-not-allowed e non viene conservato nulla, e un export con un numero più lungo di 40 caratteri riceve il 422 EI-SCHEMA che riceve con qualsiasi altra chiave, anch’esso conservato sotto nessuna chiave. Quando l’operatore rilascia una dead letter (la annulla), le risposte precedenti su quella fattura vanno via con essa, quella dell’invio e, dalla 0.35.0, quella di un annullamento rifiutato in precedenza, così un nuovo tentativo di quell’annullamento viene eseguito di nuovo e risponde 200 con la fattura annullata. Dalla 0.32.0 una risposta 5xx e un 422 connector-settings-missing non vengono conservati, così la stessa richiesta con la stessa chiave può essere inviata di nuovo. Con la chiave dell’operatore non può iniziare con client: (400), la forma con cui vengono memorizzate le chiavi dei clienti.

Lunghezza8 <= length <= 100

Corpo della richiesta

body*stringapplication/xml

Corpo della risposta

Memorizzata e messa in coda per il controllo del canale, a meno che non sia già fallito; oppure già presente (duplicate_of).

application/json
  1. response

Dalla 0.35.0. Una fattura che il cliente ha ricevuto tramite un canale, così come l’ha presa POST /received. Come Invoice, non riporta il contenuto della fattura: né venditore, né acquirente, né importi.

id*string
Corrispondenza^rcv_[0-9a-f]{24}$
invoice_ref*string

Il numero di fattura del file stesso (BT-1; FA(3) Fa/P_2), altrimenti il rail_id, altrimenti l’id.

invoice_number?string
route*Route

Il canale di trasmissione. Gli stessi valori di country_route negli eventi di stato.

Valore tra"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"
client*string
environment*string
Valore tra"sandbox""production"
state*string
Valore tra"received""validated""validation_failed"
direction*"in"
Valore tra"in"
rail_id?string

L’id del documento presso il canale stesso, come indicato in POST /received.

document_sha256*string
Corrispondenza^[a-f0-9]{64}$
duplicate_of?string

Solo su POST /received, quando il documento era già presente per il cliente e il canale.

links?
errors?array<>
documents?array<>
created_at*string
Formatodate-time
updated_at*string
Formatodate-time
curl -X POST "https://example.com/received?route=PEPPOL" \  -H "Authorization: Bearer <your-api-key>" \  -H "Idempotency-Key: order-2026-0001" \  -H "Content-Type: application/xml" \  -d 'string'
{  "id": "string",  "invoice_ref": "string",  "invoice_number": "string",  "route": "PEPPOL",  "client": "string",  "environment": "sandbox",  "state": "received",  "direction": "in",  "rail_id": "string",  "document_sha256": "string",  "duplicate_of": "string",  "links": {    "self": "string",    "events": "string"  },  "errors": [    {      "code": "string"    }  ],  "documents": [    {      "kind": "received-xml",      "sha256": "string",      "href": "string"    }  ],  "created_at": "2019-08-24T14:15:22Z",  "updated_at": "2019-08-24T14:15:22Z"}