Create a webhook
What this achieves
Section titled “What this achieves”A webhook tells another system that something happened in Humavera, as it happens, by posting to a URL you control. It is the outbound, event-driven half of integration — the opposite of another system asking Humavera for data on a schedule.
Required role: Administrator.
Before you start
Section titled “Before you start”You need an endpoint that is reachable from the internet and that answers quickly. The receiving system should verify the signature on each delivery before acting on it.
- Go to Integrations → Webhooks.
- Select Create Webhook.
- Enter the Name and the URL.
- Set the HMAC Secret, or select Auto-Generate.
- Under Events, select the events this webhook subscribes to.
- Add any Custom Headers the receiving system needs.
- Set the Retry Policy.
- Save, then select Test on the webhook to confirm the endpoint answers.
Events you can subscribe to
Section titled “Events you can subscribe to”| Group | Events |
|---|---|
| Employees | employee.created, employee.updated, employee.terminated, employee.status.changed, employee.department.changed, user.invited |
| Skills & Competencies | skill.created, skill.updated, competency.created, competency.updated, employee.skill.updated, employee.competency.updated |
| Learning | course.published, enrollment.completed, assessment.completed, certification.issued, certification.expired |
| Career & Growth | development_plan.created, development_plan.milestone.completed, promotion.readiness.submitted, promotion.readiness.approved |
| Mobility | opportunity.published, application.submitted, mobility.transfer.completed |
| Workflows | workflow.published, workflow.completed, workflow.approval.requested, workflow.approval.decided, workflow.sla.breached, workflow.notification.created |
| Feedback | feedback_cycle.launched, feedback_cycle.completed, feedback.given, feedback.requested, feedback.reminder.sent, feedback.results.pushed |
| Other | employee.flight_risk.elevated, snapshot.generated, department.created, job_profile.published |
Subscribe to the events the receiving system will actually act on. A webhook subscribed to everything delivers a large volume the receiver has to filter, and buries the two events that mattered.
Example: HC Corp’s service desk needs employee.created and employee.terminated to open and close accounts. Adding employee.updated to the same webhook multiplies the traffic and changes nothing about what the service desk does.
Be deliberate about the feedback and career events. feedback.given and promotion.readiness.submitted carry information about named people into another system, where your access controls no longer apply.
The signing secret
Section titled “The signing secret”Deliveries are signed with HMAC-SHA256 using the HMAC Secret, so the receiving system can verify a request genuinely came from Humavera and was not altered on the way.
Use Auto-Generate rather than inventing a secret. Then configure the receiving system to verify every delivery before acting on it — an unverified endpoint accepting posts is an endpoint anyone who learns the URL can drive.
When editing an existing webhook, leaving the secret field blank keeps the current secret. It is not shown back to you in the form.
Custom headers
Section titled “Custom headers”Add headers the receiving system requires — an authentication header for its own gateway, or a routing header. The overview states that custom headers are encrypted and stored, and existing values are masked in the form. Leaving them blank on an edit keeps them; adding rows overwrites them.
Retry policy
Section titled “Retry policy”| Option | Description | Default |
|---|---|---|
| Max Retries | How many times a failed delivery is retried. | 3 |
| Interval (s) | Seconds before the first retry. | 60 |
| Backoff × | The multiplier applied to the interval on each subsequent retry. | 2 |
With the defaults, a failed delivery is retried three times with the gap doubling each attempt, so a receiver that is briefly down catches up rather than losing the event.
Raise the retry count for a receiver with known maintenance windows. Do not raise it to compensate for an endpoint that is unreliable — the failure count on the webhook is the number to fix.
Example: HC Corp’s receiving service being offline for twenty minutes is covered by the defaults. Being offline every Sunday night is a scheduling problem, not a retry-policy problem.
What the list shows
Section titled “What the list shows”| Option | Description |
|---|---|
| URL | Where deliveries are posted. |
| Events | How many events this webhook subscribes to. |
| Status | Whether the webhook is active or paused. |
| Last Delivery | When it last delivered, or Never. |
| Failures | The accumulated failure count. |
Deleting
Section titled “Deleting”Deleting a webhook stops deliveries to that URL. The interface states that existing delivery logs are preserved, so the record of what was sent survives the webhook itself.
Use Pause where you want deliveries to stop temporarily. Delete where the integration is finished.
What happens next
Section titled “What happens next”Once created and active, matching events are delivered as they occur, signed, and logged. Test the endpoint before relying on it, then use the delivery logs to confirm real events are arriving and to replay any that failed.
Related
Section titled “Related”© 2025-2026 Humavera Documentation - BPilot Ltd. All Rights Reserved