generated: '2026-08-29' method: searched source: >- https://docs.strivacity.com/docs/lifecycle-event-hooks , https://docs.strivacity.com/docs/event-streaming , https://docs.strivacity.com/docs/account-events , derived from openapi/_original/strivacity-admin-portal-openapi-original.json asyncapi_spec_published: false asyncapi_note: >- Strivacity publishes no AsyncAPI document. Probed /asyncapi.yaml and /asyncapi.json on the docs and marketing hosts and searched the GitHub org — nothing. The event surface below is real and documented, it is simply described in prose and in the Admin API rather than in an event contract. mechanism_warning: >- READ THIS BEFORE TREATING THIS AS A WEBHOOK CATALOGUE. Strivacity does NOT offer HTTP webhook subscriptions in the usual sense — there is no endpoint where an integrator registers a callback URL and receives signed POSTs per event type. It offers two different outbound mechanisms, and the distinction matters to anyone planning an integration. surfaces: - name: Lifecycle Event Hooks kind: in-process extensibility hook docs: https://docs.strivacity.com/docs/lifecycle-event-hooks delivery: >- Brand-authored JavaScript executed inside a sandboxed serverless environment on the Strivacity platform at a named point in the customer lifecycle. The hook itself calls out to the brand's CRM, marketing hub or SIEM. Synchronous hooks can alter or block the flow; asynchronous hooks run fire-and-forget alongside it. signed: not applicable (no outbound HTTP contract from Strivacity) retry: not applicable managed_via_api: true api_operations: - getAllEventHookFunctions - createEventHookFunction - updateEventHookFunction - deployEventHookFunction - deleteEventHookFunction - getEventHookFunctionStatusById - getEventHookLogs - getEventHookLogById - getAllEventHooks events: - id: at-failed-authentication mode: synchronous description: Customer authentication or registration failed; the hook receives the reason and can customize the error, show a custom page, or redirect. - id: at-failed-identification mode: synchronous description: Identification against the identity store failed (account disabled, unactivated, group-restricted, not found); the hook can re-identify, continue to registration, or redirect. - id: after-self-service-login mode: asynchronous description: Successful login. - id: after-consent-update mode: asynchronous description: A customer opted into or out of a consent at registration, self-service or progressive profiling. - id: after-identity-verification mode: synchronous description: The identity verification workflow finished; results can be persisted to the account. - id: after-customer-identification mode: synchronous description: The customer supplied an identifier and before any authentication factor is requested; used to step the flow up or down. - id: after-mfa-change mode: asynchronous description: A customer enrolled or removed an MFA factor. - id: after-registration mode: synchronous description: Account registration completed. - id: after-external-login mode: synchronous description: A customer registered or logged in with a social login provider. - id: after-token-refresh mode: synchronous description: A token refresh succeeded; the response can be inspected before it returns to the client. - id: after-account-update mode: asynchronous description: An account was updated; used to sync to an external identity store. - id: after-account-deletion mode: asynchronous description: An account was deleted; used to sync deletion to an external identity store. - id: before-identity-verification mode: synchronous - id: before-contact-update mode: synchronous description: An email address or phone number is about to be persisted; the hook can validate or block the change. - id: before-external-registration mode: synchronous - id: before-id-token-generation mode: synchronous description: Inject custom claims, or add and remove scopes, before the ID or access token is created. - id: before-saml2-assertion-generation mode: synchronous - id: before-progressive-profiling mode: synchronous - id: before-registration mode: synchronous - id: before-password-validation mode: synchronous description: Used to validate against, or migrate a password from, an external identity store. - id: before-password-reset mode: synchronous - id: before-multi-stage-registration mode: synchronous - id: before-authenticator-enrollment mode: synchronous - id: before-password-persist mode: synchronous - name: Event streaming kind: outbound push to a data platform docs: https://docs.strivacity.com/docs/event-streaming delivery: >- Strivacity pushes events to a configured destination over HTTP. Supported destinations are Splunk and Elasticsearch — the destination is chosen from a vendor list, not an arbitrary callback URL. event_classes: - id: audit-log description: Administrative and system actions inside the instance. docs: https://docs.strivacity.com/docs/audit-logs - id: account-event description: >- Customer activity — login attempts, password changes, MFA codes, and other identity actions. Optionally extended with detailed account event actions (session preferences, authenticator attempts, adaptive risk decisions, external IdP usage, verification failures, invitation and login-hint details). docs: https://docs.strivacity.com/docs/account-events payload_customization: named native claims can be included in the event payload retry: supported: true window: >- Failed events are retried for up to 60 seconds by default; retries resume only after five events have delivered successfully. Configurable per instance via environment variables. managed_via_api: true api_operations: - list_4 - create_6 - getById - update_5 - delete_7 - sendTestEvent test_affordance: POST /admin/api/v1/instance/eventStreaming/{id}/test sends a synthetic event end to end - name: Account event query API kind: pull delivery: Poll the Admin API rather than receive a push. api_operations: - getAccountEvents - getAccountEventById - getDescriptor - getNotificationEvents - getNotificationEventById note: >- getDescriptor returns the machine-readable catalogue of account event types for the instance — the closest thing Strivacity has to a published event schema, and the right place for an agent to discover event types at runtime. agent_note: >- For an AI-agent integration the account event stream is the accountability record: when an agent acts on a customer's account, the event's subject is the account and the actor is the agent's client id, so agent-driven activity is separable from customer-driven activity in both the streamed events and the My Account portal. gap: >- A brand that wants a plain signed HTTP webhook has to write a Lifecycle Event Hook that POSTs to its own endpoint. An AsyncAPI document covering the 24 lifecycle events plus the account-event and audit-log payloads would make this surface machine-readable without changing a line of the product.