Repository navigation
feat: Send the request fields the API accepts on wallets, customers and more - #380
Merged
Merged
Conversation
## Context The organization update request of the Lago API accepts `slug` and no longer accepts `webhook_urls`. The client did not send `slug` and still sent `webhook_urls`. ## Description The organization whitelist now sends `slug` when given and never sends `webhook_urls`. This is a breaking change for callers that passed `webhook_urls`: the key is now dropped from the request. `webhook_url` is kept, and `webhook_urls` is still read from the response. An integration spec updates the slug against a live API and restores the original slug afterwards.
## Context The Lago API accepts `account_type` and `external_salesforce_id` on customer create and upsert, but the client dropped both from the request body. ## Description Both keys are now forwarded by `Customer#whitelist_params`, only when the caller passes them. The base hash is not compacted, so adding them there would send `null` on every upsert, which would clear the Salesforce ID and fail the `account_type` enum check on organizations with revenue share. The integration spec now expects the Salesforce ID it sends, and a new example checks that both values are kept when a later upsert omits them.
## Context The Lago API accepts `priority` and `voided_transaction_id` when a wallet transaction is created, but the Ruby client dropped both keys from the request body. Callers could not set the consumption priority of a top-up or void credits from a specific inbound transaction. ## Description Both keys were added to the wallet transaction whitelist. The params are still compacted, so a missing or `nil` value is not sent. A new integration spec checks that the API returns the given priority and that voiding with `voided_transaction_id` creates a voided outbound transaction and lowers the wallet balance.
## Context The Lago API accepts `einvoicing` on billing entity create and update, so FR and DE billing entities can turn e-invoicing on and off. The Ruby client dropped it from the request body. ## Description `einvoicing` was added to the billing entity whitelist used by `create` and `update`. A `false` value is sent, and the key is left out when the caller does not pass it. The unit specs now check the request body. A new integration spec updates `einvoicing` on a dedicated FR billing entity (`ruby-sdk-einvoicing`, created on the first run) and restores the original value.
## Context The Lago API accepts `transaction_priority` on wallet creation to set the priority of the initial top-up transaction, but the shared wallet whitelist dropped it. ## Description `transaction_priority` is now part of the wallet whitelist used by `client.wallets` and `client.customers.wallets`. Unit specs check the request body and integration specs check that the initial inbound transactions get the requested priority.
## Context The specs for a billing entity request without `einvoicing` checked the body with a custom `a_request` block, unlike the other resource specs. ## Description These contexts now stub the request with the exact body and assert the response, as the other resource specs do.
## Context `account_type` and `external_salesforce_id` are sent whenever the caller passes the key, so an explicit `nil` is sent as `null`. No spec covered that case. ## Description A spec now checks that both keys are sent as `null` when the caller passes `nil`.
The CI integration job runs the open-source Lago image, which has no billing entities and no revenue share. Examples tagged :premium now run only when TEST_LAGO_PREMIUM=true.
groyoh
marked this pull request as ready for review
October 29, 2026 08:31
toommz
approved these changes
Oct 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
The Ruby client dropped several request fields that the Lago API accepts, so users had to fall back to raw HTTP calls to set them. The gaps were in wallets, wallet transactions, customers, billing entities and the organization. The organization update also sent
webhook_urls, which the endpoint does not accept.Description
The request params now carry the missing fields, as documented in the OpenAPI spec:
priorityandvoided_transaction_id.transaction_priority, on bothwallets.createandcustomers.wallets.create.account_typeandexternal_salesforce_id. They are sent only when the caller passes them, so an upsert without them does not clear a stored Salesforce ID.einvoicingon create and update.slug.Breaking change: the organization update no longer sends
webhook_urls. The API ignored it, and webhook endpoints are managed through their own endpoints.Unit specs cover each field, and the integration specs for these resources pass against a local Lago API on
main. Theeinvoicingandpartneraccount type examples need a premium license, so they are tagged:premiumand run only whenTEST_LAGO_PREMIUM=true. The CI image is open source, so CI skips them.Fixes ING-772