Skip to main content

Your Implementation Required

These endpoints must be implemented on your server

Overview

The sync and update endpoints allow bidirectional data flow between Enginy and your CRM:
Key Principle: All matching logic lives in your CRM, not Enginy. You decide how to identify contacts (by email, LinkedIn URL, phone, etc.) and what data to sync back.

How Matching Works

When Enginy sends contacts to sync, your CRM should:
  1. Look up each contact using your preferred identifier(s)
  2. Return matches with your CRM’s internal ID (crmId)
  3. Optionally return properties you want synced back to Enginy

Common Matching Strategies

Email (Most Common)

Match by email field - the most reliable identifier for contacts

LinkedIn URL

Match by linkedinUrl - useful for B2B contacts

Phone Number

Match by phone or mobilePhone - normalize formats first

Composite Key

Combine multiple fields (email + company) for higher accuracy

Sync Contacts

Request

Request Body

Enginy sends all contacts it wants to sync:

Response

Return only contacts that exist in your CRM:
Contact lead-789 is not in the response because it doesn’t exist in your CRM. Only return matches.

Example Implementation

Here’s how to implement the matching logic:

Update Contacts

After syncing, Enginy knows which contacts have CRM IDs. The update endpoint receives only contacts that were previously matched.

Request

Request Body

Every contact in an update request has a crmId because it was returned during a previous sync.

Response

Example Implementation


Properties You Can Sync Back

When you return properties in your response, Enginy will store these values on the contact. Common properties to sync:
You can return any properties you want. Enginy will store them as custom fields on the contact.

Handling Null Values

Important: When Genesy syncs properties back from your CRM, fields that are returned as null (or not returned at all) will clear the existing value in Genesy. This includes core fields like email and phone.
To prevent accidentally clearing data in Genesy, follow these guidelines: Best Practice: Only include fields in properties that you explicitly want to sync back. If you don’t want to modify a field, don’t include it in the properties object.

Available Contact Fields

Enginy sends these fields (when available):

Engagement Field Updates

When contacts engage with campaigns (reply, connect, click links, etc.), Enginy sends engagement updates through the same PUT /contacts endpoint. These updates contain custom field names configured by the user in their campaign settings.

Example Engagement Update

Available Engagement Fields

Users can configure which fields to sync and what to name them. Here are all the fields Enginy can send:

Engagement Status Values

The campaignEngagementStatus field follows this progression:
  1. Added to Campaign - Contact added but no action taken
  2. Connection Request Sent - LinkedIn connection request sent
  3. Connection Accepted - LinkedIn connection accepted
  4. Message Sent (1/3) - LINKEDIN - First message sent (with type)
  5. Message Replied (1/3) - LINKEDIN - Contact replied
Field names are user-configurable. Your CRM should accept any field name and store it appropriately (either as a known field or as a custom field).

Implementation Tip

Make sure your PUT /contacts handler stores unknown fields rather than ignoring them:

Error Handling

Partial Success

If some contacts fail, return successful results and errors separately:

Update Failures

For updates, indicate failure in the result:

Engagement Field Updates

When contacts engage with campaigns (reply, connect, click links, etc.), Enginy sends engagement updates through the same PUT /contacts endpoint. These updates contain custom field names configured by the user in their campaign settings.

Example Engagement Update

Available Engagement Fields

Users can configure which fields to sync and what to name them. Here are all the fields Enginy can send:

Engagement Status Progression

The campaignEngagementStatus field follows this progression:
  1. Added to Campaign - Contact added but no action taken
  2. Connection Request Sent - LinkedIn connection request sent
  3. Connection Accepted - LinkedIn connection accepted
  4. Message Sent (1/3) - LINKEDIN - First message sent (with channel type)
  5. Message Replied (1/3) - LINKEDIN - Contact replied
Field names are user-configurable. Your CRM should accept any field name and store it appropriately (either as a known field or as a custom field).

Implementation Tip

Make sure your PUT /contacts handler stores unknown fields rather than ignoring them:

Reference Implementation

GitHub Repository

See a complete working implementation of contacts sync and update endpoints, including engagement field handling and activity display.