Webhooks

Webhooks allow you to receive real-time notifications about events that occur in Salescaling. When an event occurs, Salescaling will send a POST HTTP request to the URL you have configured.

Webhook Configuration

To configure a webhook, you need to provide:

• Webhook name

• Destination URL

• Event type to listen for

• Custom headers (optional)

• Description (optional)

Event Types

We currently support the following event types:

1. Meeting Status Changes (meeting_status_changed)

This event is triggered when there are changes in the status of a meeting. The possible statuses are:

• meeting_created: When a new meeting is created

• meeting_deleted: When a meeting is deleted

• meeting_transcript_done: When transcription is completed

• meeting_summary_done: When the summary is completed

• meeting_video_done: When video processing is completed

• meeting_notes_done: When notes processing is completed

Payload

{
  "meetingId": "string",
  "status": "meeting_created" | "meeting_deleted" | "meeting_transcript_done" | "meeting_summary_done" | "meeting_video_done" | "meeting_notes_done"
}

Notes

• Video processing and meeting content processing are done in parallel, so the event meeting_video_done may be received before the event meeting_summary_done.

• If you want to know when meeting content processing is completed, you can use the event meeting_summary_done.

• If you want to know when notes processing is completed, you can use the event meeting_notes_done.

2. Meeting Notes Changes (meeting_note_status_changed)

This event is triggered when there are changes in at least one note from a meeting. The possible statuses are:

• meeting_note_created: When a new note is created

• meeting_note_deleted: When a note is deleted

• meeting_note_updated: When a note is updated

Payload

{
  "meetingNoteId": "string",
  "status": "meeting_note_created" | "meeting_note_deleted" | "meeting_note_updated"
}

Notes

• This event is triggered once for each note that is processed.

• When notes are generated automatically, this event is triggered for each generated note.

3. Commercial Signal Detection (commercial_signal_detected)

This event is triggered when a commercial signal is detected in an activity. Commercial signals are important indicators that can help identify opportunities or risks in customer interactions.

Payload

{
  "code": "string",
  "description": "string",
  "contactId": "string",
  "companyId": "string",
  "activityType": "string",
  "activityId": "string",
  "evidence": ["string"],
  "changeType": "string"
}

Fields

• code: Code for the detected commercial signal. The available types are:

  • Engagement & Intent:

    • buying_intent: Detected buying intent

    • interest_in_trial: Interest in trying a trial

    • opportunity_qualified: Qualified opportunity

    • champion_detected: Internal champion detected

    • gatekeeper_detected: Gatekeeper detected

    • future_meeting_scheduled: Future meeting scheduled

    • decision_timeline_mentioned: Decision timeline mentioned

    • follow_up_required: Follow-up required

    • follow_up_deadline_mentioned: Follow-up deadline mentioned

    • multi_department_involvement: Multiple departments involved

  • Pricing, Budget & Negotiation:

    • pricing_discussed: Pricing discussed

    • budget_blocker: Budget blocker

    • budget_discussed: Budget discussed

    • discount_requested: Discount requested

    • contractual_concerns: Contractual concerns

    • legal_process_discussed: Legal process discussed

    • renewal_discussed: Renewal discussed

    • upsell_opportunity: Upsell opportunity

    • pilot_success: Pilot success

    • pilot_failure: Pilot failure

  • Fit & Product:

    • product_fit_confirmed: Product fit confirmed

    • usage_feedback_positive: Positive usage feedback

    • usage_feedback_negative: Negative usage feedback

    • technical_validation_passed: Technical validation passed

    • technical_blocker: Technical blocker

    • integration_concerns: Integration concerns

    • training_requested: Training requested

    • feature_request_made: New feature requested

    • security_concerns: Security concerns

    • compliance_concern: Compliance concern

  • Competition:

    • competitor_mentioned: Competitor mentioned

    • competitor_comparison_favorable: Favorable comparison with competitor

    • competitor_comparison_unfavorable: Unfavorable comparison with competitor

  • Risk & Churn:

    • churn_risk: Churn risk

    • no_decision_maker: No decision maker

    • internal_disalignment: Internal misalignment

    • resistance_to_change: Resistance to change

    • escalation_detected: Escalation detected

    • low_engagement: Low engagement

    • deadline_blocker: Deadline blocker

  • Relationship & Communication:

    • positive_feedback_on_demo: Positive feedback on demo

    • negative_feedback_on_demo: Negative feedback on demo

    • rapport_detected: Rapport detected

    • misalignment_on_goals: Misalignment on goals

    • client_asks_many_questions: Client asks many questions

    • client_confused_about_offering: Client confused about the offering

    • tone_aggressive: Aggressive tone

    • tone_passive: Passive tone

    • speaker_dominates_conversation: Speaker dominates the conversation

    • client_drives_conversation: Client drives the conversation

• description: Detailed description of the signal

• contactId: ID of the related contact

• companyId: ID of the related company

• category: Category of the commercial signal. The available types are:

  • positive: Positive signal

  • risk: Risk signal

  • neutral: Neutral signal

• activityType: Type of activity where the signal was detected. The available types are:

  • meeting: Meeting

  • call: Call

  • mail: Email

• activityId: ID of the activity where the signal was detected

• evidence: Array of textual evidence supporting the signal detection

• changeType: Type of change that represents the signal. The available types are:

  • new: Newly detected signal

  • unchanged: Unchanged signal

  • escalated: Escalated signal

  • improved: Improved signal

  • recovered: Recovered signal

Request Structure

Each webhook request includes:

1. Headers:

   • Content-Type: application/json

   • Configured custom headers

   • X-Webhook-Signature: Signature to verify authenticity (coming soon)

2. Body:

   • Defined according to the event type

Best Practices

1. Payload Verification:

   • Implement webhook signature verification (Coming soon)

2. Error Handling:

   • Respond with a 2xx code to confirm receipt

   • Implement retries in case of failures

   • Keep a log of received events

3. Security:

   • Use HTTPS for your endpoint

   • Implement authentication on your endpoint; you can specify a token in the request headers

   • Validate the received data before processing it

Implementation Example

app.post("/webhook", (req, res) => {
  const { type, payload } = req.body;

  switch (type) {
    case "meeting_status_changed":
      handleMeetingStatusChange(payload);
      break;
    case "meeting_note_status_changed":
      handleMeetingNoteStatusChange(payload);
      break;
  }

  res.status(200).send("OK");
});

Limits and Restrictions

• Webhooks have a 10-second timeout

• Up to 3 retries will be performed in case of failure

• The maximum payload size is 1MB

Support

If you need help implementing webhooks or have questions about the available events, contact our support team.