What webhooks do
Company webhooks send event notifications from Requidex to another system when selected activity happens for that company. Instead of polling the Open API for changes, your receiving system gets a POST request shortly after a supported event occurs.
Use company 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 in company context from the company detail page. They are not configured from a user's Integrations page.
A webhook belongs to one company. Users who can manage webhooks for that company can view and manage the company's webhook configuration.
Where to configure them
Open the company detail page for the company that should send events.
Select Integrations from the sidebar.
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 company's selected events to. 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's webhook delivery logs for the selected date range.
Delete: removes the webhook and its delivery logs.
Supported events
Requisition created: sent when a requisition is created.
Requisition approved: sent when a requisition is approved.
Assignment created: sent when an assignment is created.
Assignment confirmed: sent when an assignment is confirmed.
Timesheet approval requested: sent when a timesheet is submitted for approval.
Timesheet approved: sent when a timesheet is approved.
Payloads and full records
Webhook payloads are intentionally small. Each payload includes an event id, event type, created timestamp, and the id of the affected Requidex object.
Use the 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.
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 company Integrations page to review delivery history, or Export logs from the page actions menu to download company 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
Webhooks are a hiring-company integration. They are created and managed by the hiring company in company context, so agency and desk users do not configure or receive company webhooks themselves.
Several supported events relate to work you supply, such as assignment confirmed and timesheet approved, but the webhook configuration and signing secret stay with the hiring company.
If your agency wants event notifications for activity that involves your workers, ask the hiring company whether they can send the relevant events to a system you operate.
When your agency needs its own programmatic access, use agency-scoped Open API keys for reading data rather than company webhook delivery.