> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.mangopay.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mangopay.com/_mcp/server. # API - May 11, 2026 ## Changed ### Email property per Hook for failed notification alerts Platforms can now set a dedicated email address for each webhook event type. The email address is used to send alerts after: * 25, 50, and 75 consecutive failed notification attempts, to warn you that Mangopay is not receiving a 200 HTTP response from your endpoint * 100 consecutive failed attempts, to notify you that, as a result, the Hook's `VALIDITY` has become `INVALID` and notification attempts have stopped The `Email` property can be set on: * [POST Create a Hook](/api-reference/webhooks/create-hook) * [PUT Update a Hook](/api-reference/webhooks/update-hook) Platforms integrating for the first time **must** set the `Email` proactively to receive these notifications. For existing platforms, Mangopay automatically populates this property with the previously used global email address (provided one was set) **unless and until** you set it proactively on a Hook. This behavior means that your existing alerts are maintained and that there is no impact on new Hooks unless you decide to set the `Email`. Mangopay will continue to set the email automatically, but recommends that you integrate the `Email` property on all new Hooks that you create. The `Email` is also returned on [GET View a Hook](/api-reference/webhooks/view-hook) and [GET List Hooks](/api-reference/webhooks/list-hooks). For all platforms, if the `Email` is not defined on a Hook and is `null` in the API response, the Hook still becomes `INVALID` after 100 consecutive failed notifications but email alerts are not sent. > **Note** > > **Note – Integration depends on date of Production Hook integration** > > If your platform didn't have any `VALID` Hooks in Production on April 2, 2026, then you **must** set the `Email` at creation or update to receive alerts. You can do this via the API directly (for example, using Postman): you can't yet manage the email via the Dashboard. > > For platforms that integrated before April 2, 2026, this change does not impact your existing webhook setup **unless and until** you set the `Email` on a new or existing Hook. > > [Read more about this change](/webhooks#transition-from-default-email-april-2026) **→** --- ## Added ### SCA: Theme parameter to set dark or light mode on SCA redirection When [redirecting a user for SCA](/guides/sca/session#how-to-redirect-a-user-for-sca), you can now add the `theme` to the URL as a query parameter with the value `dark` or `light` (for example, `&theme=dark`) to force the mode of session. Note that if the user changes the mode in the session then their preference is stored as a local cookie for 30 days and takes precedence over the `theme` that you set. Read more about [SCA customization](/guides/sca/factors#customization) **→** --- ## Added ### DateRangeBy property to generate reports based on transaction ExecutionDate You can now generate the `USER_WALLET_TRANSACTIONS` and `COLLECTED_FEES` reports based on the transaction `ExecutionDate` instead of `CreationDate`. The `ExecutionDate` is the date and time that the transaction `Status` became `SUCCEEDED`, which is likely to be more useful for most platforms. Note also that these reports only contain successful transactions. On calls to the [POST Create a Report](/api-reference/reporting/create-report) endpoint for these report types, set the `DateRangeBy` property to `ExecutionDate` to use it for the range specified in the `AfterDate` and `BeforeDate`. If not specified, these Unix timestamps filter by the transaction `CreationDate`. Read more about [reports](/reports) **→** --- ## Added ### Ability to list all recipients regardless of scope The [GET List Recipients for a User](/api-reference/recipients/list-recipients-user) endpoint now accepts the `ALL` and `PAYIN` values for the `RecipientScope` query parameter. This allows retrieval of both `PAYOUT` and `PAYIN` recipients together. The default value for `RecipientScope` remains `PAYOUT`, so existing integrations continue to receive payout recipients only unless another value is specified. By default, results are sorted by `CreationDate` in descending order (`CreationDate:DESC`), but the `CreationDate:ASC` value has also been added to the `Sort` query parameter. Read more about [recipient scopes in the guide](/guides/sca/recipients#recipient-scopes) **→** --- ## Added ### VOP: Dedicated property for suggested name during Recipients check If the Verification of Payee (VOP) check performed on the [POST Create a Recipient](/api-reference/recipients/create-recipient) endpoint returns a `CLOSE_MATCH` result, the name returned by the check is now returned in a dedicated property: `RecipientVerificationOfPayee.RecipientVerificationPayeeSuggestedName`. This allows you to re-register the Recipient with the suggested name if you wish. The data was already returned as part of the `RecipientVerificationMessage`, but a dedicated property makes it easier to parse and use. The `RecipientVerificationPayeeSuggestedName` is not returned on a Payout request, even if the result is `CLOSE_MATCH`. Read more about VOP checks on [Recipients and Payouts](/guides/vop/recipients-payouts) **→**