fix(usage): populate lago_invoice_id on customer usage responses

[ayush-sharaf]

Problem

CustomerUsageResponse declares an invoice_id field, but the Lago API returns the invoice identifier under the key lago_invoice_id. Since pydantic drops unknown fields by default, the API value is silently discarded during deserialization, leaving the field permanently null.

This affects both the current_usage and past_usage endpoints. For past_usage in particular, this field is the only mechanism to associate a closed billing period with its invoice, so the bug makes that association impossible.

The mismatch is visible in the existing fixture tests/fixtures/customer_past_usage.json, which already contains lago_invoice_id while the model expected invoice_id.

I verified this against the serializers in getlago/lago-api. All three usage serializers emit lago_invoice_id, never invoice_id:

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

So past_usage is the endpoint that was actually losing data — the server returns a real invoice id that the client silently dropped. current_usage returns nil server-side by design, so it will keep deserializing as None, but now as an intentional, contract-matching field rather than a phantom one.

Fixes #407

Fix

Rename the field invoice_id → lago_invoice_id on CustomerUsageResponse to match the API payload. This mirrors the fix applied to WalletTransactionResponse in #379.

Changes

• lago_python_client/models/customer_usage.py: rename invoice_id → lago_invoice_id.
• tests/fixtures/customer_usage.json: update the current-usage fixture key to lago_invoice_id.
• tests/test_customer_client.py: assert lago_invoice_id is populated for past_usage and present (null) for current_usage.

Testing

pytest tests/test_customer_client.py — 14 passed.

Note

CustomerProjectedUsageResponse (the projected_usage endpoint) has the same invoice_id key mismatch, but per the backend (ProjectedUsageSerializer) the value is hardcoded to nil — so it's a cosmetic/contract-consistency mismatch with no lost data, unlike past_usage. It's outside the scope of #407, so I left it unchanged here; happy to fold in the rename for consistency if you'd like.

🤖 Generated with Claude Code

[cla-check-bot]

Welcome, @ayush-sharaf!

Thanks for your first contribution!

Before we proceed with the review, please sign the Fiduciary License Agreement:

Sign the FLA

Once signed, this PR will be automatically updated.

[cla-check-bot]

Thanks, @ayush-sharaf! 🎉

Your CLA has been signed and is now on file. We'll proceed with the review shortly.

[vincent-pochet]

Thank you @ayush-sharaf for this fix, it looks good.
I merging it in main and it will be part of the next release