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

# Getting Started

> Create and manage webhooks from your Zivio platform

### Before you begin

Webhooks are managed from the **Admin** area of your Zivio platform. You will need:

* An admin account with permission to manage webhooks. If you cannot see the Webhooks section, ask your platform administrator to grant you access.
* A publicly reachable **HTTPS** endpoint that can accept `POST` requests and return a `2xx` response.

<Note>Webhook URLs must be public HTTPS addresses. Internal, private, or local addresses are not permitted.</Note>

### Creating a webhook

<Steps>
  <Step title="Open the Webhooks admin">
    Navigate to the **Admin** area and select **Webhooks**.
  </Step>

  <Step title="Add a new webhook">
    Choose **Add Webhook** and complete the form:

    * **Name** — a label to help you identify the webhook.
    * **URL** — the HTTPS endpoint that will receive events.
    * **Description** — optional notes about what this webhook is for.
    * **Events** — tick the events you want to receive. You can select individual events, an entire category at once, or all events.
  </Step>

  <Step title="Save and store your signing secret">
    When the webhook is created, Zivio shows you a **signing secret** that begins with `whsec_`.

    <Warning>The full signing secret is shown only once, at creation. Copy it and store it securely — you will need it to [verify incoming requests](/webhooks/verifying-signatures). If you lose it, you can rotate the secret to generate a new one.</Warning>

    After this, only the last few characters of the secret are ever displayed, so you can identify which secret is in use without exposing it.
  </Step>
</Steps>

### What your webhook will receive

The data in each event payload reflects the permissions of the admin who created the webhook — the **owner**. A webhook only receives events for resources its owner is allowed to see, and the payload is shaped exactly as that owner would see it through the [v4 API](/api-reference). Keep this in mind when choosing who creates a webhook.

<Tip>For a service-style integration, create the webhook from an admin account that has the level of access your integration needs — no more, no less.</Tip>

### Sending a test event

Once your webhook is set up, you can send a **test event** to confirm your endpoint is reachable and your signature verification works. A test event has the type `webhook.test` and a simple placeholder payload, so it is safe to send at any time without affecting real data.

### Managing an existing webhook

From the Webhooks admin you can:

* **Edit** a webhook's name, URL, description, and subscribed events.
* **Rotate the signing secret** — this immediately invalidates the old secret and shows you a new one once. Your endpoint will reject requests until you update the stored secret on your side, so rotate during a maintenance window if possible.
* **Disable** a webhook to stop deliveries without deleting its history.
* **Review the health** of each webhook — recent delivery status and success rates are shown on the webhooks list.

### Reviewing deliveries

Every attempt to send an event is recorded. From the **Deliveries** view you can browse and filter deliveries by webhook, event type, status, and date, and open any delivery to inspect its request and response details. You can also **resend** a past delivery if needed.

<Note>When you resend an event, your endpoint receives it as a brand-new event with a new ID. If your system de-duplicates by event ID, it will treat the resend as a separate event.</Note>

### Next steps

<CardGroup cols={2}>
  <Card title="Event Types" icon="list" href="/webhooks/event-types">
    See everything you can subscribe to.
  </Card>

  <Card title="Verifying Signatures" icon="shield-check" href="/webhooks/verifying-signatures">
    Secure your endpoint against forged requests.
  </Card>
</CardGroup>