Skip to main content
Connect emits seven events. They are delivered to your marketplace’s webhook endpoints, and to the vendor’s if they declared any.

​
Subscribing

Declare your endpoints as you would for any Yabetoo event (see Webhooks), subscribing to the names below.
Subscribe to the bare name, without a prefix. The type carried by the event body is connect.transfer.created, not evt.connect.transfer.created. A subscription to the prefixed form matches nothing.

​
The envelope

accountId designates the CONNECTED ACCOUNT, never your marketplace. It is the vendor the event concerns. Delivery to you is resolved from its controller link.If you route your webhooks by accountId, plan for it: on a connect.* event, it is not your own identifier you will read.

​
The catalogue

Emitted on every successful allocation.data (camelCase): id (ctr_…), controllerAccountId, connectedAccountId, sourceWalletId, destinationWalletId, amount, fee, reversedAmount, currency, availableAt, idempotencyReference, sandboxId, createdAt, updatedAt, account.
data (camelCase): id (ctrr_…), connectTransferId, controllerAccountId, amount, currency, idempotencyReference, sandboxId, createdAt, updatedAt, account.
Emitted when a direct charge is captured.data (camelCase): id (afee_…), controllerAccountId, connectedAccountId, chargeId, intentId, transferId, amount, refundedAmount, currency, feePayer, idempotencyReference, sandboxId, createdAt, updatedAt, account.
It is not emitted when your commission is zero: in pure platform mode, no commission row is written. Its absence does not mean the capture failed.
data (snake_case): account, application_fee (afee_…), refund, amount (what this refund clawed back), refunded_amount (cumulative), currency.Not emitted if the amount clawed back is zero.
Emitted when a credit moves from the pending balance to the available balance. This is the signal to trigger a payout.data (snake_case): account, wallet, amount, currency, source_transaction.
The only signal that the “no credit” policy fired. Without it, you discover the 402 through an unhappy buyer.data (snake_case): account, charge, refund_amount, required, seller_available, marketplace_balance, shortfall, currency.
data (snake_case): account, allocation (ctr_…), required, seller_available, shortfall, currency.
No marketplace_balance here, unlike the refund refusal: on a reversal, your balance is never drawn on.
The casing of data fields is not uniform. Payloads derived from an object (transfer, reversal, application_fee.created) are in camelCase; the other three are in snake_case. Do not assume a single convention: this is a known contract defect, and not one to discover in production.

​
The two events that do not exist

connect.account.created and connect.account.updated are not emitted today. Do not expect a webhook when a vendor is created, nor when its verification state changes: read its state with GET /v1/connect/accounts/{acct} and its compliance with GET /v1/connect/accounts/{acct}/compliance.

​
Delivery idempotence

The two *_blocked_insufficient_funds events have no idempotence anchor: three successive refusals produce three events. That is correct (three refusals did happen), but it differs from the other five. Deduplicate on event.id if your processing is not idempotent.

​
Verification and security

Signature verification and replay rules are common to all Yabetoo webhooks: see Webhooks: overview.