Discussions

We're automating due-date and overdue reminders on top of the API. For a reminder to reach the same people who received the invoice, we need to read that invoice's recipients.

As far as we can tell there is currently no way to retrieve them via API, even though it's data we wrote ourselves and the web interface displays it without issue in the invoice view, under "Receptor". The practical consequence is having to keep a duplicate recipient list outside the platform, which drifts out of sync as soon as someone edits a recipient in the web app.

Everything below is checked against the OpenAPI spec dated 2026-03-02.

1. The field that holds the recipients is writeOnly

Invoice.contact_email_override is exactly what we need to read:

contact_email_override — "List of destination emails, separated by commas."
type: string, maxLength: 200, writeOnly: true

We can write it when issuing or sending, but the API never returns it.

2. The contact returned by the invoice detail also has its email as writeOnly

This second point looks more like a spec mistake than a deliberate decision.

GET /invoices/{id} responds with InvoiceResponse, described as "Invoice object as returned by V2 API with nested objects". That schema redefines the contact property to point to ContactInInvoice, whose own description is "Contact object as it appears in invoice responses" — i.e. a schema that by its own definition describes a response. And yet its email field is marked:

email — "An e-mail address for the contact point. ID: BT-58", writeOnly: true

The result is that GET /invoices/{id} returns the contact block with no email. We've confirmed this behaviour against the live API.

What stands out is that the sibling schema InvoiceContactHash — the one used by the invoice list endpoint — does expose a readable email, with the same description and the same BT-58 reference. The same piece of information is readable on one endpoint and not on the other.

Is this intended? If not, would it be possible to drop writeOnly from ContactInInvoice.email, and/or expose the invoice recipients (contact_email_override, or an equivalent read-only field) in the invoice detail response?

Thanks.