innDex
/v1/company/{companyId}/integrations/inndex/webhookOverview
Requidex provides two integration points for connecting recruitment and assignment workflows with innDex:
| Direction | Requidex integration point | Purpose |
|---|---|---|
| Requidex → innDex | Assignment webhooks and Open API read endpoints | Make assignment, worker and project references available to innDex |
| innDex → Requidex | Company-specific induction event receiver | Record induction events and keep company worker IDs aligned with innDex UIDs for Excel timesheet imports |
This page describes Requidex configuration, the events Requidex exposes, and its receiving API contract. Invitation delivery, profile prefilling, induction workflows and site access are managed in innDex and agreed separately with its team.
Requidex configuration
- In Requidex, open Company → Integrations → innDex → Configure.
- Enter the innDex company ID and save. Saving a company ID enables incoming events and worker ID sync.
- Copy the generated webhook credential. It is shown once; provide it securely to whoever configures webhook delivery in innDex.
- Provide the company-specific receiving URL and credential for the agreed event delivery configuration.
- Use Incoming events on the Requidex innDex tab to review delivery processing and resolve conflicts.
To disable the integration, clear the innDex company ID and save. This invalidates the credential. Saving a company ID again generates a new credential. Changing the innDex company ID or selecting Generate a replacement webhook credential also invalidates the previous credential immediately.
For hirers, this connection is configured by an authorised company or MSP administrator. Agencies continue to use their existing worker, assignment and timesheet workflows; the incoming integration belongs to the hiring company.
Events Requidex sends
Requidex exposes webhooks across requisitions, assignments, timesheets, expenses, invoices and other lifecycle events. See the webhook event catalogue for the full list, availability and payload references.
Outgoing subscriptions are configured in Company → Integrations → Webhooks, separately from the innDex receiving endpoint. The selected events determine when innDex is notified; the relevant triggers are agreed with innDex. Different lifecycle events can refer to the same record, so consumers should avoid repeating the same onboarding action.
Assignment webhooks contain data.assignment.id. The Get Assignment endpoint exposes the worker, company and project references. Further permitted information is available from Get Worker. These endpoints use Open API authentication and the API key's access scopes.
Outgoing events use Requidex's existing webhook delivery and signature verification. Their signing secret is separate from the credential for incoming induction events. Webhook consumers must handle repeated deliveries safely.
Events Requidex accepts
The following is Requidex's proposed contract for receiving innDex induction events. The event names, payload and authentication must be agreed with innDex before live delivery. It does not describe or confirm innDex's native webhook format. Where native innDex webhooks are available, the receiving integration should be adapted to their agreed format.
Each event includes the innDex induction ID to correlate notifications for the same induction. Requidex records this reference but does not currently fetch induction details. The innDex API endpoint and authentication for retrieving those details remain to be agreed.
The current receiver accepts the four event types below for existing company workers. Credentials are configured separately for each company and environment.
Environments and company identifiers
| Environment | Incoming webhook URL |
|---|---|
| Stage | https://api-dev.requidex.com/v1/company/{companyId}/integrations/inndex/webhook |
| Production | https://api.requidex.com/v1/company/{companyId}/integrations/inndex/webhook |
This is a dedicated receiving endpoint. Do not add the Open API /api/open/v1 prefix.
| Parameter | Type | Required | Description |
|---|---|---|---|
companyId in the URL | string | Yes | Full 24-character Requidex company ID, available in the incoming webhook URL on the innDex integration page |
The URL's company ID identifies the hiring company in Requidex. The request body's data.companyId identifies that organisation in innDex and must match the value saved in Configure. These are different identifiers.
Authentication
Requidex authenticates incoming requests using these headers:
Authorization: Bearer <WEBHOOK_CREDENTIAL>
Content-Type: application/json
Use the company-specific webhook credential generated in Requidex. An Open API key or a signed-in user's token cannot replace it. This credential authenticates incoming deliveries only; any Open API calls require separate Open API authentication.
Accepted event types
| Event type | Event meaning |
|---|---|
induction_submitted | A worker submits an induction |
induction_approved | An induction is approved |
induction_change_requested | Changes are requested to an induction |
induction_rejected | An induction is rejected |
All four event types use the same request fields and response format. Each distinct event, including each transition between these event types, requires its own event ID. An ID can be reused only for delivery of the same unchanged event.
Request fields
| Field | Type | Required | Description |
|---|---|---|---|
id | string | Yes | Unique event ID, up to 128 characters |
type | string | Yes | One of the four supported event types above |
occurredAt | string | Yes | Actual event timestamp in ISO 8601 format, including a timezone; must not be more than five minutes in the future |
data | object | Yes | Worker, induction and innDex company identifiers described below |
data.companyId | string | Yes | innDex company ID matching the saved Requidex integration configuration; up to 128 characters |
data.requidexWorkerId | string | For worker ID sync | Full 24-character Requidex worker ObjectId; the worker must already belong to the Requidex company in the URL. Omitted, null or blank references are acknowledged as ignored |
data.workerId | string | Yes | innDex worker UID, up to 128 characters; preserve leading zeros |
data.inductionId | string | Yes | innDex induction ID, up to 128 characters; use the same ID across events for the same induction |
id identifies an individual event; data.inductionId identifies the induction it relates to. Multiple events for the same induction must have distinct event IDs and the same induction ID. Event and innDex IDs must be non-empty strings without control characters. Worker references and existing company worker IDs cannot substitute for data.requidexWorkerId. The receiver does not use National Insurance number or email matching.
If data.requidexWorkerId is omitted, null or blank, an authenticated and otherwise valid event returns HTTP 200 with status: ignored and duplicate: false. It does not look up or create workers, create assignments, change data or appear in Incoming events. Repeated deliveries remain ignored. Handling workers originating in innDex is deferred pending a separate design decision. A supplied non-blank worker reference must still be valid.
Request example
Replace the example company, event and worker identifiers with the correct values for the receiving environment. Use the actual event timestamp.
curl --request POST \
'https://api-dev.requidex.com/v1/company/67bc36db80a1616ec3f47001/integrations/inndex/webhook' \
--header 'Authorization: Bearer <WEBHOOK_CREDENTIAL>' \
--header 'Content-Type: application/json' \
--data '{
"id": "unique-inndex-event-id",
"type": "induction_approved",
"occurredAt": "2026-10-21T10:00:00Z",
"data": {
"companyId": "inndex-company-id",
"requidexWorkerId": "67bc36db80a1616ec3f47002",
"workerId": "000123",
"inductionId": "site-induction-000456"
}
}'
Response fields
An accepted event returns HTTP 200 with this shape:
{
"eventId": "unique-inndex-event-id",
"status": "success",
"message": "Company worker ID updated",
"duplicate": false
}
| Field | Type | Description |
|---|---|---|
eventId | string | The submitted event ID |
status | string | success, conflict or ignored; describes worker ID sync, not induction approval |
message | string | Explanation of the processing result |
duplicate | boolean | true when this event was already processed; the prior result is returned without reapplying worker updates |
| Sync result | Meaning | Action |
|---|---|---|
success | The company worker ID was updated or already matches | Delivery is complete |
conflict | The worker does not belong to the company, an existing ID conflicts, an ID is already used by another worker, company ID entries are ambiguous, or conflicting IDs have the same timestamp | Review the worker and result under Incoming events; correct the underlying issue before selecting Retry sync |
ignored | No Requidex worker ID was supplied, or a newer successfully synced event already exists for this worker | Delivery is complete; missing-reference events make no changes and are not logged, and older events cannot revert the worker ID |
A success result for induction_rejected means the worker ID is up to date. It does not mean the induction was approved.
Errors and retries
| HTTP status | Meaning | Action |
|---|---|---|
400 | Invalid event fields, unsupported event type, innDex company mismatch, or an event ID reused with changed content | Correct the request; do not reuse an existing event ID for a different event |
401 | Missing/invalid webhook credential or a disabled integration | Check the environment, company URL, credential and saved integration configuration |
403 | The Requidex company is inactive | Contact the company administrator |
500 | Temporary processing or storage failure | Retry with the same event ID and unchanged payload |
Retry temporary network failures and HTTP 5xx responses. Repeated delivery is safe when both the event ID and payload are unchanged. Do not indefinitely retry an HTTP 200 result with status: conflict; that event has been received and recorded for manual review.
Worker linking and timesheets
Each supported event with a Requidex worker ID links an existing worker's company worker ID to the innDex UID and aligns the copied worker IDs on that company's assignments and timesheets. Other companies' worker IDs are preserved.
An existing conflicting ID is held for review. A newer event can replace a previously linked innDex UID when the current company worker ID still matches the last successfully linked value. Older successfully superseded events cannot revert the ID.
Events do not create workers or assignments, change assignment status, send invitations, or approve/revoke compliance, site access or timesheets in Requidex. For events with a Requidex worker ID, the event type is recorded in Incoming events so induction decisions can be distinguished from sync results.
Time continues to be exported from innDex to Excel and imported through the existing Requidex timesheet import process. The innDex UID must match the company's worker ID, and the remaining import references must identify the correct assignment.