CRM Integration

This guide is aimed at integrators who want to connect CRM systems such as HubSpot, Close, Zoho CRM, GoHighLevel, Pipedrive, Salesforce, or another CRM platform with KlickTipp.

CRM integrations are commonly used to synchronize contacts, lifecycle stages, segments, consent-related information, and deletion requests so that KlickTipp can run targeted email marketing and automation workflows.

Use the Management API as the default model for CRM integrations. CRM flows usually require dynamic field mapping, segment-to-tag mapping, stable ID storage, support for email address changes, and outbound sync back into the CRM.

CRM integrations are rarely simple "create contact" flows. In practice, they need to:

• Map standard and custom contact fields.
• Create or update contacts repeatedly over time.
• Keep CRM segmentation aligned with KlickTipp tags.
• Preserve a stable identity even when the email address changes.
• Display KlickTipp subscription status inside the CRM.
• React to unsubscribes and deletion requests.

That is why CRM integrations should use the Management API instead of the Listbuilding API.

Before creating or updating contacts, load the required reference data from KlickTipp. This ensures that the integration uses valid opt-in process IDs, tag IDs, and field keys.

Recommended behavior:

• Load this setup data during onboarding.
• Refresh it when mappings are edited.
• Refresh it periodically for long-running integrations.

For long-running CRM integrations, store stable IDs in both systems:

• Store the CRM Contact ID in a KlickTipp data field.
• Store the KlickTipp Contact ID in the CRM.

This prevents duplicate contacts and allows the integration to keep mapping contacts correctly even when the email address changes.

Recommended identification order:

1. Stored KlickTipp Contact ID
2. Stored CRM Contact ID
3. Email address lookup with Search Contact ID

Use the email address only as a fallback identifier. Once both systems know each other's stable IDs, contact creation and contact updates should rely on those IDs instead of email alone.

The CRM to KlickTipp sync step is the central inbound flow for CRM integrations. It creates new contacts in KlickTipp, updates existing contacts, and keeps CRM fields useful for segmentation and automation.

1. Receive a CRM contact event from a CRM webhook, scheduled sync, form submission, or another event source.
2. Apply optional filters, such as lead status, lifecycle stage, owner, list membership, or "do not sync" markers.
3. Load or refresh reference data with List Opt-in Processes, List Tags, and List Data Fields.
4. Identify the contact by stored KlickTipp Contact ID, stored CRM Contact ID, or email address.
5. Decide whether this is a new contact, an update to an existing contact, an email-address change, an unsubscribe flow, or a deletion flow.
6. For a new contact, call Add or Update Contact with the selected opt-in process and mapped CRM fields.
7. For a normal update where the email address did not change, call Add or Update Contact or Update Contact, depending on whether you already know the KlickTipp Contact ID.
8. For an email-address change, update the existing contact by Contact ID with Update Contact.
9. Store the CRM Contact ID in a KlickTipp data field and store the KlickTipp Contact ID in the CRM.
10. Map CRM fields to KlickTipp fields.
11. Add current CRM segment tags with Tag Contact.
12. Remove CRM segment tags that no longer apply with Untag Contact.
13. Display the current KlickTipp subscription status in the CRM if needed.

The recommended entry point for new CRM contacts is Add or Update Contact.

Use it when:

• A sales person created a new CRM contact.
• A form created a new CRM contact.
• An initial sync imports historical contacts.

If the CRM flow represents a fresh opt-in event, subscribe the contact with the correct opt-in process. If the flow only mirrors existing CRM records, be explicit about which contacts should enter KlickTipp and under which subscription rules.

For normal updates where the email address stays the same, you can use Add or Update Contact or Update Contact.

Use Update Contact when:

• You already know the KlickTipp Contact ID.
• You want a stable update path independent of the current email.
• You want to avoid ambiguous email-based matching.

Email address changes must not create duplicate KlickTipp contacts.

Recommended handling:

1. Store the CRM Contact ID in KlickTipp.
2. Store the KlickTipp Contact ID in the CRM.
3. When the CRM email changes, identify the existing KlickTipp contact by its Contact ID.
4. Update the existing record with Update Contact.

Do not treat an email-address change as a new contact creation.

CRM integrations usually need both standard and custom field mappings.

Typical mappings include:

• CRM Contact ID
• KlickTipp Contact ID displayed in the CRM
• First name.
• Last name.
• Company.
• Phone number.
• Birthday.
• Owner or sales rep.
• Lifecycle stage.
• Lead status.
• CRM source
• Displayed subscription status.

Recommended mapping rules:

• Map the largest useful overlap of standard CRM fields into KlickTipp standard fields.
• Use custom data fields for CRM-specific identifiers and statuses.
• Document every custom field used by the integration.
• Validate formats before sending values to KlickTipp.
• Transform values when the CRM field type differs from the KlickTipp field type.

For a complete overview of supported field types, required formats, and common pitfalls, see Data Field Types and Input Formats.

Tags connect CRM segmentation with KlickTipp automations. They can represent lifecycle stages, lead statuses, CRM lists, CRM tags, labels, product interest, or other segment data.

Recommended tag patterns:

• [CRM]
• [CRM] [Lifecycle Stage]
• [CRM] [Lead Status]
• [CRM] [List]
• [CRM] [Segment]

Recommended behavior:

• Add the tags that represent the current CRM segment state.
• Remove tags that no longer apply.
• Use a stable prefix for integration-managed tags.
• Document whether CRM segments are mapped from tags, lists, labels, pipeline stages, or custom fields.

If users should not manually create every CRM segment tag in KlickTipp, the integration can manage those tags through the API.

This is useful when:

• CRM segments change frequently.
• Labels or list values are customer-specific.
• The integration should automatically support newly created CRM categories.

Repeated Tag Contact and Untag Contact calls should be treated as idempotent from the integration perspective. The integration should compute the final desired tag state and then apply that state.

If you want to simplify this logic in Make or n8n, you can use the reusable Tag Management Templates. These templates help you resolve or create tag names, identify outdated prefixed tags, and update contact tags without rebuilding the same tag-handling flow in every integration.

KlickTipp should remain the leading system for email subscription status.

The CRM may display that status, but it should not arbitrarily overwrite it.

Recommended rules:

• Display the current KlickTipp subscription state in the CRM.
• If the CRM uses its own marketing-status field, treat that field as a display or workflow aid unless the event is a real opt-in or unsubscribe action.
• If a contact is unsubscribed in KlickTipp, reflect that status in the CRM.
• Restrict manual CRM edits of the displayed subscription field where possible.

Typical displayed values are:

• Subscribed
• Opt-In Pending
• Unsubscribed

CRM integrations often need more than one opt-in process.

Use List Opt-in Processes to load valid opt-in process IDs, then subscribe contacts with the correct process for each entry point.

Typical examples:

• Form registrations.
• Customer purchases.
• Webinar registrations.
• Lead-magnet downloads.

If the contact enters through a CRM form, always subscribe the contact with the intended opt-in process and set the corresponding display status in the CRM, such as Opt-In Pending, if the CRM supports that.

If the CRM sends an event that should unsubscribe a contact in KlickTipp, call Unsubscribe Contact only when that event is a true unsubscribe or consent-withdrawal signal.

Avoid treating ordinary CRM field edits as subscription commands.

CRM integrations often need to show KlickTipp status or events inside the CRM and sometimes create or update CRM contacts from KlickTipp changes.

Use Webhooks & Event Subscriptions for event-driven outbound flows such as contact updates or deletion requests. Batch or polling sync can be used for initial imports and periodic reconciliation.

Common KlickTipp to CRM flows include:

• Create a CRM contact when a KlickTipp contact has no CRM ID yet.
• Update an existing CRM contact when KlickTipp data changes.
• Mirror KlickTipp tags into CRM labels, tags, or segment fields.
• Display KlickTipp subscription status in the CRM.
• Process deletion requests raised from KlickTipp.

Two-way sync can create update loops if each system reacts to changes created by the integration itself.

Recommended safeguards:

• Use a dedicated integration user where the CRM allows it.
• Ignore webhook events caused by that integration user.
• Compare timestamps or source markers where necessary.
• Do not trigger downstream writes when no relevant field changed.

Deletion handling should be documented explicitly before go-live.

Possible strategies include:

• Delete the matching contact in the target system.
• Anonymize the matching contact in the target system.
• Create a manual review task before deletion.

If the CRM deletes a contact, decide whether the matching KlickTipp contact should be deleted immediately or only when the deletion is part of the intended data-governance model.

If a customer submits a deletion request through KlickTipp, use the deletion webhook flow described in Webhooks & Event Subscriptions.

Recommended reconciliation rules:

• Define which system is authoritative for deletion events.
• Document the matching rule for deletion, for example stable CRM ID, KlickTipp Contact ID, or fallback email.
• Log failed deletions and review them manually.

Many CRM integrations need both an initial import and an ongoing update flow.

Use an initial sync when:

• Historical CRM contacts must be imported into KlickTipp.
• The integration is activated for an account with existing CRM data.
• A clean baseline is needed before incremental updates begin.

Recommended behavior:

• Create contacts that do not exist yet.
• Update existing contacts without creating duplicates.
• Map by stable ID whenever possible.
• Assign the baseline source tag for imported contacts.

After the initial import, use webhook-based or polling-based incremental sync for:

• New contacts.
• Changed contacts.
• Changed segments.
• Changed subscription display status.
• Deletions and reconciliation events.

CRM integrations should handle long-running data changes explicitly, especially:

• Email address changes.
• Deleted tags.
• Outdated field mappings.
• Missing opt-in processes.
• Unsubscribed contacts.
• Missing required CRM fields such as email.
• Permission issues in the CRM or the automation platform.

For a complete explanation of the error model, validation errors, and subscription-related error codes, see Error Handling and Validation.

The same architectural rules apply across CRM platforms, but the concrete setup can differ depending on how the CRM handles tags, labels, webhooks, custom fields, and subscription display fields.

Examples currently documented and templated by KlickTipp include:

• Zoho CRM
• GoHighLevel
• Pipedrive
• Salesforce

Typical platform-specific variations include:

• Whether the CRM supports native tags or only labels.
• Whether webhook creation is available only on higher plans.
• Whether the CRM can display a custom KlickTipp Subscription Status field.
• Whether contact deletion events include the current email, a previous email, or only an object ID.

Good CRM integrations keep contact identity, subscription state, and segmentation predictable across both systems.

• Use the Management API as the default model: CRM integrations usually need dynamic fields, tags, stable IDs, and update logic.
• Store stable IDs in both systems: Store the CRM Contact ID in KlickTipp and the KlickTipp Contact ID in the CRM.
• Load and refresh reference data: Tags, fields, and opt-in processes can change over time.
• Keep KlickTipp authoritative for email subscription status: The CRM can display subscription status, but it should not overwrite it without a clear opt-in or unsubscribe flow.
• Use Contact ID for email address changes: If the CRM email address changes, update the existing KlickTipp contact via Contact ID instead of creating a new contact.
• Apply the final segment state: Remove old CRM segment tags and add the current tags so automations match the CRM state.
• Prevent sync loops: Ignore changes written by the integration user or marked as integration-originated.
• Handle deletion requests deliberately: Define whether deletion requests should remove CRM data, anonymize CRM data, or create a manual review task.
• Test each path separately: New contact, update, email change, unsubscribe, segmentation change, deletion, and re-sync after errors.

CRM integrations connect sales and customer data with KlickTipp marketing automation.

Use the Management API as the default model. Store stable IDs in both systems, load reference data, map fields explicitly, represent CRM segments as KlickTipp tags, and keep KlickTipp as the leading system for email subscription status.

Reliable CRM integrations handle new contacts, existing contacts, email address changes, subscription state, deletion requests, initial sync, incremental sync, and segment changes without creating inconsistent contact states.