What webhooks do
Company and agency webhooks send event notifications from Requidex to another system when selected activity happens. Instead of polling the Open API for changes, your receiving system gets a POST request shortly after a supported event occurs.
Use webhooks for event-driven workflows such as updating an external system when a requisition is created, notifying a middleware platform when an assignment is confirmed, or starting a downstream process when a timesheet is ready for approval.
Scope and access
Webhooks are configured from the Integrations section of a company or agency detail page. They are not configured from a user's Integrations page.
Company webhooks are available by default. Agency webhooks are available only when the agency-webhooks feature is enabled for that agency; otherwise the Integrations section is hidden on the agency detail page.
A webhook belongs to exactly one company or agency. Requisition created, Requisition approved, and Worker submitted to Requisition are company-only events. Requisition received is an agency-only event. Requisition cancelled and filled events are available in both scopes, with agency delivery limited to relevant requisitions. Requisition worker rejected and assigned events are delivered to the affected worker's agency. Assignment and timesheet events are available in both scopes but agency webhooks receive them only for work supplied by that agency.
Expenses, invoices, and credit notes are available to hirers for their company records and to agencies for records belonging to their agency. MSP-to-client invoices and credit notes are excluded from agency delivery. Invoice events exclude drafts and applications for payment (AFPs).
Purchase order, trade, and rate webhooks are company-only and are not offered in agency webhook settings. Purchase order endpoints do not accept agency-scoped API keys. Trade and rate webhooks cover company configuration, including shared and agency-specific rate cards; they are restricted to the hiring company.
Where to configure them
Open the company or agency detail page for the organisation that should receive events.
Select Integrations.
Select the Webhooks tab.
Choose New Webhook from the page actions menu.
Enter a name and the endpoint URL that should receive events.
Select one or more event types.
Leave Active selected if the webhook should start receiving events immediately.
Save the webhook. Requidex generates the signing secret automatically.
Webhook settings
Name: a label for the webhook in Requidex.
Endpoint URL: the http or https URL Requidex will POST the selected events to. Company and agency webhook endpoint URLs can contain up to 512 characters. Use HTTPS wherever possible.
Signing secret: generated automatically by Requidex. Open the webhook edit dialog to view it; it is masked by default until you choose to reveal it.
Description: optional context for what the webhook is used for.
Custom headers: optional headers to include with delivery requests, such as partner or routing identifiers.
Event types: the Requidex events that should trigger this webhook.
Active: disabled webhooks stay configured but do not receive event deliveries.
Send test event: sends a test delivery for one of the event types configured on the webhook.
Logs: opens the delivery log for a webhook.
Export logs: exports the company or agency webhook delivery logs for the selected date range.
Delete: removes the webhook and its delivery logs.
Supported events
Requisition created: company only; sent when a requisition is created.
Requisition approved: company only; sent when a requisition approval stage is completed.
Requisition received: agency only; sent when a requisition is released to that agency manually, after final approval, or through a scheduled tier release.
Requisition cancelled: sent when a requisition is cancelled; agency delivery is limited to agencies that received or responded to it.
Requisition filled: sent when a requisition becomes filled; agency delivery is limited to agencies that received, responded to, or supplied it.
Worker submitted to Requisition: company only; sent when an agency submits one or more new workers in its initial response or a later amendment.
Requisition worker rejected: sent when a submitted worker is rejected; agency delivery is limited to the agency that submitted that worker.
Requisition assigned: sent when workers are assigned; agency delivery is limited to agencies supplying the affected workers.
Assignment created: sent when an assignment is created.
Assignment confirmed: sent when an assignment is confirmed.
Assignment cancelled: sent when an assignment is cancelled.
Assignment reinstated: sent when a cancelled assignment is reinstated.
Assignment ended: sent when an assignment is ended, including when it is ended as part of a permanent replacement.
Assignment dates updated: sent when assignment dates are changed.
Assignment rates updated: sent when assignment rate values or uplifts are changed, including bulk rate changes. Pay type and rate type changes do not send this event.
Assignment shift updated: sent when the assignment shift pattern is changed.
Assignment trade updated: sent when the assignment trade is changed.
Timesheet approval requested: sent when a timesheet is submitted for approval.
Timesheet approved: sent when a timesheet is approved.
Timesheet cancelled: sent when a timesheet is cancelled by raising its credit note.
Timesheet unapproved: sent when a timesheet is unapproved.
Timesheet amended: sent when a timesheet is amended.
Timesheet deleted: sent when a timesheet is deleted.
Timesheet marked absent: sent when a timesheet is marked absent.
Expense created: sent when an expense is created.
Expense rejected: sent when an expense is rejected.
Expense approved: sent when an expense is approved.
Expense amended: sent when an expense is amended.
Expense deleted: sent when an expense is deleted.
Invoice created: sent when an invoice is created. Draft invoices and applications for payment (AFPs) do not send invoice events.
Invoice paid: sent when an invoice is paid. Draft invoices and applications for payment (AFPs) do not send invoice events.
Credit note created: sent when a credit note is created.
Credit note processed: sent when a credit note is processed.
Purchase order created: company only; sent when a purchase order is created.
Purchase order amended: company only; sent when a purchase order is amended.
Purchase order expired: company only; sent when a purchase order is expired.
Purchase order deleted: company only; sent when a purchase order is deleted.
Trade created: company only; sent when a trade is created, including imports.
Trade amended: company only; sent when trade details change or a trade is re-enabled. Disabling sends Trade disabled instead.
Trade disabled: company only; sent when an active trade is disabled.
Rate created: company only; sent when a company, project, tier, or agency-specific rate card is created, including parent cards seeded during an import.
Rate amended: company only; sent when an existing rate card is amended, including imports.
Payloads and full records
Webhook payloads are intentionally small. Each payload includes an event id, event type, created timestamp, and the full object ID of the affected Requidex object.
Use the object ID in the data object to fetch the full record from the Open API. For requisition events, use data.requisition.id with GET /requisitions/{id}. For assignment events, use data.assignment.id with GET /assignments/{id}. For timesheet events, use data.timesheet.id with GET /timesheets/{id}.
The webhook event reference pages in the Open API docs show each payload shape and link to the matching full-object endpoint.
Expense, invoice, credit note, and purchase order IDs appear in data.expense.id, data.invoice.id, data.creditNote.id, and data.purchaseOrder.id respectively. Fetch them from GET /expenses/{id}, GET /invoices/{id}, GET /credit-notes/{id}, and GET /purchase-orders/{id}. Deleted events retain the object ID, but the deleted record can no longer be fetched.
Trade and rate events use data.trade.id and data.rate.id. Hirer integrations can fetch the full records from GET /trades/{id} and GET /rates/{id}.
Delivery and security
Requidex sends each webhook as a POST request with Content-Type application/json. Delivery is at least once, so your receiver should be idempotent and safe to process the same event id more than once.
Each delivery includes X-Requidex-Event, X-Requidex-Event-Id, X-Requidex-Timestamp, and X-Requidex-Signature headers. Use the signing secret to verify that the payload came from Requidex before processing it.
Requidex records webhook delivery events, including delivery time, status, response code, attempts, and error details. Use the Logs row action on the Integrations page to review delivery history, or Export logs from the page actions menu to download webhook logs for a date range.
Common uses
Trigger a workflow in an integration platform when a requisition is approved.
Notify an external scheduling, finance, or reporting system when an assignment or timesheet changes state.
Keep a data warehouse or internal service up to date by fetching the full object from the Open API after receiving the event.
Route selected Requidex lifecycle events into a custom middleware service for enrichment or audit logging.
Troubleshooting
If no events arrive, confirm the webhook is Active and that the relevant event type is selected.
If deliveries fail, open Logs from the webhook row action menu and check the delivery status, response code, and error.
Use Send test event from the webhook row action menu to confirm the receiving endpoint and signing setup before relying on live events.
Confirm your endpoint can receive POST requests from Requidex and returns a 2xx response.
If signature verification fails, confirm you are using the current signing secret and verifying the raw request body.
If your receiver sees duplicate events, de-duplicate by X-Requidex-Event-Id or the payload id.
For agencies
When agency webhooks are enabled for their agency, agency administrators can create and manage them from the agency detail page by selecting Integrations. The signing secret and delivery logs remain scoped to that agency.
Requisition received events are delivered only when the requisition is actually released to your agency. Selecting your agency before internal approval does not send the event.
Requisition cancelled and filled events are delivered only for requisitions your agency received, responded to, or supplied, as applicable.
Worker submitted events are company-only and are not available to agency webhooks. Worker rejected and requisition assigned events are delivered only when your agency supplied the affected worker.
Assignment and timesheet events are delivered only when your agency supplies the assignment or timesheet.
Use an agency-scoped Open API key when your receiving system needs to fetch the full record referenced by a webhook payload.
Purchase order, trade, and rate events are company-only. They cannot be selected, saved, or tested on agency webhooks, and existing agency subscriptions do not receive those events.