[BUG]: CustomerUsageResponse.invoice_id is never populated — API returns lago_invoice_id

[ayush-sharaf]

Describe the bug
CustomerUsageResponse declares an invoice_id field, but the Lago API returns the invoice reference under the key lago_invoice_id (see the past usage API reference). Since pydantic ignores unknown keys, lago_invoice_id is silently dropped during parsing and invoice_id is always None.

As a result, usage periods returned by client.customers().past_usage(...) cannot be tied back to their invoices.

Your own test fixture confirms the key name — tests/fixtures/customer_past_usage.json contains "lago_invoice_id": "1a901a90-1a90-1a90-1a90-1a901a901a90" while the model (lago_python_client/models/customer_usage.py, line 76 on current main) declares invoice_id: Optional[str].

To Reproduce

1. Call client.customers().past_usage(external_customer_id, external_subscription_id) for a customer with closed billing periods (each of which has an invoice).
2. Inspect any element of usage_periods.
3. period.invoice_id is None even though the raw API response contains a lago_invoice_id for that period.

Expected behavior
The parsed usage period should expose the invoice id sent by the API (e.g. a lago_invoice_id field, as was done for WalletTransactionResponse in #379).

Support

• lago-python-client: 1.50.0 (still present on main)
• Python: 3.13, pydantic 2.x (via the pydantic.v1 shim)

Additional context
current_usage is affected the same way in principle, but there lago_invoice_id is documented as nullable anyway; for past_usage the dropped field is the only link between a closed period and its invoice.

[ayush-sharaf]

If this is verified as a bug, I'd be happy to work on it — the fix would follow the same shape as #379.

[ayush-sharaf]

Opened #408 to fix this.

I verified the root cause against the backend serializers in getlago/lago-api, and the reported behavior is confirmed — all three usage serializers emit lago_invoice_id, never invoice_id:

Endpoint	Serializer	Key	Value
current_usage	UsageSerializer	lago_invoice_id	nil (hardcoded)
past_usage	PastUsageSerializer	lago_invoice_id	invoice.id (real UUID)
projected_usage	ProjectedUsageSerializer	lago_invoice_id	nil (hardcoded)

So the client's invoice_id field never matched the payload and was silently dropped by pydantic, leaving it permanently null.

The fix renames invoice_id → lago_invoice_id on CustomerUsageResponse, mirroring the WalletTransactionResponse fix in #379.

A couple of notes from the backend verification:

• past_usage is where data was actually being lost — the server returns lago_invoice_id: invoice.id, and that value is now correctly captured. This is the meaningful part of the fix.
• current_usage returns lago_invoice_id: nil by design (the backend hardcodes it), so it will keep deserializing as None — but now as an intentional, contract-matching field rather than a phantom one.
• projected_usage (CustomerProjectedUsageResponse) has the same key mismatch, though its value is also always nil server-side. It's outside the scope of this issue, so I left it out of the PR — happy to include it if you'd like it fixed in the same change.