Cresca Integrations: Connecting Your Existing Stack
An email platform is rarely the only system touching your customer data. Cresca sits alongside a CRM, an ecommerce platform and often a support tool, and the way those systems synchronise determines whether your contact data is trustworthy. This covers how integrations work and the failures that matter.
The shape of an integration
Every integration between Cresca and another system is a two-way data path, and it is worth being precise about each direction.
Inbound events bring data into Cresca: a new signup from a form, a purchase from a store, a status change from a CRM. These become contact attributes and, where relevant, automation triggers. Inbound data quality is entirely determined by the system that sends it.
Outbound events carry Cresca activity back out: which contacts were sent to, who clicked, who unsubscribed, who bounced. This is what lets another system know about engagement without you exporting CSV files.
Most integration problems are failures in one direction being mistaken for problems in the other. If contacts are appearing correctly but engagement is not showing in your CRM, the inbound path is fine and the outbound path is broken.
What to connect first
Connect in order of how much the next workflow depends on it, not in order of how impressive the integration list looks.
- Your signup source. Forms and landing pages. Without this, contacts arrive manually and everything downstream is guesswork.
- Your ecommerce platform, if you sell online. Purchase events unlock the most valuable automations: post-purchase, replenishment, cart abandonment, win-back.
- Your CRM. Connect this third, because CRM contact models are usually wider than an email contact model and you will want to choose deliberately which fields matter for email.
- Analytics and support. Useful, but rarely load-bearing for a campaign.
The sync problems that corrupt data
Conflict without precedence. If both systems can write the same field, the last write wins, which means the result depends on timing rather than intent. Decide which system is authoritative per field before you connect. The email platform should own subscription status; the CRM should usually own lifecycle stage.
Deletes that do not propagate. A contact deleted in one system often persists in the other. This is how suppressed addresses get mailed again, which is one of the fastest ways to accumulate complaints. Decide explicitly whether deletes propagate and test it.
Duplicate creation. Without a stable identifier, the same person arriving via two paths becomes two contacts. Email address is the usual key, which fails for people with multiple addresses. Confirm how your integration deduplicates before importing a large batch.
Unsubscribe status not respected. The most damaging failure by a wide margin. If an unsubscribe in Cresca does not propagate outward, another system will keep mailing that person. Verify this propagation explicitly before any significant send.
Verifying an integration actually works
Do not trust a "connected" status. Test the data.
- Create a test contact in the source system and confirm it arrives in Cresca with the fields you expect populated.
- Trigger one real event, such as a test purchase, and confirm the automation fires.
- Unsubscribe that test contact and confirm the status propagates back to the source.
- Check field mapping: a field that arrives empty is usually a naming mismatch rather than a missing value.
Run this once at setup and again after any change to the source system's schema. Integrations do not stay working by themselves.
Building the API path
Where a prebuilt integration does not exist, the API is the fallback, and it is a normal HTTP API: authenticate, post an event or a contact, read the response. The practical guidance is to send events rather than to push full contact records. An event describes what happened, which is idempotent and easy to reason about; a full record overwrites state and will clobber fields another path is writing.
Handle failures explicitly. A request that fails silently means data you believe you have and do not. Record the failure, retry with backoff where the operation is safe to repeat, and alert when failures persist.
Pricing
Integration and API access are available on every plan, including Free:
| Plan | Price | Contacts | Emails / month |
|---|---|---|---|
| Free | $0 | 50 | 50 |
| Professional | $29/mo | 5,000 | 5,000 |
| Premium | $49/mo | 25,000 | 25,000 |
| Ultra | $99/mo | 55,000 | 55,000 |
What to do when an integration breaks
Integrations fail in three ways, and they need different responses.
- Silent stop. No new records arrive and nothing reports an error. Usually an expired credential or a changed field schema at the source. Check when the last record arrived; a gap that starts at a specific time points to a specific change.
- Partial failure. Most records arrive and some do not. Often a field-level mapping problem, such as a required value that is empty for a subset of records.
- Wrong data. Records arrive with incorrect values. Almost always a mapping error: two fields swapped, or a value being written to the wrong attribute.
For any of these, the first diagnostic is to compare a specific record in the source system against the same contact in Cresca. That single comparison tells you whether the problem is the export, the transport or the mapping.
Choosing fields deliberately
An integration with a wide CRM will offer to sync dozens of fields. Syncing all of them creates maintenance work and increases the chance of a conflicting write to a field something else also owns.
Sync the fields a campaign will actually use. Typically that is a name, an identifier, a lifecycle status, and two or three attributes used for segmentation. Everything else can be fetched when needed rather than held in the email platform and kept in sync forever.
Handling volume limits
Bulk imports and large synchronisations hit rate limits. The practical approach is to batch deliberately and make the operation repeatable, so that a partial run can be resumed rather than restarted. Imports that are safe to run twice are far easier to operate than imports that must succeed on the first attempt.
The short version
Treat each integration as two independent directions. Connect your signup source, then ecommerce, then CRM. Decide which system owns each field before connecting, and make sure deletes and unsubscribes propagate.
Test with a real contact and a real event rather than trusting a connected badge, and re-test after any schema change. Send events through the API rather than full records, and when something breaks, compare one record across both systems before changing anything.
Continue learning
Related Cresca resources
External references