Webhooks

Webhooks allow you to receive real-time notifications about events occurring in Salescaling. When an event occurs, Salescaling will send an HTTP POST 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 a meeting's status. 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 and meeting content processing are performed in parallel, so the meeting_video_done event may be received before the meeting_summary_done event.
• If you want to know when meeting content processing is completed, you can use the meeting_summary_done event.
• If you want to know when notes processing is completed, you can use the meeting_notes_done event.

2. Meeting Note Changes (meeting_note_status_changed)

This event is triggered when there are changes in at least one note of a meeting. 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 of the detected commercial signal. Available types are:

  • Engagement & Intent:

    • buying_intent: Buying intent detected
    • interest_in_trial: Interest in a trial
    • opportunity_qualified: Opportunity qualified
    • 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 competitor comparison
    • competitor_comparison_unfavorable: Unfavorable competitor comparison

  • 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 offering
    • tone_aggressive: Aggressive tone
    • tone_passive: Passive tone
    • speaker_dominates_conversation: Speaker dominates conversation
    • client_drives_conversation: Client drives 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. Available types are:

  • positive: Positive signal
  • risk: Risk signal
  • neutral: Neutral signal

• activityType: Type of activity where the signal was detected. 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 represented by the signal. Available types are:

  • new: New signal detected
  • 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
   • Maintain 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 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 with webhook implementation or have questions about available events, please contact our support team.