Zithara
Overview
Section titled “Overview”Signals reads orders, store visits and customer records from Zithara CRM.
Zithara sends events to Signals by webhook as they happen, so a purchase or a store visit reaches your ad platforms within moments of being recorded.
It also supports one integration type only, Offline Events, which is why the destinations below are the offline conversion endpoints rather than the full set. There is no audience or lead conversion path from this connector.
Supported destinations
Section titled “Supported destinations”Destinations supported by Zithara
Prerequisites
Section titled “Prerequisites”- A Zithara CRM account, with the Client ID and Client Secret from it. Signals uses the pair to generate an access token.
- The ability to register a webhook in Zithara CRM. Nothing reaches Signals until the webhook is registered, so this is the step to confirm you can complete before you start.
- Orders, visits or customer records carrying the contact details destinations match on, chiefly email address and phone number.
Authentication
Section titled “Authentication”In Studio, open Sources, find the CRM category, and click the Zithara CRM tile. This connector authenticates with credentials you add manually. Enter the following, then continue.
| Field | Where to find it |
|---|---|
| Client ID | From your Zithara CRM account. |
| Client Secret | From your Zithara CRM account. |
Signals uses the pair to generate the access token it authenticates with.
Configuration
Section titled “Configuration”Instance Setup
Section titled “Instance Setup”Offline Events is the only Integration Type available on this connector, so it is already selected. Give the instance a name and continue.
Webhook configuration
Section titled “Webhook configuration”Studio generates a webhook URL for this instance. Copy it, register it in your Zithara CRM account, then choose which events Zithara should send. The connector does not work until the webhook is registered in Zithara using that URL.
Six events are available: Order Create, Order Update, Visit Create, Visit Update, Customer Create and Customer Update. Select only the events you intend to report. Every event you enable is delivered onward, so enabling all six when you only report purchases sends visits and customer updates your destinations have no use for.
Manage instance
Section titled “Manage instance”The events this instance sends can be changed at any time. Open it from the Manage existing instance table, click the edit option in the menu to the top right, update the event selection and click Finish.
Data & identifiers
Section titled “Data & identifiers”Personal identifiers are normalized and SHA-256 hashed before they are sent to any destination.
Email, phone, name and location are what destinations match on. Order value, currency and product fields describe the conversion rather than the person, so they do not affect match rates.
Best practices
Section titled “Best practices”- Register the webhook in Zithara before expecting any data. This is the single most common reason a Zithara connection looks configured but delivers nothing.
- Enable only the events you report on. Order Create and Order Update cover purchase reporting; Visit and Customer events are for footfall and profile changes.
- Ensure orders and visits carry an email address or phone number. Destinations weight these highest, so a transaction with neither matches at a much lower rate.
- Maintaining consistent formatting in Zithara helps match rates: email addresses in lowercase, phone numbers in E.164 format, and no trailing spaces.
Troubleshooting & FAQ
Section titled “Troubleshooting & FAQ”Nothing arrives at all. The webhook is almost certainly not registered in Zithara. Copy the URL from the instance and register it there.
Some event types arrive and others do not. Only the events selected on the instance are sent. Open the instance and check the event selection.
Authentication fails. Re-check the Client ID and Client Secret, and confirm both come from the same Zithara CRM account.
Match rates are low. Records holding neither an email address nor a phone number are the usual cause, since destinations weight those two identifiers highest. Fix formatting at source as well, since a hash only matches if both sides normalized the value the same way.