Sending Incode Events to Splunk

Splunk is a widely adopted Security Information and Event Management (SIEM) platform used for log aggregation, threat detection, and operational analytics. Incode's event system is built on webhooks — HTTP callbacks that push real-time notifications to your infrastructure whenever a key identity verification event occurs. Since Splunk's HTTP Event Collector (HEC) is designed to accept inbound HTTP payloads, the two systems connect naturally.

This guide walks through everything you need to get Incode identity events flowing into Splunk for centralized visibility and analysis.

The instructions below are written for Splunk Cloud. If you're running Splunk Enterprise, the process is largely the same.

Table of Contents

• Splunk Configuration
• Incode Configuration
• Webhook Events Reference
• Webhook Payload Format

Splunk Configuration

Before touching anything in Incode, you'll need to set up an HTTP Event Collector (HEC) token in Splunk. This is what allows Splunk to receive incoming JSON payloads over HTTP.

Step 1 — Navigate to Data Inputs

In Splunk, open the Settings menu and choose Data inputs.

Step 2 — Open HTTP Event Collector

From the Data inputs page, select HTTP Event Collector to manage your HEC tokens.

Step 3 — Create a New Token

Click New Token and fill in the form as follows:

Click Next to continue.

Step 4 — Finalize and Save

On the Input Settings screen, the defaults are fine — click Review, then Submit. Your new HEC token will be shown on the confirmation screen. Copy it now and store it somewhere accessible; you'll need it when configuring Incode.

You can always retrieve the token again from Settings → Data inputs → HTTP Event Collector if needed.

Incode Configuration

With your HEC token in hand, head to the Incode Dashboard and go to Configuration → Webhooks. This is where you'll tell Incode where to send event data. The full webhook reference is available at developer.incode.com/docs/webhooks.

Step 1 — Enter the Splunk Endpoint

In the URL field, enter your Splunk HEC endpoint:

https://<HOST>.splunkcloud.com:8088/services/collector/raw

Replace <HOST> with your Splunk Cloud collection hostname.

Two things to note about this URL:

• /services/collector/raw not /services/collector/event — Incode sends plain JSON payloads with no wrapper or envelope. The /event endpoint expects payloads wrapped in Splunk's own JSON format, so using it will cause Splunk to fail to parse the data and drop events. /raw accepts the payload exactly as Incode sends it.

Step 2 — Add the HEC Token as a Custom Header

Splunk's HEC endpoint requires a token to accept incoming data. The correct way to pass it is via the Webhook Custom Headers section in the Incode Dashboard — leave the Authentication section above it blank, as that is for OAuth2 and is not applicable here.

Add the following header:

Replace <HEC_TOKEN> with the token you copied from Splunk.

If your Splunk URL includes a port number (such as :8088), include it in the URL regardless of which option you choose — for example: https://<HOST>.splunkcloud.com:8088/services/collector/raw

Step 3 — Choose Which Events to Send

Select the webhook events you want Incode to forward to Splunk. See the Webhook Events Reference section below for a complete breakdown of what each event represents.

A practical starting point for most SIEM use cases — covering final outcomes without exposing PII:

• ONBOARDING_FINISHED
• SESSION_SUCCEEDED
• SESSION_FAILED
• SESSION_PENDING_REVIEW

If you need more granular visibility into in-progress verification steps — and your data handling policies permit it — you can also enable intermediate events that may carry PII:

• ID_VALIDATION_FINISHED
• GOVERNMENT_VALIDATION_FINISHED
• FACE_VALIDATION_FINISHED

Step 4 — Additional Custom Headers (Optional)

Beyond the Authorization header added in Step 2, you can define additional static headers that get attached to every outbound webhook request. These are useful for internal routing tokens or any other fixed header value your infrastructure requires.

Keep in mind that all headers you define will be sent across all webhook types — there's no per-event header customization, and dynamic values aren't supported.

Webhook Events Reference

Incode's webhook system spans several categories, each covering a different aspect of the identity verification lifecycle. All events arrive as HTTP POST requests with a JSON body.

Onboarding Status Events

The Onboarding Status Webhook emits a notification each time the processing state of a verification session advances. Because a full onboarding session involves multiple modules — ID capture, government validation, face match, and more — this webhook can fire several times per session in sequence.

Prefer a simpler integration? If you only care about a session's final state rather than every intermediate step, use Session Webhooks — they each fire once, for a single defined outcome.

Session Webhooks

Session webhooks give you a clean, one-notification-per-outcome model. Each of the four events below can be pointed at its own URL, and each fires exactly once per session when that specific outcome occurs.

Webhook Payload Format

Onboarding Status — Sample Payload

{
  "clientId": "MyClientId001",
  "flowId": "66969519eb1d789a96347ca7",
  "interviewId": "664283755e0f8e1b87fcc2ce",
  "externalCustomerId": "MyCustomerID#0001",
  "onboardingStatus": "ONBOARDING_FINISHED"
}

externalCustomerId is only present in the payload if your integration passed this value when creating the session via the omni/start endpoint.

Session Webhook — Common Payload Fields

All four session webhooks share a common set of fields:

Additional fields are included in SESSION_FAILED, SESSION_SUCCEEDED, and SESSION_PENDING_REVIEW:

SESSION_SUCCEEDED also includes:

OAuth2 Authentication Header

If you've enabled OAuth2 authentication for webhook delivery, each request will carry:

Authorization: Bearer <ACCESS_TOKEN>

Setup instructions are available at Authenticating Webhook Requests.

How to Respond

Incode expects one of the following HTTP responses from your endpoint to mark a delivery as successful:

• 204 No Content
• 200 OK with Content-Type: application/json

Example of an acceptable 200 response body:

{ "success": true }

Returning anything else, or timing out, will trigger a retry.

Additional Resources

• Incode Webhooks Overview
• Authenticating Webhook Requests
• Onboarding Status Webhook Reference
• Session Webhooks Reference
• Incode Dashboard
• Splunk HEC Documentation