Webhooks are event-driven integrations that automatically send real-time data from GetAccept to external systems whenever specific actions occur. Instead of polling the GetAccept API to check for updates, webhooks push notifications to your endpoint when events happen, making your integrations faster and more efficient.

Common use cases include:

You set up GetAccept webhooks yourself. GetAccept Support does not create or manage webhooks for customers. Document webhooks and Deal Room webhooks are set up in different places.
​
​Document webhooks:
Document webhooks are created through the GetAccept API, usually by your developer or by an integration tool such as Zapier. To create a document webhook, choose the event to follow and the URL that should receive it. You can also add an optional payload text that is sent with every event, and a notification email address that is alerted when deliveries fail.
​
Any user can create a personal document webhook. Only an admin can create, change or delete a company-wide document webhook.
​
Document webhooks are changed, deleted and tested through the API too. A test sends a sample event for an existing document to your URL, so you can check that your system receives it. Admins can see document webhooks in GetAccept under Settings › Integrations › Webhooks, when the company plan includes webhooks. The page lists each webhook's event, the receiving host and whether the webhook is Private or Public. Click an event to see its last 50 deliveries. Document webhooks cannot be created or changed on this page.
​
​Deal Room webhooks:
Deal Room webhooks are created in GetAccept. In Deal Rooms, go to Settings › Integrations › Webhooks and click New webhook.
• URL: the address that receives the events. The URL must start with https://. GetAccept checks that the URL can be reached when you save.
• Event: the Deal Room event that sends the webhook.
• Scope: User sends events from the Deal Rooms you have access to. Entity sends events from every Deal Room in your company. Only admins can choose Entity.
• Custom payload (optional): text of up to 2,000 characters that is sent with every event.
• Notification email (optional): an address that is alerted when deliveries fail.
​
Click Create webhook to save. Click a Deal Room webhook in the list to see its delivery logs. A Deal Room webhook cannot be edited. To change a Deal Room webhook, delete it with the bin icon and create a new one. Admins can delete any Deal Room webhook; other users can delete the Deal Room webhooks they created.

​

Each webhook follows one event. You choose the event when you create the webhook.
​

Document webhooks can follow these events:
Created, Sent, Viewed, Reviewed, Opened, Signed, Approved, Expired, Rejected, Partially rejected, Downloaded, Printed, Forwarded, Partially signed, Recalled, Lost, Page tracked, Commented, Hard-bounced, Comment created, Comment resolved and Comment reply created.
​
Each document event includes details about the document and its recipients.
​

Deal Room webhooks can follow these events:
Room visited, Room published, Room unpublished, Task updated, File uploaded, Link clicked, Conversation created, Conversation message created, Meeting created, Milestone updated, Room type updated and Room owner updated.
​

The GetAccept API documentation describes the content of each event.

If your webhook endpoint requires IP whitelisting, GetAccept sends webhooks from a fixed set of IP addresses. See Webhook IP whitelisting for the current list.

GetAccept webhooks cannot send custom HTTP headers, such as an Authorization header, and webhook requests are not signed. To check that a webhook request comes from GetAccept, add a secret value of your own to the webhook URL or to the webhook's payload text, and have your endpoint check that value on every request. Always use a URL that starts with https:// so that events are sent encrypted.

Webhooks are the right choice when you need to push GetAccept event data to a custom endpoint or to a system that isn't a supported CRM. If your goal is specifically to update CRM fields when GetAccept events occur, event-based CRM sync may be a better fit because it can layer in conditions based on CRM data.

With event-based CRM sync, admins can build conditional logic that combines a GetAccept event with CRM field values (such as deal stage, deal value, or any CRM field) to update CRM records only when both the event and the CRM conditions are met. GetAccept reads the live CRM record at the moment the event fires and applies the right update.

For example, when a GetAccept contract is signed:

Event-based sync with CRM field conditions is available for HubSpot, Pipedrive, Upsales, and Microsoft Dynamics 365. Salesforce is not included in this release. If you are routing conditional CRM logic through webhooks today on one of the supported CRMs, you may be able to consolidate that logic back into the native integration.