Introducing Webhook Events for Pull Request Scans

In September we introduced Pull Request Stories to help developers understand dependency changes before merging code. Today, we’re taking that one step further with Webhook Events for Pull Request Scans.

You can now automatically receive webhook events for every pull request scan triggered in your repositories. Instead of checking the dashboard or polling our API, Socket can send results directly to your existing tools and workflows in real time.

Each webhook includes the final scan results for a pull request, showing:

• Changed dependencies (added, updated, or removed)
• New alerts triggered by your Security Policy

You’ll only be notified about new issues introduced in the pull request, not existing alerts or those ignored by policy. Each payload also includes direct links to the Socket dashboard and API.

What Are Webhooks?#

Webhooks are HTTP requests sent from one system to another when specific events occur. They allow real-time updates without having to poll APIs or log into a website.

They’re the foundation behind countless integrations, such as calendar notifications in Slack, Jira ticket updates, or GitHub repository activity. Socket already subscribes to webhook events from GitHub to trigger new scans, and now you can receive webhook events from Socket as well.

Automate Your Workflows with Socket Webhooks#

Once your webhook is set up, Socket can send pull request scan results directly to your tools and systems, such as Slack, Jira, or custom CI pipelines. This makes it easy to trigger automated actions or alerts whenever new dependency or security changes are detected.

For example, you could automatically create a Jira ticket when a high-severity issue appears, or post a summary of dependency changes to a team Slack channel. Webhooks make it simple to extend Socket’s visibility into the tools you already use.

How to Set It Up#

If you’re on a Business or Enterprise plan, go to Dashboard → Settings → Webhooks (under “Integrations”) and click Create webhook.

Note: The Create webhook button is only available to organization owners and admins.

Fill out the required fields (name, URL, and signing key) and select at least one event type.
The signing key allows you to verify webhook payloads when received. You can provide your own key or use the "Generate" button to create one automatically. For implementation details, see the documentation.

By default, webhooks are sent for all repositories in an organization, but you can filter to a subset of repositories or add custom HTTP headers under Advanced settings.

Webhook Payload Structure#

Each pull request event payload includes four main object groups and a version field:

• organization – Basic organization info
• pull_request – Details such as author, branches, title, and status
• repository – Basic repository info
• scan – Final scan results including changed dependencies and new alerts

Here's an example that shows the received webhook data:

For the complete schema, visit the webhooks documentation.

Webhooks Roadmap#

Webhook Events for Pull Request Scans are available now for all Business and Enterprise customers.

We’re starting with pull request scans, but more event types are on the way! Webhooks will become a key part of integrating Socket into your workflows, making it easier to automate actions, track changes, and stay on top of your dependency security.