Consegnare una fattura che il cliente ha ricevuto tramite un canale
- Nella sandbox
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.
apiKeyAuthorizationBearer <token>Inviare la chiave come token bearer: Authorization: Bearer <your-api-key>. Lo stato del servizio è l’unica chiamata che non richiede una chiave.
route*stringIl canale da cui è arrivato il documento.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"rail_id?stringL’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 . _ : / @ + = # -.
^[A-Za-z0-9._:/@+=#-]{1,200}$client?stringIl 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.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$Idempotency-Key*stringUna 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.
8 <= length <= 100body*stringapplication/xmlMemorizzata e messa in coda per il controllo del canale, a meno che non sia già fallito; oppure già presente (duplicate_of).
application/json- 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^rcv_[0-9a-f]{24}$invoice_ref*stringIl numero di fattura del file stesso (BT-1; FA(3) Fa/P_2), altrimenti il rail_id, altrimenti l’id.
invoice_number?stringroute*RouteIl canale di trasmissione. Gli stessi valori di country_route negli eventi di stato.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"client*stringenvironment*string"sandbox""production"state*string"received""validated""validation_failed"direction*"in""in"rail_id?stringL’id del documento presso il canale stesso, come indicato in POST /received.
document_sha256*string^[a-f0-9]{64}$duplicate_of?stringSolo su POST /received, quando il documento era già presente per il cliente e il canale.
links?errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timecurl -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"}Elencare e cercare le fatture ricevute GET
Dalla 0.35.0. Gli stessi parametri e la stessa risposta di GET /invoices, solo per le fatture ricevute; state è received, validated o validation_failed. Una chiave cliente vede quelle del proprio cliente; l’operatore quelle di ogni cliente, oppure quelle di un cliente con client.
Cercare un codice di errore o di motivo GET
Restituisce la voce del catalogo per l’ID di una regola, un codice di errore di un canale o un codice motivo francese (ID e alias).