Microsoft 365 Connectors and Webhooks

Connectors and webhooks are two complementary technologies that allow Microsoft 365 to receive data from external services and send data to external services. They are fundamental to building automated workflows and integrations without writing custom code. The MS-900 exam tests your understanding of their purpose, configuration, and limitations.

Webhooks are HTTP callbacks: an external service sends an HTTP POST request to a predefined URL when a specific event occurs. In Microsoft 365, webhooks are used to receive notifications from external systems into groups, Teams channels, or other endpoints. For example, a monitoring tool can send a webhook to a Teams channel when a server goes down.

Connectors are pre-built wrappers around webhooks that simplify configuration. They provide a user interface to define triggers and actions without needing to write the HTTP request manually. Microsoft 365 offers both built-in connectors (like the Office 365 Outlook connector) and the ability to create custom connectors for your own services.

At the protocol level, a webhook is simply an HTTP POST request sent to a specific endpoint URL. The request body is typically JSON or XML. In Microsoft 365, the endpoint is a URL generated by the target (e.g., a Teams channel's webhook URL). The flow:

Connectors abstract this process. When you configure a connector in the Microsoft 365 admin center or within a Teams channel, you are essentially setting up a webhook endpoint and defining the message format. The connector may also include authentication (e.g., OAuth) and data transformation.

To create a webhook in a Teams channel:

To test the webhook, you can use a tool like curl:

curl -H "Content-Type: application/json" -d '{"text": "Hello from curl"}' <your_webhook_url>

For connectors with more complex logic, you may use Power Automate, which provides a graphical interface to define triggers and actions. Power Automate connectors can use webhooks internally.

Using curl:

curl -X POST -H "Content-Type: application/json" -d '{
  "@type": "MessageCard",
  "@context": "http://schema.org/extensions",
  "summary": "Test message",
  "title": "Alert",
  "text": "This is a test message from curl."
}' https://outlook.office.com/webhook/...

The message appears as a card in the Teams channel.

Connectors and webhooks are lightweight integration tools that enable Microsoft 365 to receive data from external systems. They are simple to set up but have security and rate-limit considerations. The MS-900 exam tests your ability to identify when to use them and how they differ from other integration methods like Power Automate or Microsoft Graph.

Scenario 1: DevOps Alerting with Jenkins and Teams

A development team uses Jenkins for CI/CD. They want build failure notifications sent to a Teams channel. They create an incoming webhook in the #build-alerts channel and configure Jenkins to send an HTTP POST to that URL on build failure. The Jenkins plugin 'Office 365 Connector' simplifies this by providing a UI to enter the webhook URL and choose message formatting. In production, they handle rate limits by using a dedicated webhook for Jenkins only, not sharing it with other services. They also include a secret token in the payload to prevent spoofing. Misconfiguration often occurs when the payload format is wrong—Teams expects a specific JSON schema; if the 'text' field is missing, the message may not appear. They also learned to set the webhook URL as a Jenkins credential to avoid exposing it in plain text in job configurations.

Scenario 2: Customer Support Integration with Zendesk

A support team uses Zendesk for ticket management. They want new high-priority tickets to appear in a Teams channel. Zendesk supports webhooks natively: they create a webhook in Zendesk targeting the Teams incoming webhook URL. They set the trigger to send when a ticket with priority 'urgent' is created. The Zendesk webhook sends JSON with ticket details; they use a Power Automate flow to transform the Zendesk format into a Teams MessageCard because Zendesk's default payload is not compatible. This adds a processing step but allows custom formatting. Scale considerations: at 1000 urgent tickets per hour, they stay well under the 4 req/s limit. They also set up a second webhook for a different channel for 'critical' tickets. A common mistake is forgetting to update the webhook URL when the channel is renamed or deleted, causing silent failures.

Scenario 3: Social Media Monitoring with Twitter to SharePoint

A marketing team wants to save tweets mentioning their brand into a SharePoint list. They use Power Automate with the Twitter connector (trigger: when a new tweet is posted) and the SharePoint connector (action: create item). This flow uses webhooks internally—Twitter sends a webhook to Power Automate, which then writes to SharePoint. No manual webhook configuration is needed. However, the Twitter connector requires a Twitter developer account and API keys. Performance: Power Automate flows have a maximum run duration of 30 days, but for real-time processing, this is fine. Misconfiguration: if the SharePoint list schema changes, the flow fails. They monitor flow runs in the Power Automate portal.