Jadiroon Docs · دليل جديرون

Integrations in the Platform Console manages deployment-level read integrations: an entity or holding system that reads every active workspace at once through the API, and receives their events on webhooks. What such an integration can read, and how its data is shaped, is described in Entity-level read. This page covers managing it in the console.

A workspace's own integrations (ERP sync, scoped permissions, bulk jobs) are different: the workspace's Workspace Admin manages them in Settings → Integrations.

Who can use it

Integrations appears in the console sidebar only for super admins whose console role holds Integrations Act (integrations.act). The locked Owner role holds it. Viewers and other roles don't see the section, and opening /admin/integrations sends them to their first allowed console page. The console routes behind it return 403 without that permission, for reads too.

Creating an integration

Integrations → New integration.
Enter a Name (for example "Holding BI – production") and an optional Description.
Enter the IP allowlist: one IP address or CIDR range per line (for example 203.0.113.10 or 10.20.0.0/16). It is required. A range covering every address (/0) is refused, and invalid entries are listed under the field.
Create. The integration opens on its Settings tab.

The list shows each integration's status, active key and endpoint counts, and how many allowed IPs it has. An integration without an allowlist is flagged: its keys are refused.

Settings

Details: name and description.
IP allowlist: required. You can change it, but you can't save it empty. Keys work only from the listed addresses.
Status: Pause integration refuses every key for now and holds its webhook deliveries; Resume integration turns it back on. Nothing is deleted.
Delete integration: deletes it with its keys, webhook endpoints and delivery log, after an in-app confirmation. The connected system stops working at once.

There is no permission picker: a deployment-level integration always reads everything, read-only.

API keys

API keys → New key.
Name the key after where it is used, and pick an Expiry date. The expiry is required: the key stops working at the end of that day.
Issue key. The full key (jdr_live_…) is shown once, in a copy box. Copy it into your secrets manager. The dialog closes only with I've stored it, close; Jadiroon keeps only a fragment to recognise it.

If the integration has no IP allowlist yet, the tab says so and the key can't be issued (ip_allowlist_required); Open Settings tab takes you to the allowlist. The key list shows each key's prefix, creation date, last use, expiry and status (Active, Expired, Revoked). To rotate a key: issue a new one, switch the system to it, then Revoke the old one.

Webhooks

Add endpoint takes a public https URL and the events to send:

All resource events (*), which includes events added later, or Specific events, picked per resource (org units, positions, employees, candidates, openings and the rest).
Audit feed (audit.recorded), listed apart and unticked by default. It sends every audit log entry of every active workspace, plus platform entries (console actions), as its own event. A deployment-level integration may always pick it; it is never part of "All resource events".

Only *, audit.recorded and event types from the event catalog are accepted; any other type is refused (unknown_event_type). When you edit an endpoint and untick event types, its pending deliveries of those types are dropped (marked failed, scope changed).

URL problems (not https, a private or local host, a host outside the deployment's allowed hosts) are shown under the field. After Add endpoint, the signing secret (whsec_…) is shown with a copy box.

Each endpoint card has:

Send test event: sends a ping to this endpoint only and shows the result. It needs the endpoint and the integration to be active.
Edit, Pause / Resume, and Delete (with confirmation).
Re-enable: after 3 days of failed deliveries the endpoint is disabled automatically and every console Owner gets an email naming the integration and the endpoint host, with a link to this page; fix the receiver, then re-enable it.
Secret and delivery log: Reveal the signing secret, or Rotate secret. After a rotation the previous secret keeps signing for 24 hours: every delivery in that window carries two signatures, so the receiver can switch over without losing a delivery.

Endpoints receive events from every active workspace. Every envelope carries workspaceId (see Entity-level read).

Delivery log

The log lists the endpoint's deliveries, newest first, kept for 30 days. Filter by status (All, Succeeded, Pending, Failed, Gave up). Each row shows:

the event type and id;
the workspace it came from (name and id), or Platform for a test event or a platform audit entry;
status, attempts, the receiver's response code and duration, time and next attempt.

Open a row to read the receiver's response (first 500 characters). Redeliver sends the same event again as a new delivery, attempted at once.

What is recorded

Every change is written to the console's Activity log: integration created, updated or deleted; key created or revoked; endpoint created, updated, deleted, tested or secret rotated; delivery redelivered. Keys and secrets are never written to the log. API reads made with the key are not recorded.

Console integrations: deployment-level read