This documents the webhook payload that Host Tools will POST to your configured webhook URL when one of the user's channel payouts is stored, changed or removed.

Note: This is not an API endpoint you call.
This documents the requests that Host Tools sends TO your webhook URL.

When triggered:

• payout.created: Host Tools stored a new payout: a paid Airbnb or VRBO payout, a pending Airbnb estimate, or a Booking.com bank transfer. Also sent when a payout that was deleted comes back.
• payout.changed: a payout Host Tools already had was read again with something different: a booking matched to a row, a pending estimate with new rows, another booking of a Booking.com transfer, or a payout moved to the account that replaced a deleted one.
• payout.deleted: the payout is gone. Usually a pending Airbnb estimate: once Airbnb pays it, it is deleted and the paid payout comes as a new payout.created with its own _id; a cancelled booking also drops it. Also the pending estimates of an account the user deletes. document has deletedAt.

Airbnb and VRBO payouts are read once a day, so their webhooks come together after each day's read; the first read of a newly connected account sends a payout.created for each payout it finds, up to 60 days back. Booking.com transfers come within hours of the transfer.

Each webhook is sent 30 seconds after the payout's last change, with the payout as /api/getPayout/{payoutID} returns it then, so several changes close together arrive as one webhook with the latest data. A payout.changed can still follow right after payout.created with the same payout, and can come when only something Get Payout doesn't return changed. Keep payouts by _id: add or replace on created and changed, drop on deleted, and ignore a payout.deleted for a payout you never had. If you miss webhooks, Get Payouts with updatedSince returns every change since then. OAuth clients only get this webhook with the ownerStatements:read scope.

Handling the webhook:

1. Your endpoint should respond with HTTP 200 status
2. Process the data asynchronously if needed
3. Respond within 30 seconds