Directory webhook events and payloads
A directory can subscribe to ten events. This page lists when each one is sent and every field in its payload. To create a subscription, see Set up webhooks for your directory in the Help Center. For headers, the signature check and how to reply, see Verify and handle webhook deliveries.
Events
The event name arrives in the X-Event-Type header.
Conventions
- Ids are UUIDs, sent as strings.
createdtimestamps are in UTC, formattedYYYY-MM-DD HH:MM.custom_fieldslists the answers to the custom questions on your form. Each item hasexport_label(the label you gave the field),internal_labelandtext_value(the answer as text; multiple choices are joined into one string). Standard fields such as name and email are not repeated here.- Fields with no value are
null. - We may add fields over time. Ignore fields you do not recognise instead of rejecting the request.
Lead object (contact_request)
Sent inside contact_request_created and contact_request_updated.
contact_request_created
contact_request_updated
Same fields as contact_request_created. state, project_status and, where relevant, the decline or close reason fields carry the new values. For example, after the partner accepts the lead:
When the partner declines, state is declined and decline_reason (with decline_reason_detail) is set. When your team closes the lead, state is closed and close_reason (with close_reason_detail) is set.
matchmaking_request_created
Fields of request_details:
matchmaking_request_updated
Same fields as matchmaking_request_created. For example, after your team assigns the request to two partners:
Each assignment also creates a lead on the partner’s profile, so a contact_request_created event with source set to matchmaking and match_origin set to this request id follows for every partner assigned.
When your team closes the request, state becomes closed and close_reason is set.
partner_application_created
partner_application_updated
Same fields as partner_application_created, plus entry_id and entry_title: the partner profile created when the application is accepted, or null when it is declined. application_details.state is accepted or declined. For example, after an application is accepted:
partner_get_listed_completed
profile_submitted_by_entry_owner
public_profile_changed
Sent when what visitors see on a partner’s profile changes:
- a partner’s edits, once you approve them (approvals on) or as soon as the partner saves (approvals off)
- edits your team makes in the dashboard or through the API, including bulk partner updates (one delivery per partner that changed)
- a partner’s options on filters shown in your directory’s filter bar or on profiles
- a partner becoming visible (public or searchable), being hidden or made inactive, or being removed
Not sent for draft edits, submissions for review, rejections or discarded drafts, for fields visitors never see (internal directory fields, External ID), for edits to a hidden partner, or for saves that change nothing visible. Saves of the same partner a few seconds apart produce one delivery, a few seconds after the save. When you subscribe, PartnerPage records how every partner looks right then, so deliveries start with the next real change.
The payload tells you which partner changed, not what changed. Read the profile again through the public partner read, GET /api/directory/public/v1alpha/directories/{directory_id}/entries/partners/slugs/{entry_slug}/, or remove it from your copy when change is unpublished.
partner_profile_changed
Sent when anything you see about a partner in your dashboard changes, whatever the partner’s status (Public, Searchable, Hidden or Inactive):
- a partner is added to your directory
- a partner’s edits, once you approve them (approvals on) or as soon as the partner saves (approvals off)
- edits your team makes in the dashboard or through the API, including bulk partner updates (one delivery per partner that changed)
- what only your team sets: status, featured, tier, owner organization, External ID, contacts, SEO title and description, the internal description, and whether contact requests are hidden
- a partner is deleted
Not sent for draft edits until they are approved, or for saves that change nothing. Directory-wide changes, such as renaming or deleting a tier, badge, callout, certification, filter or option, changing filter mappings or switching features, reach you with each partner’s next save. Saves of the same partner a few seconds apart produce one delivery, a few seconds after the save. When you subscribe, PartnerPage records how every partner looks right then, so deliveries start with the next real change. Partners added after you subscribe are reported as created.
The payload tells you which partner changed, not what changed. Read the partner again with your API key (read-only keys work) through Get a partner entry, GET /api/directory/private/v1alpha/directories/{directory_id}/entries/partners/{entry_id}/. If you only need what visitors see, subscribe to public_profile_changed instead.