Overview
Webhooks deliver real-time notifications when events occur in Connecteam, eliminating the need for polling.
Available Webhooks
| Webhook | Events | Description |
|---|---|---|
| Time Activity | clock_in, clock_out, user_add_request, admin_day_locked, user_timesheet_approved, and more | Time clock punches, pending requests, day locks, and timesheet approval |
| Form Submission | form_submission, form_submission_edited, manager_field_updated | Form entries and updates |
| Users | user_created, user_updated, user_deleted, user_archived, user_restored, user_promoted, user_demoted | User lifecycle events |
| Scheduler | shift_created, shift_updated, shift_deleted, availability_status_created, availability_status_deleted | Shift and availability changes |
| Tasks | task_published, task_completed | Quick task events |
| Chat | message_created, message_updated, message_deleted, conversation_created, conversation_updated, conversation_deleted | Chat message and conversation events |
Setup Methods
Via UI
- Go to Settings → API & Integrations
- Click Add webhook
- Configure:
- Name: Descriptive name for your webhook
- URL: Your HTTPS endpoint
- Feature: Select the feature type
- Object: Select the specific instance (e.g., which time clock)
- Events: Choose which events to receive
- Click Create webhook
ImportantOnly account Owners can create webhooks. The endpoint URL must be HTTPS.
Via API
See Setting up webhook via API for programmatic webhook management.
Webhook Behavior
- Retry logic: Failed deliveries are retried up to 3 times. There is no fixed delay, so a retry may arrive immediately. Any
2xxresponse succeeds;404is treated as permanent and is not retried; other failures may be retried. - Payload format: JSON. Shared envelope fields are
requestId,company,eventType,eventTimestamp, andactivityType. Some webhooks (Users, Tasks) nest details underdata. Time Activity is flat — fields such asuserId,timeClockId, andtimeActivitysit at the root. See Time activity webhook. - Timeout: Return a
2xxresponse within 10 seconds. Queue longer processing after acknowledging the delivery.
Common Payload Structure
Most webhook payloads share these base fields. Time Activity does not wrap the event in data.
{
"requestId": "unique-request-id",
"company": "company_identifier",
"eventType": "event_name",
"eventTimestamp": 1736760013,
"activityType": "feature_type"
}| Field | Type | Description |
|---|---|---|
| requestId | string | Correlation ID inherited from the originating action. Retries keep the same value, and different events from one action may share it |
| company | string | Company identifier |
| eventType | string | The event that triggered this webhook |
| eventTimestamp | integer | Unix timestamp of the event |
| evnetTimestamp | integer | Deprecated misspelling. Still sent on older events (Users, and older Time Activity types). New Time Activity request, decline, and period events send eventTimestamp only |
| activityType | string | Feature type (for example User, Task, forms, shift, timesheet_period) |
| data | object or array | Event-specific payload on Users, Forms, Tasks, and similar. Omitted on Time Activity |
Receiving webhooks safely
- Validate
x-webhook-secretwhen you configured asecretKey. - Return any
2xxresponse within 10 seconds. - Queue business processing after acknowledging the request.
- Expect retries to resend the same JSON.
- Do not deduplicate on
requestIdalone. Combine it witheventTypeand the affected entity (timeActivity.id,timeActivityId, or the user/date range).
Updated 6 days ago
What’s Next
Did this page help you?
