Webhooks

Using Webhooks in GovDash

GovDash supports webhooks to seamlessly notify external systems whenever opportunity records are created, updated, or deleted. These webhooks enable real-time synchronization, allowing your team to implement custom logic (such as updating Salesforce, SharePoint, or any external CRM) the moment an opportunity changes.

Webhook Management with Svix

GovDash leverages Svix to manage webhook delivery. Svix handles reliable event dispatching and provides robust observability into webhook activity. We recommend reviewing their documentation to understand how to consume and validate incoming webhook events: https://docs.svix.com/consuming-webhooks

Setting Up Webhooks in GovDash

To get started:

1. Navigate to Settings → Webhooks within GovDash.

2. Under the Webhooks section, you can create and configure new webhooks for your organization by clicking Add New Webhook.

3. After creation, click on the webhook name to:

   • Set up or update endpoint URLs

   • Monitor delivery attempts and event logs

4. If you have existing opportunities you’d like to send webhooks for, use the Send create events for existing for existing opportunities button on the main Webhooks dashboard in GovDash.

Note: You'll need to have a server or endpoint ready to receive these events.

Event Schemas & Consumption

After your webhook is created, GovDash will begin sending events to your configured endpoint. You can view the payload structure (schema) of each supported event in the Event Catalog within the Webhooks Admin Dashboard.

As of July 2025, GovDash supports the following event types:

• v1.opportunity.create

• v1.opportunity.update

• v1.opportunity.delete

Sample Payloads/Schemas

If you’d like to see a sample of the webhook schemas/payloads, we have provided sample files using dummy data below:

Salesforce Webhooks

Important: You will need to configure the Salesforce integration before setting up webhooks for Salesforce. Please see our guide here for steps to configure the Salesforce integration.

Salesforce Bidirectional Sync: Custom Field Setup

To enable seamless syncing between GovDash and Salesforce, your Salesforce instance must include a custom field on opportunity records named:
GovDash_Opportunity_ID

This field acts as a unique identifier that allows GovDash to track and update Salesforce opportunities that originated from GovDash.

Required Configuration

• Field Name: GovDash_Opportunity_ID

• Field Type: Text

• Field Length: 64 characters

• Unique: Yes (should be configured as a unique field)

Why This Field Matters

If you import or sync existing Salesforce opportunities into GovDash, we strongly recommend that you ensure your GovDash_Opportunity_ID field in Salesforce is mapped to externalCRMIdentifier within GovDash. Doing so ensures that when new opportunities are later created via the webhook-triggered processes, GovDash can properly recognize and track changes on those records/opportunities.

Mapping your Salesforce GovDash_Opportunity_ID field to GovDash’s externalCRMIdentifier internal field is done within the Track Salesforce Fields section of the Capture Settings in GovDash. Below is an example of what the field mapping should look like:

Important: Without this field/mapping in place, GovDash will not be able to push changes from Salesforce to GovDash on opportunities that were created within GovDash first.

Setting Up the Receiving Endpoint

GovDash sends webhook events through Svix to a URL you provide. That URL needs to point to something on your end that can receive the event, verify it came from GovDash, and write the data into Salesforce. This is usually called a "middleware" or "integration layer," and it sits between Svix and Salesforce.

If you don't already have something like this, the section below describes the shape of what's needed so you can hand it to your IT team or integration partner.

What the middleware needs to do

At a minimum, the receiving endpoint must:

1. Accept HTTPS POST requests at a public URL.

2. Verify the Svix signature on each request using your Signing Secret, to confirm the payload came from GovDash and wasn't tampered with. (Svix verification docs)

3. Parse the JSON payload and identify the event type (v1.opportunity.create, v1.opportunity.update, or v1.opportunity.delete).

4. Authenticate to Salesforce (typically via a Connected App using OAuth 2.0) and upsert the opportunity record, matching on the GovDash_Opportunity_ID field.

5. Return a 2xx HTTP response quickly so Svix marks the delivery as successful. Anything non-2xx or slow will trigger Svix's retry logic.

Common ways to build it

Most customers use one of these approaches, in rough order of effort:

• Low-code / iPaaS platforms — Workato, Tray.io, Zapier, Make, or MuleSoft can receive a webhook, verify the signature, and push to Salesforce with minimal custom code. Fastest path if your org already uses one of these.

• Salesforce-native — A public Apex REST endpoint or Salesforce Flow's HTTP callout can receive the webhook directly, which keeps everything inside Salesforce but requires Apex skills and careful handling of signature verification.

• Serverless function — AWS Lambda (behind API Gateway), Azure Functions, or Google Cloud Functions are a lightweight custom option. Cheap to run, easy to secure, and the Svix SDK is available in most common languages.

• Custom application — A small service hosted on your own infrastructure. Most flexibility, most overhead.

Validating Requests

You can verify whether incoming payloads came from our systems using the Svix Signing Secret provided within your dashboards:

Need Additional Information?

See the links below for more information on verifying webhooks:

• https://docs.svix.com/receiving/verifying-payloads/how

• https://docs.svix.com/receiving/verifying-payloads/how-manual

• https://docs.svix.com/consuming-webhooks