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

# Create an endpoint

> Configure, test, monitor, disable, and remove a workspace webhook.

Your receiver must be publicly reachable over HTTP or HTTPS. Use HTTPS in production.

## Create the receiver first

Build a route that:

* accepts `POST` with a JSON body;
* reads the exact raw request body;
* verifies `Biqli-Signature`;
* deduplicates the envelope `id`;
* returns an HTTP `2xx` response quickly.

Do not require browser cookies, CSRF tokens, or interactive authentication on this route. The HMAC signature authenticates Biqli's payload.

## Add it in Biqli

<Steps>
  <Step title="Open Webhooks">
    Select the workspace, then open **Workspace settings -> Webhooks**.
  </Step>

  <Step title="Create a webhook">
    Enter a recognizable name and the complete public receiver URL.
  </Step>

  <Step title="Choose events">
    Select every event type this endpoint should receive. At least one event is required.
  </Step>

  <Step title="Store the signing secret">
    Copy the `whsec_...` signing secret into your server secret manager. Never place it in frontend code or source control.
  </Step>

  <Step title="Send a test event">
    Open the webhook's event log and select **Send test event**. Inspect the recorded request, response, status, and attempts.
  </Step>
</Steps>

## URL safety rules

Biqli validates the destination at configuration time and again immediately before every attempt.

* The URL must use HTTP or HTTPS.
* Credentials embedded in the URL are rejected.
* `localhost`, private addresses, and reserved network addresses are rejected.
* The hostname must resolve publicly.
* Redirect responses are not followed and count as failures.
* One workspace cannot configure the same normalized URL twice.

The URL is re-resolved for every delivery to prevent a later DNS change from reaching an internal service.

## Manage the endpoint

From the webhook detail page you can:

* inspect event and attempt history;
* copy the webhook and event IDs;
* inspect request headers and payloads;
* inspect response status, headers, and body;
* send realistic test events;
* edit the name, URL, and subscriptions;
* disable or enable future event delivery;
* delete the endpoint.

Disabling an endpoint stops new production events from being queued. A pending or retrying production delivery is cancelled when its job next runs; test deliveries can still be sent for diagnosis. Existing history remains visible. Deleting the endpoint removes its associated delivery records.

## Permissions

Workspace access follows the webhook permissions assigned to the member: view, create, update, and delete. A member cannot use webhook access to read or modify another workspace's endpoints.