Sally AI Webhook Integration: The Complete A-Z Guide

With webhooks, Sally can instantly send data to other tools as soon as something happens — for example, sending a meeting summary directly to your automation platform the moment it's ready.

This guide explains webhooks from scratch and walks you through a complete example.

Quick Navigation

1. What is a webhook (simple explanation)?
2. Prerequisites
3. Create a webhook URL in your tool
4. Create a webhook in Sally
5. JSON body & field reference
   • 5.1. JSON example (copyable)
   • 5.2. Explanation of all JSON fields
6. Check connection & view logs
   • 6.1. Test the connection (the fastest first check)
   • 6.2. Understanding logs: what they show – and why they matter
   • 6.3. How to find webhook logs in Sally
   • 6.4. How to read a log entry correctly
   • 6.5. Reexecute logs (targeted testing & debugging)
   • 6.6. Common issues & quick fixes
7. Execute Webhook manually
8. FAQ & Troubleshooting

1. What Is a Webhook and How Does It Work?

A webhook is essentially an internet address (URL) provided to you by another tool or system (e.g., Zapier, Make, n8n, Power Automate, or your own backend).

Whenever something specific happens in Sally — for example, when a summary is created — Sally automatically sends a POST request to that URL.

Comparison:

• API = you actively request data from another system.
• Webhook = the system automatically sends you data when something happens.

Typical webhook use cases:

• Automatically send summaries to an automation platform
• Create tasks in your workflow tools (Zapier, Make, n8n, Power Automate)
• Trigger backend actions when a meeting ends

---

2. What Are the Prerequisites?

To connect Sally to another tool via webhook, you need:

• Access to the target tool
  Example: Zapier, Make, n8n, Power Automate, or a custom backend.

  info

  Without an account in the target tool, you cannot create a webhook endpoint.

• Permission to create or access a webhook URL
  This URL always comes from the target tool.

  • In tools like Zapier, Make, n8n, Power Automate → you find it inside the workflow setup.
  • In custom systems → developers usually provide it.
  info

  Check whether your role (e.g., “Admin” or “Owner”) is allowed to create webhooks.

• A Sally account with integration permissions

  • Personal webhooks: Always available
  • Organization-wide webhooks: Only with the right permissions

Important

The webhook URL always comes from the target system — never from Sally.
Without it, Sally has nowhere to send data.

---

3. How Do You Create a Webhook URL in Your Tool?

The steps differ depending on your system but the principle is always the same:

1. Open your target tool (e.g., Zapier, Make, n8n, Power Automate, custom system).
2. Create an incoming webhook (sometimes called “Listener URL”, “Trigger URL”, or “Endpoint”).
3. Copy the generated Webhook URL.

Tip

If unsure, search your tool's documentation for “create webhook” + tool name.

---

4. How Do You Create a Webhook in Sally?

Once your target tool has generated a webhook URL, you can configure it in Sally. The new webhook integration gives you full control over authentication, headers, and the webhook body.

Step-by-step

1. Open Settings.

Open Settings

2. Go to "Integrations"
3. Click "+Add integration" in the section that matches your use case.

Personal vs. Company-wide Webhooks

Sally distinguishes between personal and company-wide webhooks. The scope depends on where you create the integration:

• "Your personal integrations": The webhook only triggers for meetings of the user who created it.
• "Integrations (Company)": The webhook triggers for all meetings across the entire company account.

Choose the right section depending on whether the webhook should apply to you personally or to the whole organization.

Add Integration

4. Choose Webhook V2 → click Create Webhook

info

Webhook V1 is an older version. Existing V1 webhooks remain active. All new webhooks use V2.

Select Webhook V2

5. Fill out the Webhook form

Save Webhook

Below is a table showing all available form fields and what each one does.

Webhook Form - all Fields Explained:

Field	Description
Webhook Name	A freely selectable display name for the integration. Helps you identify the webhook later (e.g., “Webhook n8n – Leads”, “Zapier – Tasks”).
Webhook URL	The endpoint URL provided by the target system where Sally will send the webhook data. Without this URL, the webhook cannot be triggered.
Cookie (optional)	Optional field for systems that use session cookies instead of API tokens. Modern tools like Zapier, Make, or n8n do not require a cookie. Only used for specific internal or legacy systems.
Authentication Method	Defines how Sally authenticates with the target system. Possible options: • None – No Authorization header is sent; ideal for open listeners or test endpoints. • Basic Auth – Sally sends username + password as a Basic Auth header; commonly used in internal APIs. • Raw – You manually provide the full Authorization header (e.g., Bearer xyz123, ApiKey abc123). • Client Certificate (PFX + Password) – Enables mTLS authentication; only required if the target system explicitly demands a client certificate.
Custom Headers	Allows adding any additional headers, such as x-api-key, x-tenant-id, or signature keys. Used to secure requests or control workflows.
HTTP Body Version	Defines the structure of the JSON body. Recommendation: always choose the latest version to receive the most complete and up-to-date data.
Language	Defines the language in which content is generated. Sally uses BCP-47 based on ISO 639-1. For example, de-DE or en-US will be sent.
HTTP Body Customization	Defines which content Sally includes in the webhook body. Each category can be enabled or disabled individually. The following elements are available: • Tasks – All detected tasks including assignees and due dates. • Custom Insights – Results from custom insights (e.g., checklists or custom fields). • Objections – Detected objections from the conversation. • Decisions – All decisions made during the meeting. • Key Points – Important core topics or main statements of the meeting. • Meeting-type-specific elements – Content generated from the selected meeting type (e.g., question catalog). • Transcription – Full transcript sections including speakers, timecodes, and emphasis. • Summary – The generated main summary as well as HTML variants. By enabling/disabling these fields, you can precisely control how detailed the webhook body should be.

6. Click Create

Your webhook now appears in the list.

Webhook is active

---

5. JSON Body & Field Reference

While configuring your webhook, Sally shows you a live preview of the JSON that will be sent.

You can copy the JSON directly using the built-in Copy button - useful for n8n, Make, Zapier, or testing endpoints.

JSON Body

The payload includes all detected meeting data: attendees, topics, decisions, tasks, objections, meeting-type items, and transcript parts.

Below you find:

1. A complete copyable JSON example
2. A full field reference table

5.1 JSON example (copyable)

{
  "directoryId": "00000000-0000-0000-0000-000000000001",
  "recordingSummaryId": "00000000-0000-0000-0000-000000000001",
  "languageCode": "string",
  "appointmentDate": "0000-01-01T00:00:00.000Z",
  "appointmentSubject": "string",
  "attendees": [
    {
      "name": "string",
      "email": "string",
      "invitationStatus": 0,
      "attendenceStatus": 0
    }
  ],
  "meetingUrl": "string",
  "meetingPlatform": "webex|msteams|zoom|googlemeet",
  "summary": "string",
  "combinedFullSummaryHTML": "string",
  "topics": [
    {
      "summary": "string",
      "description": "string",
      "startTimeStamp": 0.0,
      "endTimeStamp": 0.0
    }
  ],
  "decisions": [
    {
      "summary": "string",
      "description": "string",
      "startTimeStamp": 0.0,
      "endTimeStamp": 0.0
    }
  ],
  "tasks": [
    {
      "subject": "string",
      "description": "string",
      "responsiblePersonName": "string",
      "responsiblePersonEmail": "string",
      "dueDate": "0000-01-01T00:00:00.000Z"
    }
  ],
  "objections": [
    {
      "objection": "string"
    }
  ],
  "customInsights": [
    {
      "id": "00000000-0000-0000-0000-000000000001",
      "name": "string",
      "result": "string"
    }
  ],
  "meetingTypeItems": [
    {
      "summary": "string",
      "description": "string"
    }
  ],
  "transcriptParts": [
    {
      "id": "00000000-0000-0000-0000-000000000001",
      "speakerName": "string",
      "startTimeStamp": 0.0,
      "endTimeStamp": 0.0,
      "text": "string",
      "emphases": "string",
      "sortOrder": 0
    }
  ]
}

5.2 Explanation of all JSON fields

Field Name	Type	Description
directoryId	string (GUID)	Unique ID of your Sally organization. Used to identify which workspace the webhook originates from.
recordingSummaryId	string (GUID)	Unique ID of the generated summary. Can be used to fetch or match data later.
languageCode	string	Language in which the summary was generated. Sally uses BCP-47 language codes based on ISO 639-1, e.g., de-DE, en-US, fr-FR.
appointmentDate	string (ISO date)	Date and time of the meeting or recording.
appointmentSubject	string	Title or subject of the meeting (from the calendar or manually provided).
attendees	Array	List of all meeting participants.
attendees[].name	string	Name of the participant.
attendees[].email	string	Email address of the participant.
attendees[].invitationStatus	number	Numeric invitation status indicating how the person responded to the calendar invite. Possible values: 10 = Declined, 20 = Accepted, 30 = Tentatively accepted, 40 = No response, 50 = Organizer, 100 = Unknown
attendees[].attendenceStatus	number	Numeric attendance status indicating whether the person actually attended. Possible values: 10 = Did not attend, 20 = Attended, 100 = Unknown
meetingUrl	string	Link to the online meeting (Teams, Zoom, Webex, etc.).
meetingPlatform	string	Platform on which the meeting took place (webex, msteams, zoom, googlemeet).
summary	string (Markdown)	Compact main summary of the meeting.
combinedFullSummaryHTML	string (HTML)	Full formatted summary in HTML, ideal for CRMs, ticketing systems, or emails.
topics	Array	Topics/sections detected in the conversation.
topics[].summary	string (Markdown)	Short description of the topic.
topics[].description	string (Markdown)	More detailed description of the conversation section.
topics[].startTimeStamp	number (decimal)	Start time of the topic in seconds (relative to the recording).
topics[].endTimeStamp	number (decimal)	End time of the topic in seconds.
decisions	Array	All decisions made in the meeting.
decisions[].summary	string (Markdown)	Short description of the decision.
decisions[].description	string (Markdown)	Detailed description of the decision.
decisions[].startTimeStamp	number (decimal)	Timestamp when the decision was mentioned.
decisions[].endTimeStamp	number (decimal)	Timestamp when the decision topic ended.
tasks	Array	Tasks/action items detected by Sally.
tasks[].subject	string (Markdown)	Title of the task.
tasks[].description	string (Markdown)	Description or context of the task.
tasks[].responsiblePersonName	string	Person responsible for the task.
tasks[].responsiblePersonEmail	string	Email of the responsible person.
tasks[].dueDate	string (ISO date)	Due date of the task in ISO 8601 format. Only set if Sally detects a date in the conversation. Example: 2025-03-15T00:00:00.000Z
objections	Array	Objections or concerns mentioned during the meeting.
objections[].objection	string (Markdown)	The formulated objection.
customInsights	Array	Results of your custom insights/prompts.
customInsights[].id	string (GUID)	Unique ID of the custom insight field.
customInsights[].name	string	Name of the insight field.
customInsights[].result	string (HTML)	Result generated by the prompt.
meetingTypeItems	Array	Content generated by your selected meeting type (e.g., questions, sections, checks).
meetingTypeItems[].summary	string (HTML)	Short description of the item.
meetingTypeItems[].description	string (HTML)	Detailed description of the meeting-type element.
transcriptParts	Array	Each recognized transcript segment, structured by speaker and time.
transcriptParts[].id	string (GUID)	Unique ID of the transcript segment.
transcriptParts[].speakerName	string	Name of the speaker.
transcriptParts[].startTimeStamp	number (decimal)	Start time of the segment in seconds.
transcriptParts[].endTimeStamp	number (decimal)	End time of the segment in seconds.
transcriptParts[].text	string	Spoken content.
transcriptParts[].emphases	string	List of detected emphasized words within the segment. Contains an array of objects with the emphasized word and its start/end timestamps. Example: [{“word”:”Yes”,”startTime”:104.89,”endTime”:104.89}]
transcriptParts[].sortOrder	number (int)	Sequential number indicating the order of the segment in the full transcript. Ascending: lower = earlier, higher = later.

---

6. Check connection & view logs

In this section, you will learn:

• How to test your webhook connection
• What log entries are and what they mean
• Where to find webhook logs
• How to interpret log entries correctly
• How to reexecute log entries
• How to troubleshoot issues effectively

6.1. Test the connection (the fastest first check)

Before diving into logs, you should first verify that your webhook connection works in general.

To test the connection in Sally:

1. Go to Integrations.
2. Open your previously created webhook integration.
3. Click Test.

Test webhook connection

4. Now select a meeting that will be used as the basis for testing the connection.
5. Click Test.

Select a test meeting

Sally sends a test event to the configured webhook URL and immediately shows whether the target system accepted the request.

Note on test mode in the target system

If you are using a test or sandbox URL in your target system (e.g. n8n, Zapier, or custom APIs), make sure that test mode is enabled there.
Many systems ignore or block test webhooks unless the workflow is explicitly set to “Listening” or “Test”.

The connection test is ideal for quickly checking:

• whether the URL is correct,
• whether the target system is reachable,
• and whether basic authentication works.

6.2. Understanding logs: what they show – and why they matter

Sally automatically records every webhook execution.
You can view, analyze, and reexecute these log entries at any time.

In short: Logs show exactly what Sally sent, when it was sent, and how the target system responded.

Logs help you with:

• verifying that events were triggered correctly,
• troubleshooting incorrect URLs or missing permissions,
• inspecting the transmitted data (payload),
• analyzing response times and performance,
• maintaining technical traceability (e.g. for audits or support cases).

In addition, you can reexecute individual log entries without triggering a new meeting or event.
This is especially useful for debugging or after making changes in the target system.

6.3. How to find webhook logs in Sally

To access the logs of a webhook integration:

1. Open Integrations.
2. Locate your webhook integration under "Your personal integrations".
3. Click Logs.

Open logs for a webhook integration

You will then see an overview of all webhook executions:

Overview of all webhook requests

Each entry represents a single webhook execution attempt sent by Sally to your target system.

6.4. How to read a log entry correctly

A single log entry contains multiple pieces of information that together provide the full context:

Label	Description	Example
Execution time	The moment when Sally triggered and sent the webhook to the target system. Useful for correlating events with meetings or workflow steps.	Jan 12, 2026, 10:01
Target endpoint (URL)	The exact URL the webhook was sent to. Important when working with test, staging, and production environments.	https://example.com/webhook
HTTP status	Response code returned by the target system. Indicates whether the request was accepted, rejected, or failed.	202 Accepted
Latency / duration	Time between sending the request and receiving the response. High values may indicate performance or network issues.	850 ms
Event	The specific Sally event that triggered the webhook, e.g. after a meeting ended or a summary was created.	Meeting completed
Retries	Shows how many times the webhook was manually reexecuted for this entry. You can manually reexecute failed webhooks from the logs at any time.	2
Request & response details	Full technical details including headers, payload, and response body. Essential for in-depth debugging.

Common HTTP status codes

• 2xx (Success) → The target system accepted the request
• 4xx (Client error) → Usually a configuration issue (e.g. 401 Unauthorized, 404 Not Found)
• 5xx (Server error) → The target system was temporarily unavailable. You can manually reexecute the webhook from the logs

6.5. Reexecute logs (targeted testing & debugging)

Reexecuting a log entry is especially useful if:

• You changed the webhook URL
• Updated authentication or headers
• The target system was temporarily unavailable

What happens when you reexecute a log?

When you reexecute a log, the exact same webhook payload is sent again that was originally used for this log entry. No new meeting is started and no new event is triggered in Sally — it is purely a resend of the existing data.

This allows you to specifically test whether changes in the target system (for example, the webhook URL, authentication, or data processing) now work correctly, without triggering the entire process again.

To reexecute a log entry:

1. Open the log overview of your webhook integration.
2. Locate the desired log entry.
3. Click Reexecute.

Reexecute a single log entry

This allows you to test changes in the target system immediately — quickly, precisely, and reproducibly.

6.6. Common issues & quick fixes

Issue	Typical symptoms	Quick fix
Incorrect URL	Requests fail or hit the wrong endpoint	Compare the target URL in the logs with the expected endpoint. Watch out for typos, missing paths, or outdated test URLs.
Missing or incorrect authentication	401 Unauthorized or 403 Forbidden	Verify API keys, tokens, and required headers in the target system.
Payload does not match the target system	Errors despite successful delivery	Inspect the payload in the log details. The target system may expect a different format, field names, or version.
Rate limiting	429 Too Many Requests	Reduce the number of webhook events or introduce queues/delays in the target system.
Target system unavailable	5xx server errors	Check the availability or status of the target system. You can manually reexecute the webhook from the logs.
Test mode not enabled	No reaction in tools like n8n	Ensure the workflow in the target system is actively listening when using test URLs.

---

7. How Do You Execute a Webhook Manually?

In addition to automatic execution after a meeting, you can also trigger webhooks manually for a specific appointment in Sally.
This is especially useful if you want to resend a webhook intentionally without waiting for a new event.

To execute a webhook manually:

1. Open the desired appointment.

Execute webhook manually from an appointment

2. Click the Integrations button at the top.
3. Select "Execute Webhook manually".

Manually executed webhook shown as a log entry

What happens when you execute a webhook manually?

When executing a webhook manually, Sally sends the webhook again for this exact appointment to the configured target system.

Important to know:

• No new meeting is created.
• No automatic event is required or triggered.
• The same payload structure is used as with the automatic webhook execution.

The manually executed webhook then appears as a separate entry in the logs, including:

• execution time,
• target endpoint,
• HTTP status,
• and full request and response details.

This allows you to:

• test changes in the target system,
• retry failed transmissions,
• or resynchronize data without having to run the meeting again.

---

8. FAQ & Troubleshooting

• My webhook isn't sending anything. What should I do?
• How do I set the webhook language?
• How long are logs stored?
• Can I use multiple webhooks at the same time?
• What is the difference between a personal and a company-wide webhook?
• What happens if my target system is unreachable?
• Can I customize the webhook body content?
• Can I edit a webhook after creating it?
• How can I test my webhook without running a meeting?
• What HTTP method does Sally use for webhooks?
• Can I temporarily disable a webhook without deleting it?
• Are webhooks also triggered for uploaded recordings?
• My target system receives the data but doesn't process it correctly.

My webhook isn't sending anything. What should I do?

1. Check whether the triggering event (e.g. summary created) actually occurred.
2. Make sure the webhook is enabled in the integration settings.
3. Open the Logs for the webhook integration and check if an entry exists. If it does, the HTTP status will indicate the issue.
4. If no log entry exists, the webhook was not triggered. Verify that the webhook is assigned to the correct scope (personal vs. company-wide).

How do I set the webhook language?

You set the language directly in the webhook form using the "Language" field. Go to Settings > Integrations, create a new webhook or edit an existing one, and select the desired language from the dropdown.

Select language in the webhook form

Sally will then generate the webhook body content (e.g. summary, tasks, decisions) in the selected language. The language is included in the JSON body as the languageCode field using BCP-47 codes (e.g. de-DE or en-US).

How long are logs stored?

Webhook logs are stored for 90 days for security and traceability purposes and then automatically deleted. Manual deletion is not required.

Can I use multiple webhooks at the same time?

Yes. You can create as many webhooks as you need, both in the personal and company-wide scope. Each webhook can have its own URL, authentication, and individually configured body. This allows you to send data to Zapier, Make, and your own backend simultaneously, for example.

What is the difference between a personal and a company-wide webhook?

• Personal webhook: Only triggers for meetings of the user who created the webhook.
• Company-wide webhook: Triggers for all meetings across the entire company account, regardless of who conducted the meeting.

The scope is determined when you create the webhook, depending on whether you add the integration under "Your personal integrations" or under "Integrations (Company)".

What happens if my target system is unreachable?

If the target system is unavailable when Sally tries to send the webhook (e.g. 5xx errors or timeouts), the failed attempt is recorded in the logs. You can manually reexecute the webhook from the logs at any time.

Can I customize the webhook body content?

Yes. In the webhook form, you will find the "HTTP Body Customization" section. There, you can enable or disable individual categories such as tasks, summary, transcription, decisions, objections, custom insights, and meeting-type elements. This gives you precise control over which data is included in the webhook body.

Can I edit a webhook after creating it?

Yes. Open the integration overview, click on the desired webhook, and adjust the settings (e.g. URL, authentication, headers, body version, or language). Changes take effect from the next webhook execution.

How can I test my webhook without running a meeting?

You have two options:

1. Connection test: Open the webhook in the integration settings and click Test. Select an existing meeting as the basis. Sally sends a test event to the configured URL.
2. Reexecute a log: Go to the log overview of the webhook and click Reexecute on an existing entry. This resends the exact same payload.

What HTTP method does Sally use for webhooks?

Sally always sends webhook data as an HTTP POST request with a JSON body (Content-Type: application/json).

Can I temporarily disable a webhook without deleting it?

Yes. You can deactivate a webhook in the integration settings. While the webhook is deactivated, Sally does not send data to the configured URL. You can reactivate it at any time without having to reconfigure anything.

Are webhooks also triggered for uploaded recordings?

Yes. Webhooks are triggered whenever the configured event occurs, regardless of whether the meeting was recorded live or uploaded as a file. Once Sally has created the summary, the webhook is sent.

My target system receives the data but doesn't process it correctly. What could be wrong?

Check the following:

1. Open the log entry and compare the sent payload with the expected format of your target system.
2. Make sure you have selected the correct HTTP body version.
3. Ensure that field names and data types match what the target system expects. Some fields are sent as Markdown or HTML (see the field reference).
4. If your tool expects a different date format, you will need to convert the ISO 8601 format (2025-03-15T00:00:00.000Z) in your target system accordingly.