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
Your system sends a request. A
POSTwith a JSON body goes to the webhook URL, with the authentication header the webhook expects.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.The plan runs. Sprinto starts the attached ingestion plan. The request body is available to the plan as
params.webhookPayload.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
Entity type
The shape of the records, such as Server with os_version and disk_encrypted fields
Ingestion → Entity Types
Ingestion plan
Steps that read the request body, map it to the entity type and store it
Ingestion → Plans
Webhook
The URL, authentication and limits, with the plan attached
Ingestion → Webhooks
Sender
The system or script that calls the webhook URL
Your side
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
Last updated