Application developer
Decides how to handle a notification safely in code.
Job: design a consumer that re-checks before acting.
Respond to identity and authority changes with governed events.
Connect identity systems and applications to event-driven trust workflows. Learn how changes to identities, delegated authority and trust signals can be represented as notifications—while policy decisions and audit evidence remain governed by their authoritative systems.
What are webhooks and events in Zoiko iD?
Webhooks and events are a proposed integration pattern for informing subscribed systems about relevant identity, authority and trust changes. A notification is not proof that access should be granted: consequential actions still require current policy and authority checks, and the underlying audit evidence belongs to the authoritative service.
01
Notifications, not reads
A notification says something changed. Reading current state is a separate API call.
02
Not an authorization decision
Receiving an event never replaces a current, authoritative policy check.
03
Evidence stays with its owner
The authoritative service holds the audit record. A notification refers to it.
Four roles, four jobs
Each role uses this page for a different decision. None of these roles is granted access by reading it.
Platform engineer
Plans throughput, retries and reconciliation for production.
Job: confirm the published delivery contract.
Security engineer
Reviews origin verification, secrets and tenant boundaries.
Job: approve the security controls before go-live.
Enterprise architect
Assesses how events fit alongside an existing identity estate.
Job: decide whether an overlay design fits.
Six conceptual categories
Each category describes a kind of change. None is a list of event names. Exact event types are published only after the approved Event Registry confirms them.
Conceptual
Identity lifecycle
Changes to an actor identity or a verified relationship.
Conceptual only until approved Event Registry confirms exact event types.
Conceptual
Delegated authority
Changes in representation, scope, mandate or expiry.
Conceptual only until approved Event Registry confirms exact event types.
Conceptual
Policy outcomes
Relevant controlled decisions. Not a replacement for a live check.
Conceptual only until approved Event Registry confirms exact event types.
Conceptual
Trust signals
Context changes used to re-evaluate an action before it proceeds.
Conceptual only until approved Event Registry confirms exact event types.
Conceptual
Revocation
Withdrawal or expiry of scoped authority or access. Treat it as a reason to re-check.
Conceptual only until approved Event Registry confirms exact event types.
Conceptual
Evidence reference
Pointers to source-governed decision records held by the owning service.
Conceptual only until approved Event Registry confirms exact event types.
Who does what
1
Producer
The owning system records a change.
Owning service
2
Verification
The subscriber checks that a notification is authentic before trusting it.
Subscriber
3
Dispatch
A notification is sent to subscribed endpoints. Timing is not guaranteed.
Platform
4
Subscriber
Your system receives and records the notification.
Your system
5
Application action
Your application re-checks current authority and decides what to do.
Your system
6
Evidence
The owning system keeps the authoritative record.
Owning service
Five design steps, no code required
1
Receive without trusting
Accept the notification, then verify it before reading its contents.
2
Deduplicate
Record processed identifiers so a repeat does not trigger a second action.
3
Re-check current state
Query the owning service before any consequential change.
4
Act within your own policy
Your application decides the outcome under its own rules.
5
Keep your own record
Log the identifier and outcome, and point back to the owner's evidence.
What must be approved before go-live
Each gate has a named owner. A gate that is not met keeps its feature hidden or marked pending.
| Gate | What it confirms | Owner |
|---|---|---|
| Event Registry | Exact event types and schemas are published and versioned. | Engineering with Product |
| Delivery contract | Ordering, retry, expiry and reconciliation terms are stated. | Platform engineering |
| Security review | Origin verification, secret handling and tenant boundary approved. | Security |
| Accessibility QA | This page and its components meet WCAG 2.2 AA. | Front-end and QA |
| Route registry | Every link resolves to an approved destination. | Web platform |
Documented slots, contracts pending
Each area has a documented slot. The contract for each is pending publication by the owning team, so no values are shown here.
| Area | What this page says | Status |
|---|---|---|
| Ordering | Global order is not implied. Compare timestamps before applying changes. | Contract pending |
| Duplicates | Design consumers to handle repeats. Deduplicate using the verified event identifier. | Contract pending |
| Retries and expiry | Set by the published contract. Keep handlers responsive and queue slow work. | Contract pending |
| Missed events | Reconcile from the approved query path if one is published. Alert on gaps in your own records. | Contract pending |
No delivery guarantee is stated on this page. Ask an identity expert for the current contract for your environment.
A governed technical boundary
Origin verification
Verify each notification's origin before reading its contents.
Security approval pending
Secret handling
Keep verification secrets in a secret manager. Never publish them in examples or logs.
Engineering gated
Key rotation
Rotation procedures are documented once the approved contract is published.
Engineering gated
Encrypted transport
Design requirement: deliver only to encrypted endpoints. Not a verified product claim.
Design requirement
Replay resistance
Design requirement: reject stale notifications. Tolerance is set by the contract.
Design requirement
Tenant boundary
Subscriptions are authorized server-side. Possessing an endpoint is not authority.
Server-side enforced
Never place a secret in a public example, support request, or analytics event.
How subscriptions are scoped
Subscriptions are configured in an authenticated, authorized console once it is available to your account. The panel opposite is a conceptual example, not a working control.
Subscription setup previewConceptual example
EndpointYour HTTPS endpoint
Event categoriesChoose by category
Tenant scopeSet server-side
StatusNot available in this preview
No change is saved from this page.
Schema explorer
Event families appear here only with an approved schema. Until then, each shows as pending. No example is generated or guessed.
Schema pending publication
Identity lifecycle
Version: not publishedSchema not published. Contact your identity expert for the current contract.
Schema pending publication
Delegated authority
Version: not publishedSchema not published. Contact your identity expert for the current contract.
Schema pending publication
Policy outcomes
Version: not publishedSchema not published. Contact your identity expert for the current contract.
No published event schemas match the filter “Verified schema.” Once a schema is approved, its version, status and last-reviewed date will appear here with a read-only sample.
Testing guidance
Published technical guidance covers approved test tooling only.
Explore testing guidance
Published technical guidance for approved test tooling.
Sandbox status: not confirmed as active.
Ask about evaluation options.
No live test events are sent from this page. Any test must use synthetic records and cannot trigger live changes.
A notification is not the audit record
Each notification can carry an event identifier and request context, so you can correlate it with your own logs. The authoritative audit evidence stays in the owning system.
Notification
Tells a subscriber that something changed. Used to trigger a check. Not proof of an action.
Informational
Audit evidence
The governed record held by the owning service. Reviewed through its own authorized route.
Authoritative in owning system
Scenarios, with their limits
Human access
Sync access in your directory when a person's credential status changes.
Scope: re-check access against current policy before changing sessions.
Partner delegation
Track delegations to external partners and update your own records when scope changes.
Scope: the partner's access is decided by the owning authority, not by the notification.
Machine lifecycle
Queue renewals and pause dependent services when a machine identity is revoked.
Scope: availability of machine identity events is not confirmed for every family.
AI-agent control
Respond to a sponsor's withdrawal of a mandate by stopping the agent's next action.
Scope: agent event families are not claimed as available until confirmed.
Terms used on this page
Event
A recorded change in an identity, authority or trust state.
Notification
A message that tells a subscriber a change occurred. It is not proof.
Subscriber
The system that receives notifications & decides its own action.
Evidence
The authoritative record, held by the service that made the decision.
Talk to an identity expert about event-driven integration.
Share your identity estate, the events you need, and your constraints. An expert will confirm what is available for your environment.
Frequently asked questions
Do webhook notifications authorize access?
No. A notification only signals that an identity, credential, or authority state change has occurred. Receiving an event never replaces a current, authoritative policy check. Consumers must re-query the owning service before executing any consequential action.
Can I replay missed events?
Replay and reconciliation capabilities depend on the published delivery contract for your environment. While event identifiers and timestamps allow local deduplication, historical catch-up queries are handled through approved query APIs.
Are AI-agent and machine identity events supported?
Events for machine identities, workloads, and AI-agent delegation mandates are conceptual event families currently pending formal publication in the approved Event Registry.
What happens if an event arrives more than once?
Consumers must be designed to be idempotent. You should record processed verified event identifiers so that duplicate deliveries do not trigger repeated actions or state mutations.
Are payloads signed?
Yes. In the governed security model, webhook notifications require origin verification (such as HMAC signatures with pre-shared secrets or asymmetric signatures). Always verify the signature before parsing or acting upon the payload.
How do I know which versions apply?
Event schemas, versions, and lifecycle status are maintained in the official Event Registry. Once a schema reaches 'Verified' status, its version and breaking change policy are formally documented.