Events
Webhook Events
ContactManager provides webhook events to notify your application about different user activities. Each webhook payload includes an event type and relevant data about that event.
Common Payload Structure
All webhook payloads follow this standard structure:
- id: A unique identifier for this webhook delivery (useful for deduplication)
- event: The type of event that occurred
- payload: Contains all relevant data about the event
Available Events
User Events
user.new
Triggered when a new user is created in your system.
user.is_contact
Triggered when a newly joined user potentially knows existing users in your system. This helps identify possible connections between users based on contact information matching.
The matched_user_ids
array contains IDs of existing users who might know the new user. You can use this to suggest connections or build social features that connect users who likely know each other.
user.deleted
Triggered when a user is deleted from your organization.
This event is useful for keeping external systems in sync with your ContactManager data and for compliance with data deletion regulations.
Social Events
user.follow
Triggered when a user follows another user.
user.unfollow
Triggered when a user unfollows another user.
Event Management
user.create_event
Triggered when a user creates a new event.
user.update_event
Triggered when a user updates an existing event.
user.delete_event
Triggered when a user deletes an event.
Using Events for Social Features
ContactManager’s webhook events are designed to help you build powerful social features:
- Use
user.is_contact
to identify potential connections between users - Track follow/unfollow actions to build social graphs
- Monitor user events to create activity feeds and social timelines
- Build notification systems based on user actions
Event Delivery and Reliability
To ensure reliable delivery of events, ContactManager implements a robust retry mechanism:
- Events are delivered in real-time when they occur
- If your endpoint is unavailable or returns an error, we retry automatically
- Retry attempts are made at 3 and 10 seconds after the initial failure
- All delivery attempts are logged with their status, duration, and response information
- Each event has a unique ID to help with deduplication in your system
For implementation details, see our implementation guides.