Your security team can collect Jadiroon's audit log in its SIEM (Splunk, Microsoft Sentinel, QRadar, Elastic, …): every change made in the app or through the API, sign-ins, data exports and super-admin activity, with who, what, which record, before and after, IP address and user agent. There are two ways to get it, and you can use both.
| Pull: audit feed | Push: audit.recorded webhook | |
|---|---|---|
| How | Poll GET /api/v1/audit-events | Jadiroon POSTs each row to your endpoint |
| Latency | Your polling interval | Seconds |
| Catch-up after an outage | Any time (rows are kept as long as the audit log) | Retries with backoff for several days (see Retries), events kept 30 days |
| Permission | audit.view | audit.view, and audit.recorded picked on the endpoint |
Both carry the same object; it is described on the Audit events reference page.
Pull: polling the feed
- Create an integration for the SIEM with only
audit.view(addrecruitment.candidate.contactonly if the SIEM may hold candidate contact values; without it they read[redacted]). - First run: page through
GET /api/v1/audit-events?limit=100from the start, followingnextCursoruntil it isnull. - Store the
occurredAtof the last row. - Every few minutes: call again with
updatedSince= that stored time, and skip ids you already have (rows at exactly that time come back).
Rows come oldest first and never change, so the feed is append-only from your point of view.
Push: the audit.recorded event
- In Settings → Integrations → (integration) → Webhooks, add an endpoint (your SIEM's HTTP collector, behind a small receiver that verifies the signature) and tick
audit.recorded. It is listed separately and is not included in*. - Each audit row is sent as one event,
data.object= the audit row. - Verify the signature and deduplicate by event id as described on Webhooks.
Use the pull feed as the backfill whenever the endpoint was down longer than the retry window.
What the feed contains, and what it doesn't
- Contains: every mutation (app, API, automation), sign-ins (
auth.signed_in), password changes, data exports (audit.log.exported,people.participation.exported, …), integration key and endpoint changes (settings.integration.*), and actions by Jadiroon super admins inside your workspace. - Does not contain API reads. Reading through the API is not audited, so the feed shows what your integrations changed, not what they read.
- Secrets (passwords, tokens) are blanked when the row is written. Candidate contact values are masked at read time unless the key holds
recruitment.candidate.contact, and pay changes (positions, job descriptions, pay scales), pay ids and amounts stored at the top level ofmetadata(for example on a position or opening creation) andmetadata.gradeCodeare left out unless it holdsstructure.functional.salary.
Mapping to SIEM fields
| SIEM field | Audit row |
|---|---|
| Event time | occurredAt |
| Event id | id (pull) or the event id (push) |
| Action / event type | action |
| User / principal | actor.type, actor.id, actor.name (integration actors also carry metadata.actorIntegration.keyPrefix) |
| Object | target.type, target.id, target.label |
| Source IP, user agent | ipAddress, userAgent |
| Details | metadata (for example changes with { from, to }) |
Entity-wide collection
On a dedicated deployment, an entity or holding SIEM can read every workspace's audit rows through one deployment-level read integration. Its feed also includes platform rows (workspaceId: null): Platform Console actions such as workspace creation, super-admin entries and exits, console role and integration changes, and failed console sign-in attempts (admin.login_failed). Filter on action if you only want some of them.