Have something to say?
Webhooks de producción rechazados con 401
Hola equipo! Necesitamos ayuda para diagnosticar la autenticación de webhooks en producción, porque las requests entrantes no están alineando con el esquema de seguridad documentado. Contexto: Endpoint: https://mercantis.io/api/rebill/webhook Content-Type procesado: application/json Implementamos validación HMAC SHA-256 según docs (x-rebill-signature + secreto compartido) También probamos allowlist de IPs (34.225.22.63, 3.221.139.192) Comportamiento observado: Las requests entrantes no incluyen x-rebill-signature (ni headers equivalentes de firma) IP de origen observada en logs: 52.158.209.200 (fuera de la allowlist documentada) Resultado: 401 en el 100% de los intentos (no es intermitente) Importante: Esta integración venía funcionando correctamente. No rotamos API keys ni cambiamos la URL del webhook. ¿Nos pueden confirmar el contrato de autenticación vigente para webhooks en producción? Si lo necesitan, podemos compartir request IDs y timestamps exactos de entregas fallidas.
Webhooks de producción rechazados con 401.
Hola equipo! Necesitamos ayuda para diagnosticar la autenticación de webhooks en producción, porque las requests entrantes no están alineando con el esquema de seguridad documentado. Contexto: Endpoint: https://mercantis.io/api/rebill/webhook Content-Type procesado: application/json Implementamos validación HMAC SHA-256 según docs (x-rebill-signature + secreto compartido) También probamos allowlist de IPs (34.225.22.63, 3.221.139.192) Comportamiento observado: Las requests entrantes no incluyen x-rebill-signature (ni headers equivalentes de firma) IP de origen observada en logs: 52.158.209.200 (fuera de la allowlist documentada) Resultado: 401 en el 100% de los intentos (no es intermitente) Importante: Esta integración venía funcionando correctamente. No rotamos API keys ni cambiamos la URL del webhook. ¿Nos pueden confirmar el contrato de autenticación vigente para webhooks en producción? Si lo necesitan, podemos compartir request IDs y timestamps exactos de entregas fallidas.
Price not displaying correctly in Dashboard - Products
I was testing the API and found some strange behavior with values in minor units. According to the documentation, the amount field should be sent in cents: amount number Price amount in minor units (e.g., cents). Must be ≥ 0. So I send the value in cents, for example 2120000 to represent $21,200. However, in the dashboard it is displayed as: ARS 2,120,000.00 In addition, the API response confirms that the value is being saved correctly as minor units: "prices": [ { "id": "XXXXX", "currency": "ARS", "isDefault": true, "createdAt": "2025-11-27T19:42:44.329Z", "updatedAt": "2025-11-27T19:42:44.329Z", "amount": 2120000, "amountInCents": 2120000, "amountInUnits": 21200 } ] That is, amountInUnits = 21200, which is correct, but the dashboard interprets amount as if it were already in units, and therefore displays an amount 100 times greater. Could it be that the dashboard is formatting the value in units instead of minor units?
UI error in tariff section
I was reviewing the Rebill fees and I found a small visual bug in mobile, for Argentina it looks fine, but for the rest of the countries the table overflows the container, so the percentages are not visible, here are some screenshots
Clarify identity verification for LLC-type companies
When completing the registration process for an LLC-type company, I encountered a confusing point: in the "beneficiaries" section, it is not clearly explained that each beneficiary must validate their identity from an email sent to their email address in order to complete the registration. I found out by chance when checking my inbox; there was no indication within the panel that this step was necessary. Suggestions: Add an explicit notice indicating that an email will be sent to verify the beneficiary's identity. Display a message such as: "Check your email to complete the identity verification. " Include a visual status (e.g., "pending verification") so that the user knows that the registration is not yet complete.
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.