Overview

AutoElevate can post events straight into a Microsoft Teams channel or a Slack channel — a new elevation request, a session that just started, an agent update that failed — as a formatted card with a button that opens the record in the Admin Portal. This is the most common use of AutoElevate webhooks: you create a destination URL in Teams or Slack, then register it with AutoElevate as a webhook in the matching format.

Registering the webhook is done through the Partner API. There is no webhook screen in the Admin Portal, so someone at your organization needs to make a few authenticated API calls — typically four: one to confirm your key works, one to create the webhook, one to send a test, and one to read the delivery logs if the test does not arrive. No code has to run on your side once the webhook exists; the calls themselves can be made with curl, Postman or any HTTP client. If you have not used the Partner API before, read Partner API (BETA) first for how to create an API key; this article includes the request details you need for these calls.

Before You Begin

• A Partner API key on a user with the Administrator role. Webhook permissions are held only by that role, and there is no screen for adding them to a custom role. If your API user has a custom role, either use an Administrator's key or contact CyberFOX Support to have the permissions added. See Partner API (BETA) for creating the key.
• These permissions on the key. In the API key permission picker, grant:
  • Create webhooks — to register the webhook (Step 2). This is the only permission a company-scoped webhook needs to be created.
  • Update and test webhooks — to send the test event (Step 3), and to disable or re-enable the webhook.
  • Read webhooks — to read the delivery logs if the test does not arrive.
  • Read companies — only if you will look up the company ID through the API (Step 2). You can find the ID in the Admin Portal instead.
• A key type. Keys are created in the Admin Portal on a user's page (Users → the user → API keys) by anyone whose portal role has permission to edit users. The Scheme picker offers Bearer (most tooling) and HMAC-SHA256 (signed). Bearer is the default and the simpler choice here: you send it as-is in an Authorization: Bearer … header from curl, Postman or any HTTP client. HMAC requires you to compute a signature for every request. Both work on every webhook route. The scheme only covers your calls to the Partner API — Teams and Slack deliveries are unsigned whichever key you use, so there is no signature to check on the channel side.
• A short key expiration. You only need the key while you register and test the webhook, so pick the shortest expiration that covers the work. The webhook is not tied to the key or the user that created it, so it keeps delivering after the key expires or is revoked. To disable or delete the webhook later, create a new key with Update and test webhooks or Delete webhooks.
• Somewhere to post to — a Teams channel or a Slack channel you have permission to add integrations to.
• A decision on scope. One webhook can cover every company in your organization, or exactly one company. A channel per customer means one webhook per customer.

Request basics

Every call in this article goes to the same base URL and carries the same two headers:

• Base URL: https://partner-api.autoelevate.com
• Authorization — for a Bearer key, Bearer followed by your key. For an HMAC key, the signed header described in the Partner API reference.
• X-Acknowledgment: i-understand-this-is-beta-and-may-change — required on every request, exactly as written. Without it the API returns 400 with Missing or invalid X-Acknowledgment header.

Paths in this article are versioned (/api/v1/…). The unversioned form (/api/webhooks) is a permanent alias for v1 and also works, but the reference recommends pinning a version. Requests are limited to 20 per minute per route; if you exceed that the API returns 429 with a Retry-After header.

Step 1 — Create the Destination URL

Microsoft Teams

Use a Power Automate Workflows URL, not a classic Incoming Webhook connector. Microsoft retired the classic Office 365 connectors in May 2026; a Workflows URL is the supported path.

1. In Teams, open the channel, choose Workflows, and pick the template Send webhook alerts to a channel. Do not use the "from specific people" or "from people in an org" versions. They need a sign-in token that AutoElevate does not send.
2. Complete the workflow, selecting the team and channel to post to.
3. Copy the URL the workflow gives you. It is on the environment.api.powerplatform.com domain, for example https://<id>.aa.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/….

Check the domain before you continue. A supported Teams URL is on *.environment.api.powerplatform.com. URLs on logic.azure.com stopped working on 30 November 2025, and classic webhook.office.com connectors stopped in May 2026. If you have either, create a new workflow.

Slack

1. In Slack, create or open an app for your workspace and enable Incoming Webhooks.
2. Add a new webhook to the workspace and choose the channel to post to.
3. Copy the webhook URL. It is on hooks.slack.com, for example https://hooks.slack.com/services/….

Treat either URL as a password. Anyone who has it can post into your channel. Store it in your password manager, not in a text file, ticket or chat. AutoElevate stores it write-only and never shows it again after creation.

Step 2 — Register the Webhook with AutoElevate

Confirm your key works and find the company ID

If the webhook is for one customer, you need that company's ID, a UUID such as a1b2c3d4-e5f6-7890-abcd-ef1234567890. If your key has Read companies, listing your companies returns it — and, as a harmless read, it is also the quickest way to prove your key and headers are right before you create anything:

curl "https://partner-api.autoelevate.com/api/v1/companies?take=200" \
  -H "Authorization: Bearer aeb_xxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "X-Acknowledgment: i-understand-this-is-beta-and-may-change"

A 200 response lists your companies under items, each with its id and name. Copy the id of the customer the channel is for.

If your key does not have Read companies, find the ID in the Admin Portal instead: open the company's page and copy the ID from the browser address bar, which ends in /companies/ followed by the ID. Your portal role needs permission to view companies to open that page. To prove the key without Read companies, use GET /api/v1/webhooks (needs Read webhooks).

Create the webhook

Send an authenticated POST to /api/v1/webhooks with a JSON body. For a Teams channel that should see every elevation request and approval for one customer:

{
  "name": "Approvals channel",
  "url": "https://<id>.aa.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/…",
  "eventSubscriptions": ["request.created", "request.approved", "request.denied"],
  "format": "teams-incoming-webhook",
  "companyId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

The webhook is live as soon as it is created. There is no way to create it disabled — real events that match its subscriptions start posting immediately. If you want to prove the channel before any real event can arrive, see the optional sequence in Step 3.

The response includes the new webhook's ID as webhookConfiguration.id; keep it for the test and for any later changes. It also includes a signing secret, which the Teams and Slack formats do not use — Teams and Slack cannot verify a signature, so for these formats the URL is the only credential and the secret can be discarded.

Step 3 — Send a Test Event

1. Send POST /api/v1/webhooks/{id}/test, with no request body.
2. Read the response. {"success": true} means Teams or Slack accepted the delivery. {"success": false} means AutoElevate sent the test but the destination did not answer with a 2xx — go to the delivery logs (step 4).
3. Check the channel. A card titled AutoElevate test delivery should appear within a few seconds, showing the message This is a test webhook delivery from AutoElevate. and who triggered it. It has no button, because a test has nothing to open.
4. If nothing appears, read GET /api/v1/webhooks/{id}/delivery-logs and match the most recent entry against Troubleshooting below.

If the test returns 404 in the first few seconds after creating the webhook, wait a moment and try again — the new record is still propagating.

Optional: test before any real event can post

The test route works even while the webhook is disabled. Because a new webhook is live immediately, use this sequence if you need to prove the channel with no chance of a real event arriving first:

1. Create the webhook (Step 2).
2. Immediately send PATCH /api/v1/webhooks/{id} with {"enabled": false}.
3. Send the test and confirm the card arrives.
4. Send PATCH /api/v1/webhooks/{id} with {"enabled": true} to go live.

Events raised in the few seconds between steps 1 and 2 can still post.

What the Cards Contain

Every event uses the same card layout. What changes from event to event is the title and the facts:

• Title — a plain-language name for the event, such as Elevation request approved.
• Timestamp — when the event happened, in UTC.
• Up to ten facts drawn from the event. For an elevation request: company, machine, user, file, publisher, elevation type, the user's reason, who acted on it, file path and status (a denial reason takes the status's place). Internal identifiers are left out.
• Open in AutoElevate — a button that opens the record in the Admin Portal. Elevation request and session events open the request; events about a computer open that computer. Organization-structure events (companies, locations, users) have no record to open and carry no button.

Slack cards carry the same title, facts, button and timestamp as a Block Kit message. The card layout is fixed by AutoElevate; you choose which events reach the channel, not what the card shows.

Best Practices

• Use a Service user's API key to create the webhook, so the key you manage webhooks with survives staff changes. Removing a user does not stop the webhooks they created. The Service user needs the Administrator role. See Partner API (BETA).
• Keep the key short-lived and narrow. Grant only the webhook permissions listed in Before You Begin, and choose the shortest expiration that covers the setup. The webhook outlives the key; to change or stop it later, create a new key.
• Prove your key first. Run the company lookup in Step 2 (or GET /api/v1/webhooks) before creating anything; a 200 there rules out key, header and signing problems.
• One webhook per channel, one purpose per channel. A security channel that gets elevation requests and alerts is read; a channel that gets every event type is muted within a week.
• Scope per customer if your technicians work from per-customer channels — one webhook per company, each with its own destination URL.
• Use a Workflows URL for Teams. Re-create any webhook that points at logic.azure.com or webhook.office.com, because those URLs no longer work.
• When a Teams or Slack URL changes, send the new URL in a PATCH, or create a new webhook and delete the old one. Do not send back the redacted URL you read from the API; leave url out to keep it, or send the full new one to change it.
• Disable rather than delete when pausing a channel, so the configuration survives. Either way, deliveries already in progress can continue for a few minutes.
• Keep the webhook ID with the channel's documentation. You need it for every test, log read and change.

Troubleshooting

Any call returns 401

AutoElevate rejected your credentials before looking at the request. Check that the key has not expired or been revoked, that the Authorization header matches the key's scheme (Bearer … for a Bearer key; the signed AE-HMAC-SHA256 … header for an HMAC key), and that the key was pasted completely. For HMAC keys, also check the computer's clock: the signed timestamp must be within 5 minutes of AutoElevate's server time.

Any call returns 400 about the acknowledgment header

Missing or invalid X-Acknowledgment header means the beta header is missing or not exactly i-understand-this-is-beta-and-may-change. Add it to every request, verbatim.

The create call returns 403

You are not authorized to perform this action. means the API key or its user lacks the Create webhooks permission. Only the Administrator role holds it; use an Administrator's key, or contact CyberFOX Support to have the permission added to your role. A different 403 — one that says a webhook without a companyId receives events for every company and asks you to name a company — means the key's user is restricted to certain companies and tried to create an organization-wide webhook. Add a companyId.

The create call returns 400

The message names the field. The common ones: Webhook URLs must use https. (the URL starts with http://); Event types … are raised for the MSP, not a company, so only a webhook without a companyId can subscribe to them. (you combined user.* events with a companyId — remove one or the other); or a validation error on eventSubscriptions (a misspelled identifier, or the reserved type test).

The create call returns 422

The companyId names a company that does not exist. Check it against the company lookup in Step 2.

A call returns 429

You have exceeded 20 requests per minute on that route. Wait for the number of seconds in the Retry-After header and try again.

The test returns success: false

AutoElevate sent the test, but Teams or Slack did not answer with a 2xx. The test is not retried. Read the delivery logs and match the most recent entry against the table below.

Nothing appears in the channel

Read the delivery logs for the webhook and look at the most recent entry:

The API returns only the 50 most recent attempts, so read the logs soon after a failure.

A card arrives but looks wrong

Check the format on the webhook matches the destination: teams-incoming-webhook for a Teams Workflows URL, slack-incoming-webhook for a Slack URL. A native webhook pointed at a chat URL posts nothing.

The channel went quiet after a company change

A company-scoped webhook is not re-pointed when that company is merged into another or removed. It stays configured and receives nothing. Re-scope it to the surviving company or delete it.

The same event posted twice

A slow or failed first delivery was retried and both eventually reached the channel. This is expected behavior for a chat destination, which cannot de-duplicate. If it happens often, the destination is answering slowly.

What to include in a support ticket

From the delivery log entry: the deliveryId, the createdAt and attemptNumber, the eventType, and responseStatusCode and errorMessage verbatim — plus the webhook ID from GET /api/v1/webhooks. The deliveryId is the value Support can search for. Never include the Teams or Slack URL, or your API key, in the ticket.

Security Notes

• The URL is the credential. Teams and Slack deliveries are not signed. Anyone holding the URL can post to the channel. Store it as you would a password, and never paste it into a ticket or chat. If it is exposed, regenerate it in Teams or Slack and update or re-create the webhook.
• AutoElevate never shows the URL again after creation. Reads return only its origin.
• Your API key is a credential too. Keep it in a password manager or secrets manager, give it only the permissions this setup needs, and let it expire when you are done.
• Cards can carry sensitive detail — computer names, user names, requested applications, the reason a user gave for a request. Post only into channels whose membership you control.
• Permission to create webhooks is deliberately narrow. It belongs to the Administrator role only.

Related Articles

• AutoElevate Webhooks (Beta)
• Partner API (BETA)
• AutoElevate Audit Log: Tracking Settings and Account Changes