> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thinkplatform.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Choose User guide for browser tasks, Developers for CLI, SDK and external agents, and Administration for organization management.
> Confirm identity and organization/project context before operations. Documentation access does not grant ThinkPlatform permissions.
> Review side effects, verify changes with a read, and do not blindly retry an operation with an uncertain outcome.
> Use documented UI steps for the web app and documented public CLI or SDK interfaces for automation. Follow each page’s prerequisites and authentication requirements.

# Receive events with webhook endpoints

> Configure an authenticated inbound webhook for an agent or flow.

An inbound webhook endpoint receives a request and starts an agent task or flow. It is different from an outbound [webhook subscription](https://docs.thinkplatform.ai/guides/automation/schedules-and-webhooks.md), which sends platform events to another service.

## Before you begin

Select the organization and project containing the intended agent or flow. A project Owner must create and manage the endpoint and have access to its target. Arrange an authorized sender and agree on its authentication method and a safe test payload. An endpoint's tasks run as the current editor shown in **Run as user**; verify that person's access and the target's actions before saving. Do not use another person's credentials or include secrets in a test payload.

## Create and authenticate an endpoint

1. Open **Automation → Webhooks → Endpoints** and choose **New Webhook Endpoint**. Enter a **Hook name** and choose the **Target type** and agent or flow.
2. For an agent, write **Instruction text** describing what it should do with the incoming data and select the payload mode. For a flow, review its fixed/default inputs and, if using schema mapping, map only the incoming fields that should override those inputs. Check the selected target and **Run as user**.
3. Choose an **Auth mode** supported by the sender: `static_secret`, `github_signature`, or `entra_jwt`. For a shared or signing secret, securely store the generated secret when it is shown; it is shown only once. Give it only to the authorized sender through an approved secret channel. For Entra JWT, coordinate the platform-managed tenant, caller identity, and required app role with your administrator.
4. Choose **Create**. Copy the endpoint URL from the resulting endpoint details and configure the authorized sender with the corresponding authentication. Treat the URL and credentials as sensitive; do not paste them into chat, documentation, or logs.

## Test and verify the result

1. Select the saved endpoint and find **Request example** in its details. Choose the **curl** or **Python** tab and copy the example into a private, controlled environment for the authorized sender. The example is specific to the endpoint and auth mode; replace placeholders using the sender's approved credential source. Do not put credentials in a shared shell history, chat, ticket, or log.
2. Use a harmless payload that matches the configured agent instructions or flow mapping. The example includes sample JSON; replace any real or sensitive values with harmless test values and review the target's side effects first. For `static_secret`, the request uses `Authorization: Bearer <hook-secret>`. For `github_signature`, calculate `X-Hub-Signature-256: sha256=<signature>` using the signing secret and the exact request body, as shown in the example; changing the body requires a new signature. For `entra_jwt`, use `Authorization: Bearer <entra-access-token>` with an authorized caller and the displayed token scope. Never share the secret or token as part of the payload.
3. Have the authorized sender run the prepared request once. Open **Deliveries** and refresh; inspect status, response code, error, and task ID when available. Follow the task or flow run to inspect its status and result; a received request alone does not prove the target completed successfully. Review delivery details carefully because they can contain request headers and payload data.

If authentication fails, check the chosen mode and sender configuration with the responsible administrator without exposing credentials. If the delivery is accepted but the task fails, inspect the target, its inputs, and the editor's permissions. Before retrying, check whether the first event already started work or changed a resource.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.