Renter Updated
Overview
·Event key:renter.updatedWebhook triggered when an existing renter record is re-pushed for any reason other than a bare status change. It carries the full client record — contact details, preferences, listings, and messages — the same shape as renter.created, minus third_party_vla_handling, which is only ever included on creation.
Funnel decides between renter.updated and renter.status-change using a heuristic, not an explicit flag from the triggering action: if a status-change event on the renter occurred within about one second of the underlying group-assignment update, Funnel assumes the push was triggered by that status change and sends the smaller renter.status-change payload instead. Any other re-push of the client — for example, editing contact details, adding a message, or changing preferences — sends renter.updated with the full record shown below. The very first push for a given renter always sends renter.created instead of either of these.
Event Payload
What counts as a successful delivery: Funnel treats any 2xx HTTP status code as success — it does not check the response body at all, so returning any content (or none) with a 2xx status is sufficient. If your endpoint returns a non-2xx status or is unreachable, Funnel retries the delivery up to 2 more times (3 attempts total), waiting roughly 60 seconds and then 120 seconds before each retry, so your handler must be idempotent.
This legacy webhook is deprecated. For new integrations, we recommend using the modern webhooks v2 system, which provides:
- Better event structure with consistent formatting
- More granular events for different activities
- A dedicated delivery pipeline — see the Webhooks Walkthrough for what's documented about its delivery behavior
- Enhanced security features