API Evangelist derivation of Zoopla's Lead Push Service. Zoopla publishes no AsyncAPI document; this document is derived from the published push-service documentation at https://developers.zoopla.co.uk/leads/docs/push-service and binds each event to the message schema already declared in Zoopla's own Swagger 2.0 Leads contract. Nothing here is invented — the channel is the member-hosted endpoint Zoopla POSTs to, the two messages are the documented `applicant` and `appraisal` envelopes, and the security schemes are the two inbound methods Zoopla supports (OAuth 2.0 client credentials against the member's token endpoint, or a static API key sent verbatim as the Authorization header value).
View SpecView on GitHubReal-EstateUnited KingdomProperty ListingsProperty PortalPropTechRentalsEstate AgentsLeadsCRM IntegrationAsyncAPIEventsWebhooks
Channels
leads
The member's configured recipient endpoint. Zoopla sends one HTTP POST per lead. When one endpoint receives both types, the top-level key on the payload distinguishes them.
Messages
✉
applicantLead
Applicant lead
A consumer has enquired about buying or renting a property.
✉
appraisalLead
Appraisal lead
A property owner has requested a valuation.
Servers
https
consumer
The member-hosted endpoint Zoopla delivers leads to. Zoopla is the client here; the host is whatever the member configures with Zoopla, and a single endpoint may receive both lead types or separate endpoints may be configured per type.
asyncapi: 3.0.0
info:
title: Zoopla Lead Push Service
version: '1.0.0'
description: >-
API Evangelist derivation of Zoopla's Lead Push Service. Zoopla publishes no
AsyncAPI document; this document is derived from the published push-service
documentation at https://developers.zoopla.co.uk/leads/docs/push-service and
binds each event to the message schema already declared in Zoopla's own
Swagger 2.0 Leads contract. Nothing here is invented — the channel is the
member-hosted endpoint Zoopla POSTs to, the two messages are the documented
`applicant` and `appraisal` envelopes, and the security schemes are the two
inbound methods Zoopla supports (OAuth 2.0 client credentials against the
member's token endpoint, or a static API key sent verbatim as the
Authorization header value).
contact:
name: Zoopla Member Services
email: members@zoopla.co.uk
url: https://developers.zoopla.co.uk/leads/docs/push-service
x-apievangelist:
generated: '2026-07-26'
method: derived
source: https://developers.zoopla.co.uk/leads/docs/push-service
published_by_provider: false
defaultContentType: application/json
servers:
consumer:
host: 'your-endpoint.example.com'
protocol: https
description: >-
The member-hosted endpoint Zoopla delivers leads to. Zoopla is the client
here; the host is whatever the member configures with Zoopla, and a single
endpoint may receive both lead types or separate endpoints may be
configured per type.
security:
- $ref: '#/components/securitySchemes/memberOAuth2'
- $ref: '#/components/securitySchemes/memberApiKey'
channels:
leads:
address: '/'
description: >-
The member's configured recipient endpoint. Zoopla sends one HTTP POST per
lead. When one endpoint receives both types, the top-level key on the
payload distinguishes them.
servers:
- $ref: '#/servers/consumer'
messages:
applicantLead:
$ref: '#/components/messages/applicantLead'
appraisalLead:
$ref: '#/components/messages/appraisalLead'
operations:
receiveApplicantLead:
action: receive
channel:
$ref: '#/channels/leads'
summary: Receive an applicant lead (a consumer looking to buy or rent).
description: >-
Delivered in real time. Retried for 24 hours if the member endpoint is
unavailable; leads are retained for 30 days in total with no self-service
replay after the retry window. The same lead is also retrievable from
GET /applicant-leads on the Leads poll API.
messages:
- $ref: '#/channels/leads/messages/applicantLead'
receiveAppraisalLead:
action: receive
channel:
$ref: '#/channels/leads'
summary: Receive an appraisal lead (an owner asking for a valuation).
description: >-
Delivered in real time under the same retry and retention rules. Also
retrievable from GET /appraisal-leads on the Leads poll API.
messages:
- $ref: '#/channels/leads/messages/appraisalLead'
components:
messages:
applicantLead:
name: applicantLead
title: Applicant lead
summary: A consumer has enquired about buying or renting a property.
contentType: application/json
payload:
type: object
required: [applicant]
properties:
applicant:
$ref: '../openapi/zoopla-leads-api-openapi.json#/definitions/Applicant'
examples:
- name: applicantLeadExample
summary: Example applicant payload published in the push-service docs.
payload:
$ref: '../examples/zoopla-push-applicant-lead.json'
appraisalLead:
name: appraisalLead
title: Appraisal lead
summary: A property owner has requested a valuation.
contentType: application/json
payload:
type: object
required: [appraisal]
properties:
appraisal:
$ref: '../openapi/zoopla-leads-api-openapi.json#/definitions/Appraisal'
examples:
- name: appraisalLeadExample
summary: Example appraisal payload published in the push-service docs.
payload:
$ref: '../examples/zoopla-push-appraisal-lead.json'
securitySchemes:
memberOAuth2:
type: oauth2
description: >-
Zoopla mints a token from the member's own token endpoint using
grant_type=client_credentials with the client_id and client_secret the
member supplied, then presents it as `Authorization: Bearer {token}`.
Client credentials is the only grant supported.
flows:
clientCredentials:
tokenUrl: 'https://your-token-endpoint.example.com/oauth2/token'
availableScopes: {}
memberApiKey:
type: httpApiKey
description: >-
A static key supplied by the member, sent verbatim as the Authorization
header value with no scheme prefix.
name: Authorization
in: header
Discovery needs no key. Ratings and market analysis are Pro.
Get an API key
Free tier, no form to fill in. Signing in shares your email address with us — we
store it to create your key and to recognise you if you sign in with another
provider. See our Privacy Policy and
Terms.