SDK 4.5.0 — import a customer's own UBL, and send it under their identity

If you run a platform on getpeppr — you send invoices on behalf of your own customers — and you send raw UBL rather than JSON, upgrade. Until this release that combination could not work, whatever you tried.

What was broken

POST /invoices/import only ever compared a document's supplier against your own company. A document issued by one of your sub-tenants was refused with supplier_identity_not_owned, whatever its scheme, whatever its verification state — and registering that sub-tenant changed nothing, because the check never looked at sub-tenants at all.

The refusal said "register the identifier stated in its AccountingSupplierParty EndpointID". That is precisely what a platform has already done. A real integrator followed it, retried five times on a document our own /validate/ubl called conformant, and reasonably concluded that verification was still propagating. It was not. Nothing was going to change.

What you write now

await peppol.invoices.importFile({
  file: ublBytes,
  filename: "invoice.xml",
  to: { peppolId: "9925:BE0314595348" },
  sender: { externalSubTenantId: "your-customer-ref" },
});

sender takes { legalEntityId } or { externalSubTenantId } — one of the two, never both. It is the same field send() has taken since sub-tenant sending shipped; it simply reaches the raw-import path too. Your bytes are still forwarded untouched.

⚠️ The SDK used to drop this field silently. The request body is built field by field, so a sender you passed never reached the network — and the 422 you got back named an identity you had not claimed. Nothing warned you. If you worked around it by calling the endpoint directly, you can come back through the SDK.

Two things to know

The document and sender must agree. If your document states a supplier endpoint, it has to be the sub-tenant's own. getpeppr never rewrites the document you supply, so a disagreement is refused (supplier_identity_mismatch) rather than resolved for you — we will not guess which of the two identities you meant.

A standard key is now refused with 403, not ignored. This differs from POST /invoices, where the field is dropped for standard keys, and the difference is deliberate: on a path whose whole point is that we change nothing about your document, a security field that is read and then discarded is the second defect this release closes.

While you are here

Sending under a scheme with no registry behind it — 9915, which the code list publishes for exactly this purpose — is the clean way to exercise the platform flow without registering a tax number that belongs to someone else. Two things it will not do for you:

• It does not identify a seller on its own. BR-CO-26 still wants a legal registration identifier (BT-30) or a VAT number (BT-31) somewhere in the document. An EndpointID alone is not enough.
• It does not satisfy the Dutch, Danish or Norwegian rules. Those three require a national identifier of their own — for the Netherlands, a KVK or OIN number, and a VAT number will not stand in for it.

Both are network rules, not ours, and both are easier to meet before you build a country leg than after.