Webhooks overview

A webhook lets one application send real-time data to another application when a specific event occurs.

Instead of polling for changes, a webhook pushes data immediately. For example, MSP Manager can send a notification when a ticket is created or updated. Teams often use webhooks to integrate products and keep systems synchronized.

How webhooks work

Webhooks follow a simple request-and-response model:

  1. You create a webhook in MSP Manager and specify:
    • A destination URL, also called an endpoint, in the receiving system
    • One or more event types to monitor
  2. When a selected event occurs, MSP Manager:

    • Sends an HTTP POST request to the destination URL

    • Includes event details in the request body, typically formatted in JSON
  3. The receiving system processes the request and takes action, such as:
    • Creating or updating a record
    • Posting a message
    • Triggering a workflow or automation

This approach allows systems to react automatically and in real time.

Common webhook scenarios

Teams commonly use webhooks to:

  • Send ticket updates to external systems such as CRMs, PSA tools, or custom apps.
  • Trigger workflows or automations in response to events.
  • Keep data synchronized across platforms.
  • Notify third‑party services about changes as they occur.

Because webhooks are event‑driven, they reduce unnecessary API requests and improve efficiency.

Webhook security and signing secrets

Signing secrets allow receiving systems to verify webhook requests and trust the event data they receive.

Signing secrets help ensure:

  • Authenticity: The request comes from the expected source.
  • Integrity: The payload was not modified after sending.
  • Protection against spoofing: Unauthorized systems cannot send fake webhook requests.

How signing secrets work

When you configure a signing secret:

  • MSP Manager generates a signature for each webhook request using the secret and the request payload.
  • MSP Manager includes the signature with the request, typically in an HTTP header.
  • The receiving system:
    • Recomputes the signature using the same signing secret.
    • Compares the computed signature to the signature in the request.

If the signatures match, the receiving system verifies the request as authentic. If they do not match, the receiving system should reject the request.

Related topics