eliDocs
/
API Reference

POST /v1/receive

POST/v1/receive

The inbound side of managed delivery (preview). Parse and validate an inbound document you already hold, and read the invoices that arrive for you over the network. In development, not yet callable.

Receiving has two sides:

  • Parse and validate a document you already hold. POST /v1/receive is a compute convenience: it validates an inbound XML and returns the structured data in one call. No network, no storage.
  • Read what arrives for you over the network. Once you are registered on a network, inbound invoices land in your Beliq inbox, get validated on arrival, and are exposed to you by API and webhook.

POST /v1/receive

Send the raw XML you received; get back the verdict and the parsed invoice. This is validate and parse folded into one call, for the inbound direction. It touches no network and stores nothing.

Request

Header Required Description
Authorization required Bearer <api-key> or X-API-Key.
Content-Type required application/xml

The request body is the raw XML document.

receive.sh
curl -X POST https://api.beliq.eu/v1/receive \
  -H "Authorization: Bearer blq_live_abc123..." \
  -H "Content-Type: application/xml" \
  --data-binary @incoming.xml
Response
{
  "success": true,
  "data": {
    "validationResult": { "valid": true, "format": "ubl", "profileDetected": "peppol", "errors": [], "warnings": [] },
    "parse": {
      "format": "ubl",
      "profileDetected": "peppol",
      "invoice": { "number": "INV-2026-0123", "issueDate": "2026-04-13", "currencyCode": "EUR" }
    }
  }
}

The verdict always comes back. If the document is outside parse coverage, the parse field is omitted and you still get the validation result. A valid: false verdict is a finding, not an error: the call succeeds and reports the rule violations, the same way validate does.

Network receiving

When a partner delivers an invoice to you over the network, Beliq records it, validates it, and makes it available. You do not call an endpoint to receive; you read what has arrived.

Inbound status

An inbound document moves through its own short lifecycle:

Status Meaning Terminal
received A document arrived and was recorded, deduplicated against anything already seen.
validated Beliq validated and parsed it. The verdict is stored on the document.
available Exposed to you by API and dashboard; a transmission.received webhook has fired. yes
failed Ingestion or validation could not complete after retries. Escalated, never silently dropped. yes

A failing validation verdict does not stop a document reaching available: it arrived, and you get it together with its verdict so you can decide what to do. Only a document that cannot be processed at all (a transient engine outage past the retry cap, or an unreadable payload) ends in failed, and its bytes are retained.

Reading inbound invoices

Inbound documents are transmissions with direction: "inbound". Read them with the same tracking endpoints as the outbound side:

GET /v1/transmissions?direction=inbound&status=available
Authorization: Bearer <api-key>

Fetch the stored verdict, the audit trail, and the document itself through the :id sub-resources. The stored verdict is also re-derivable at any time by passing the document back through POST /v1/receive.

Webhooks

Subscribe to transmission.received to be told the moment an inbound invoice becomes available, rather than polling. See Webhooks.

  • POST /v1/send: the outbound side, delivery and status.
  • Test mode: rehearse inbound handling with a blq_test_ key.
  • POST /v1/parse: turn a document you already hold into canonical fields today.