> For the complete documentation index, see [llms.txt](https://docs.sprinto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sprinto.com/ingestion/webhooks.md).

# Webhooks

Learn how to create, configure, manage, and monitor ingestion webhooks in Sprinto, including authentication, attached plans, recent events, webhook testing, and lifecycle actions.

Ingestion webhooks let your systems push data to Sprinto when it changes, instead of waiting for Sprinto to collect it on a schedule. Each webhook has its own URL. When a system sends a JSON request to that URL, Sprinto runs the ingestion plan attached to the webhook, and the plan turns the request body into records Sprinto can monitor.

### When to use a webhook

Use a webhook when:

* The source system can call an HTTP endpoint when something changes, such as an asset being created, a setting changing or a scan finishing.
* The source has no API Sprinto can poll, or polling would be too slow.
* You want to send data from your own scripts, CI pipelines or internal tools.

If the source has an API that Sprinto can read on a schedule, a scheduled ingestion plan is usually simpler.

### How it works

1. **Your system sends a request.** A `POST` with a JSON body goes to the webhook URL, with the authentication header the webhook expects.
2. **Sprinto checks and records it.** Sprinto checks the size, rate limit, authentication and whether the event is a duplicate, then records the event and responds `202`.
3. **The plan runs.** Sprinto starts the attached ingestion plan. The request body is available to the plan as `params.webhookPayload`.
4. **Records are stored and checked.** The plan maps the body to an entity type, stores the records, and runs the checks set up for them.

A `202` confirms that Sprinto received the event. To confirm that records were stored, check the plan run linked from the event.

### What you need

<table><thead><tr><th width="161.32421875">Piece</th><th>What it is</th><th>Where to set it up</th></tr></thead><tbody><tr><td><strong>Entity type</strong></td><td>The shape of the records, such as <code>Server</code> with <code>os_version</code> and <code>disk_encrypted</code> fields</td><td>Ingestion → Entity Types</td></tr><tr><td><strong>Ingestion plan</strong></td><td>Steps that read the request body, map it to the entity type and store it</td><td>Ingestion → Plans</td></tr><tr><td><strong>Webhook</strong></td><td>The URL, authentication and limits, with the plan attached</td><td>Ingestion → Webhooks</td></tr><tr><td><strong>Sender</strong></td><td>The system or script that calls the webhook URL</td><td>Your side</td></tr></tbody></table>

### Key things to know

* **Send many records in one request.** Put records in a JSON array in a single request, up to 500 KB. One request becomes one plan run.
* **One run per plan at a time.** Runs of the same plan never overlap. While a plan is running, other events for that plan are declined rather than queued. See Known limitations.
* **Authenticate every production webhook.** Use an API key, bearer token or HMAC signature. **No Auth** is for testing only.
* **Duplicates are ignored.** Sprinto skips events it has already received, based on the event's ID or its body, so a sender that retries won't create extra runs.
* **The plan sees only the body.** Request headers and query-string values are not passed to the plan.

### Known limitations

* **Events that arrive during a run aren't queued.** Sprinto runs one execution of a plan at a time. A plan can read, create, update and delete records, and two runs doing that at the same time could conflict or block each other. So while a run is in progress, other events for the same plan are declined as duplicate invocations. The declined events still show **completed** in the webhook log, but no records are stored from them. Batch records into one request, or leave time between requests for the previous run to finish.
* **"Completed" isn't linked to the run's outcome.** An event shows **completed** once it is handed to the plan engine. Check the plan run to confirm that records were stored.

Improvements to both are on the roadmap.

### Next steps

* [Create and Manage Webhooks](https://app.gitbook.com/o/3Y6icP5z46IeflA3QtMY/sites/site_N29Ru/s/Esyn5VMU6e0OyGjRtKgx/~/edit/~/changes/624/ingestion/webhooks/create-and-manage-webhooks)
* [Ingestion Webhooks: Technical Guide](https://app.gitbook.com/o/3Y6icP5z46IeflA3QtMY/sites/site_N29Ru/s/Esyn5VMU6e0OyGjRtKgx/~/edit/~/changes/624/ingestion/webhooks/ingestion-webhooks-technical-guide)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sprinto.com/ingestion/webhooks.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.