Open the API and webhooks

01In a nutshell #sec_13e9f74d

The REVIEWIT API allows your SIEM, BI, ITSM or IGA tools to directly consume campaigns, decisions and audit trail; webhooks push events to them — each client with its own credentials, each webhook with its own secret.

02Where #sec_1398f612

Settings, tab Integrations & AI: API Clients and Webhooks. The two screens share an edition capability: if your subscription is not in an edition that includes it, the screen says so — API access is included with the edition … — and offers Compare editions or contact your contact.

03Before opening #sec_c6be4ab0

An API client is a technical account with a scope. The three questions to ask before creating it are the same as those asked of a service account:

1. Which tool? One client per tool, named after it. Never a 'generic' client

shared between three teams.

1. Read or write? *Each client receives its own credentials and its own read or write scopes.* A reporting tool does not write anything.

1. Secret or certificate? OAuth2 client credentials — secret or certificate, at your choice. The

certificate avoids having a secret to circulate.

04Create an API client #sec_ef367d47

New API client. A name, the authentication mode, the scopes, an expiration. Upon creation, the secret is displayed only once; Copy puts it on the clipboard. It will not be visible afterwards: store it in the tool's safe that uses it before closing the panel.

The list then carries each client: name, auth (Secret or Certificate), status, last use, created on, expiration. Two columns to read regularly: a client never used is an open access for nothing; a client close to expiration will break an integration one morning.

Three gestures: Detail, Rotation — Rotation of the secret: the old one ceases to be valid — and Revoke.

The complete documentation of the API — authentication, pagination, rate limits, and each call point — is in the API Reference chapter of this portal.

05Create a webhook #sec_1542805b

Webhooks push campaign, decision, and deletion events to your ITSM, SIEM, or automation tools — HMAC-signed payloads.

New webhook: a receiving URL, the events to receive — campaign launched or completed, access revoked, challenge opened, deletion requested — and a signature secret, displayed once too. Your receiver checks the signature of each delivery with this secret; an unsigned or incorrectly signed delivery does not come from REVIEWIT.

The list shows for each webhook its events, its status, last success and last failure. Deliveries opens the history, delivery by delivery.

06When a webhook dies #sec_59b75620

A receiver that no longer responds ends up being cut off: 20 consecutive dead-lettered deliveries — the endpoint seems dead. The webhook switches to Auto-deactivated. Nothing is lost on the REVIEWIT side, but nothing is delivered either.

The recovery gesture is written on the screen: perform a secret rotation to reactivate after repair. The rotation is clear: the current secret stops verifying immediately — no overlap. Repair the receiver first, then rotate the secret, then put the new secret in the receiver.

07Delete #sec_d839318b

Deleting a webhook places it in Deleted items: its URL and events can be restored until the … — its secret, no. A restored webhook restarts with a new secret.

08Hygiene #sec_8913bb12

09What this page does not cover #sec_3424cfd8

The continuous diffusion of the audit trail to a SIEM is neither an API client nor a webhook: it is BEACON, with its own guarantees of order and proof. This is the next page.

10To remember #sec_4cc007e0

One client per tool, one secret seen once, scopes as precise as possible. A signed webhook, monitored by its two dates, reactivated by rotation. And everything that is no longer used is revoked — a technical access is recertified like the others.