# Three response fields were never guaranteed

`amount`, `currency` and `sending_history.sent_at` leave `required`. No response changes — the contract was promising something the server never did.

Sep 8, 2026 · Improved

Two contract corrections, same shape: fields declared mandatory that the server already omitted. Nothing stops being sent; what changes is what the document promises about it.

If you generated a client from the spec and treated them as mandatory, you were validating against a promise we were not keeping — and you would break on the first row that did not carry them.

## What else changed

- **`amount` and `currency` on a payment event** leave `required` and become nullable. They were already omitted on events that move no money — the catalogue notifications that arrive over the same channel. An event with no amount is not a payment of zero: it is an event that moved no money.
- **`sending_history.sent_at` becomes optional** — optional, not nullable: the field is omitted, never sent as `null`. A sending history records decisions, not only deliveries: an email stopped by policy is listed as `REJECTED`, and one just accepted travels as `QUEUED` while dispatch is asynchronous. Neither has an instant of sending, because no sending happened. It is never backfilled with a clock value.
- **What to do.** Regenerate your client and treat the three as optional. If your integration did not already break, it was tolerating them anyway.

## Endpoints

- `GET /v1/companies/{company_id}/payment-connections/{connection_id}/events` — amount and currency are optional and nullable
- `GET /v1/companies/{company_id}/invoices/{invoice_id}` — sending_history entries may omit sent_at

## Where to go next

- [List payment events](/payment-events/listCompanyPaymentEvents)
- [Sending email](/guides/sending-email)

---

Full OpenAPI spec: https://docs.beel.es/api/openapi