Which Webhook Integration Is Yours

banca.me has two webhook integrations. They are not two styles of the same thing — they carry different events, verify differently, and each registration endpoint rejects or ignores what belongs to the other.

Which one you use is decided by your product, not by preference.

	BNPL	Real estate
You are	a merchant offering Buy Now, Pay Later	a real-estate partner consuming risk evaluations
Register with	POST /partner/webhook	POST /partner/webhook/subscription
Events delivered	loan_approved	new_lead and pre_approve
Verification	HMAC — bancame-signature	Token — bancame-webhook-secret
Pick events / filters / project scope	No — fixed to loan_approved	Yes
Extra requirement	—	both events need the evaluation module

If you are a BNPL partner

Register with POST /partner/webhook.

This is your route, including for a brand-new integration. The subscription endpoint rejects BNPL partners with 422 ERR_PARTNER_PRODUCT_CANNOT_RECEIVE_WEBHOOKS — unconditionally, even if you only ask for loan_approved. So there is nothing to migrate to and nothing you are missing out on.

Your destination is subscribed to loan_approved and verifies by HMAC. Both are fixed when the destination is created.

• Payload: loan_approved in the Event Catalog
• Verification: Verify HMAC Signatures

The registration body carries only url. Sending eventTypes or filters is ignored, not rejected — you get a 201 and a plain loan_approved destination, which is a quiet way to end up with an integration that is not what you intended.

If you are a real-estate partner

Register with POST /partner/webhook/subscription.

This is the self-service route: you choose which events the destination receives, filter pre_approve by outcome, and scope a destination to a single project. Your destination verifies by token.

Two events are available to you, and they are the same lead at two moments of the funnel:

Event	Fires	Carries
new_lead	the moment the lead is created, before any evaluation	11 identity and contact fields
pre_approve	when that lead's evaluation finishes	the full evaluation, 51 fields

• Which events exist and every field they carry: Event Catalog
• Verification: Verify the Webhook Token

You can build this without writing code

Because the token is a static header rather than a computed signature, any platform with native header authentication can verify it — n8n's Webhook node, Make, Zapier, most API gateways. Point one at your destination URL, set bancame-webhook-secret as the expected header, and you have a working integration with no verification code to maintain.

The BNPL side cannot be wired up this way: an HMAC signature has to be computed over the raw request body, which needs real code.

Both events require the evaluation module; without it the request is refused with a 403 naming the module.

What both share

• Listing and deleting destinations. GET /partner/webhook and DELETE /partner/webhook/{id} behave the same for both. The verificationScheme field on each listed destination tells you which verifier it needs.
• The envelope. Every delivery is { eventId, data }, with no event-type field. See Webhook Event Format.
• Neither shares a verifier. The schemes are documented separately — HMAC for BNPL, token for real estate — because there is no overlap between them. Read only the one for your integration.
• Delivery behaviour. HTTPS destinations only, redirects not followed, and a retry carries the same eventId. Timeouts and retry counts differ per event — new_lead gets 3 seconds and no retry at all. See Best Practices.
• The limit. 10 active destinations per partner. Deleting one frees its slot immediately.

Can one partner have both?

The two integrations are keyed off your product, so in practice you are one or the other. If you genuinely need both, the schemes are per-destination and immutable — you would register separately through each endpoint and run two verifiers, one per destination. Talk to us first.