Rebill - Inconsistencies in documentation and API responses
Good evening team,
I wanted to let you know these inconsistencies that I found in the first tests that I was doing of the Rebill api and the existing documentation.
1. Incorrect enum in Create Payment Link
In the POST /payment-links endpoint documentation(https://docs.rebill.com/api/reference/payment-links#create-a-payment-link), it states that paymentMethods.methods accepts the values: ('card', 'transfer', 'cash').
However, in the actual responses, the correct value is 'bank_transfer' instead of 'transfer'. The documentation should be updated to: ('card', 'bank_transfer', 'cash').
2. Different response structure in List Plans
The GET /plans endpoint(https://docs.rebill.com/api/reference/plans#list-plans) documents that the response has the structure:
{ "data": [...], "total": 2, "limit": 10, "offset": 0 }However, the actual response has a completely different structure:
{ "records": [...], "pagination": { "totalItems": 3, "totalPages": 1, "currentPage": 1, "itemsPerPage": 10, "hasNextPage": false, "hasPreviousPage": false } }3. Validation error in List Plans
When sending a request to the GET /plans endpoint with the body:
{ "pagination": {...}, "filters": { "status": "active" } }I get the error: "value.map is not a function". This suggests that there is a problem in the validation of the input parameters.
Log in to comment and vote
Comments1
Nahuel Candia
Jul 13
Hi! Thanks for the detailed report — we checked it against the current docs.
paymentMethods.methodsenum: already fixed in the docs, it usesbank_transfer(nottransfer). You may have seen an older version."List Plans" response structure: there's no
GET /plansendpoint that lists plans — the correct one isPOST /plans/search, and its documented response already uses{ records, pagination }, matching what you got. No inconsistency here.value.map is not a functionerror: this isn't a documentation issue. In your request,filters.statuswas sent as a string ("active"), but the endpoint expects an array (["active"]). It should work fine with the array. That said, you're right that the error the backend returns in that case isn't clear — we'll flag it to the team so it returns a descriptive400instead of that internal error.Thanks again for testing this thoroughly, reports like this really help us.