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

Settings → Integrations connects Jadiroon to other systems. Everyone with access to the page sees the personal Google Meet card. The Workspace Admin also sees API & webhooks, where your ERP, HRIS or security tools are connected to the workspace.

Where to find it

Settings → Integrations (/{slug}/app/settings/integrations).

Google Meet is shown to roles holding the Manage integrations permission (under Settings & integrations).
API & webhooks is shown only to the locked Workspace Admin role, which always signs in with two-factor. Other roles don't see it, even with Manage integrations.

Google Meet

Connect your own Google account to have a Google Meet link created automatically when an interview is confirmed. The card shows which Google account is connected; Disconnect removes it. The connection is personal: each interviewer connects their own account.

API & webhooks

An integration is one external system, such as "Oracle HCM – production". Each integration has:

its own permissions;
one or more API keys, which the system uses to call the Jadiroon API;
webhook endpoints, where Jadiroon sends an event when data changes.

Everything an integration does is recorded in the Audit log as Integration · name.

Workspaces prepared with sample data come with an ERP (demo) integration so you can look around: a key (its value is not usable), a paused webhook endpoint with a few successful, retrying and failed deliveries, a finished bulk job with two failed rows, and five employees linked to erp-demo ids.

The list shows each integration's status (Active or Paused), how many permissions, active keys and endpoints it has, and when one of its keys was last used. New integration asks for a name and an optional description. Open an integration to manage it on four tabs.

Access

Details: rename the integration or change its description.
Permissions: the same matrix as Roles and permissions: View and Act per module, plus named permissions. The integration reads and writes with exactly these permissions, under the same rules as a person using the app. Its data scope is always the whole workspace. For example, without See candidate contact details its candidate emails and phone numbers are masked, and without Hire candidates it can't hire. Audit log View lets it read the audit feed and subscribe to the audit-feed webhook event. Removing a permission also drops the webhook deliveries still waiting to be sent to its endpoints (they show as Failed, scope changed): they were prepared with the old permissions. Re-read with updatedSince to catch up.
IP allowlist: one IP address or CIDR range per line (such as 203.0.113.10 or 10.20.0.0/16). When the list has entries, requests from any other address are refused. Leave it empty to allow any address. An invalid entry, or a /0 range, is pointed out under the field and nothing is saved.
Status: Pause integration refuses every key of the integration and holds its webhook deliveries until you Resume it. Nothing is deleted.
Delete integration: after you confirm, the integration is deleted with its keys, endpoints, delivery log and bulk jobs. The connected system stops working at once.

API keys

New key asks for a name (for example "sync server") and an optional expiry date. The key stops working at the end of that day.

The list shows each key's name and prefix (such as jdr_live_t7Q…), when it was created and last used, its expiry, and whether it is Active, Expired or Revoked. Revoke asks for confirmation; from then on, every request with that key is refused. It can't be undone.

Rotating a key: issue a new key, switch your system to it, then revoke the old one. An integration can hold several active keys at once, so there's no downtime.

Webhooks

Add endpoint asks for:

Endpoint URL: a public https address in your system that accepts JSON POST requests. Private, internal and local addresses are refused.
Events:
- All resource events covers every resource event, including ones added later. It doesn't cover the audit feed.
- Specific events lets you pick events grouped by resource (org units, positions, employees, candidates, applications, and so on). If the integration can't read a resource, that group is greyed out with a note: its events wouldn't be sent, so give the integration that resource's View permission first.
- Audit feed (audit.recorded) is listed apart and is unticked by default. It sends every audit log entry as its own event, for security monitoring (SIEM). You can tick it only when the integration holds Audit log View.

When the endpoint is added, its signing secret is shown so you can copy it into your system.

Each endpoint card shows its URL, its status (Active, Paused or Disabled) and its events, with these actions:

Send test event: sends a ping event now and tells you whether your system accepted it. It needs both the endpoint and the integration to be active.
Edit: change the URL or the events.
Pause / Resume: while paused, new events are not sent and not queued for later; deliveries already pending are held and retried once the endpoint is active again.
Delete: asks for confirmation, then deletes the endpoint and its delivery log.
Secret and delivery log: opens the signing secret and the delivery log (below).

Signing secret: every delivery carries a Jadiroon-Signature header, signed with this secret (HMAC-SHA256). Your system should check it before accepting the delivery. Reveal shows the secret, with a Copy button. Rotate secret creates a new one after you confirm. The old secret stays valid for 24 hours, and deliveries in that window carry both signatures, so you have a full day to update your system. The card shows when the overlap ends. You can't rotate again until then (a second rotation would drop the first secret before your system switched).

Failures and auto-disable: a delivery that your system doesn't accept with a 2xx response is retried with growing gaps, for up to 3 days. While deliveries keep failing, the card shows a "failing since" note. After 3 days of continuous failure, the endpoint is disabled and Workspace Admins are notified. Fix your receiver, then use Re-enable.

If an endpoint subscribes to the audit feed but the integration has since lost Audit log View, the card flags it: nothing from the audit feed is sent. Add the permission back on the Access tab, or edit the endpoint to remove the event.

Delivery log: the newest deliveries first, 50 at a time, filterable by status:

Succeeded: your system accepted it.
Pending: waiting for its next attempt (Retrying after a failure).
Failed: a test event that wasn't accepted, or a pending delivery dropped because the integration's permissions or the endpoint's events were narrowed (response shown as scope changed).
Gave up: no retries left.

Each row shows the event type and id, the number of attempts, your system's last response code, the duration and the next attempt. Open a row to see the first 500 characters of your system's response. Redeliver sends the event again now, as a new row, rendered with the integration's current permissions; it needs the endpoint and the integration to be active, and it is refused when the endpoint no longer subscribes to that event or the integration can no longer see it. Deliveries are kept for 30 days.

Bulk jobs

A read-only list of the bulk upsert jobs this integration sent: resource, status (Queued, Running, Done, Failed), progress, succeeded and failed counts, the key prefix used, and when the job was sent and finished. Results opens the outcome of each row. Failed rows are shown first, with the error code and message. Row index 0 is the first row of the request. Row results are kept for 7 days.

Audit

Every change on this page is recorded in the Audit log: creating, editing, pausing and deleting an integration, permission changes (with what was added and removed), keys issued and revoked, endpoint changes, secret rotations and reveals, test events and redeliveries. Keys and secrets themselves are never written to the log.