Integrations

How to connect zer0pii to the systems your team already runs. Every setting below is exactly what the console takes; the vendor-side steps name the standard documented route, not a screenshot we cannot verify.

SIEM export

The console's SIEM export writes metadata-only audit events as newline-delimited JSON (JSON Lines) objects to an S3 bucket you own, batched roughly every 60 seconds, plus an on-demand test event. zer0pii never configures S3 event notifications (SNS/SQS/Lambda triggers) on your bucket; if a vendor's route needs one, you set it up on your own bucket.

Object key layout

Object key layout
<prefix>/<org_id>/YYYY/MM/DD/HH/events-<uuid>.jsonl - one JSON object per line.

Credentials

Either an IAM role ARN (the console shows a ready-made trust policy scoped to your org's external ID, so only zer0pii's principal, presenting that ID, can assume it) or a static access key pair. Configure both in the console's SIEM export card: bucket, region, optional key prefix, and either the role ARN or the access key pair.

Splunk

Splunk Add-on for AWS, S3 input pointed at your export bucket/prefix. Splunk's AWS documentation covers creating the input; we have not verified specific menu paths since that is Splunk's UI, not ours.

Microsoft Sentinel

Sentinel's Amazon S3 connector reads from an S3 bucket via an SQS notification queue. That queue is AWS-side setup you configure yourself, since zer0pii's sink only writes objects and does not create bucket notifications.

Datadog

Datadog's S3 log forwarding, typically via the Datadog Forwarder Lambda triggered by an S3 event on your bucket. Same caveat as above: the S3-to-Lambda trigger is your AWS configuration, not something zer0pii sets up.

SIEM export console reference

Source: apps/gateway/core/s3_siem_sink.py, apps/gateway/api/v1/console.py:516-649

Single sign-on

OIDC and SAML are both supported, one protocol per organization, configured in the console's Single sign-on card. Neither protocol can grant a signed-in user the admin or owner role - every SSO- or SCIM-provisioned account is created as a plain member.

OIDC (Okta)

The console asks for three values: the issuer (an https:// URL, e.g. your Okta domain), the client ID, and the client secret (required the first time OIDC is configured, optional after to rotate it). Register the redirect URI below in your Okta application exactly as shown; it is fixed by the gateway and not configurable.

Redirect URI (register this in Okta)
https://api.zer0pii.com/v1/auth/sso/callback

SAML (Microsoft Entra)

The console takes the IdP entity ID, the IdP SSO URL and a PEM-encoded x509 certificate, or a single IdP metadata URL to fill those three automatically. Register the Assertion Consumer Service (ACS) URL below in your Entra enterprise application exactly as shown.

ACS URL (register this in Microsoft Entra)
https://api.zer0pii.com/v1/auth/saml/acs

Both protocols require a non-empty list of allowed email domains; a user signing in with any other domain is refused.

The console's "test connection" button runs a server-side check (OIDC discovery document and JWKS fetch, or SAML metadata fetch) before you rely on a real login.

Source: apps/gateway/core/oidc.py, apps/gateway/api/v1/sso.py, apps/gateway/api/v1/console.py:683-812

SCIM provisioning

zer0pii runs a SCIM 2.0 server that Okta or Microsoft Entra can call to create, list, deactivate and delete users. User resources only - there is no group or team sync.

Base URL

Base URL
https://api.zer0pii.com/v1/scim/v2

Authorization header

Authorization header
Authorization: Bearer <scim_token>

One bearer token per organization, issued and rotated from the console. There is no session or cookie on this path; the token alone determines which organization's members a call can see or change.

Supported operations

  • GET /Users - list, with filter=userName eq "..." and startIndex/count pagination
  • GET /Users/{id} - fetch one user
  • POST /Users - provision a user (always created with the member role; SCIM cannot grant admin or owner)
  • PATCH /Users/{id} - active:false deactivates (same hard-delete-plus-session-wipe as removing a member in the console); active:true on an existing user is a no-op
  • DELETE /Users/{id} - remove a user

Source: apps/gateway/api/v1/scim.py