Integrate via Zapier

Zapier is Thawly's "long-tail" integration slot — it lets you wire any CRM, sales tool or notification channel that we don't yet have a native OAuth integration for. The Zap does the wiring; Thawly provides the trigger and action endpoints.

When to pick Zapier vs a native CRM#

If your CRM is on the integrations page with an Open setup guide or Connect with OAuth button (HubSpot, Salesforce, Pipedrive, Microsoft Dynamics 365, Zoho, Close, Capsule, Copper), use that — the native path imports your closed-lost deals directly with field-level mapping, retries, and write-back of "Re-engagement attempt" notes onto the source deal. Zapier is the right choice when your CRM isn't on that list (Insightly, Freshsales, monday.com, ActiveCampaign, Less Annoying CRM, Salesmate, Apptivo, EngageBay, Bigin, SugarCRM and similar), or when you want to pipe Thawly signals out to a non-CRM destination such as Slack, Microsoft Teams, a Google Sheet or a custom webhook in your stack. Native integrations are always preferable where they exist; reach for Zapier for the long tail.

Generating + rotating the bearer token#

Authentication is a per-org bearer token you paste into the Zap's Authorization header. To mint one:

1. Open Settings → Integrations in Thawly.
2. Click Manage Zapier connection → on the Zapier card.
3. Click Generate token. The plaintext token is shown once — copy it immediately into your password manager or directly into the Zap. We never display it again.
4. In Zapier, configure the action's Authorization header as Bearer <your-token>.

The token is hashed at rest in crm_connections.access_token using HMAC-SHA256 with a server-side key (ZAPIER_TOKEN_HMAC_KEY). A leaked database dump leaks the encrypted hash, not the bearer token, even if the encryption key is also compromised.

Rotation: click Generate token again to mint a new bearer. The old hash is cleared, so any Zaps still pointed at the previous token will start failing with HTTP 401 until you update their Authorization header. Rotate the token any time someone leaves the team or you suspect a leak.

[Screenshot: Zapier action with Custom Request → Headers → Authorization: Bearer thwly_zap_…](/help/img/zapier-mapping.png)

Webhook URL#

For Zaps into Thawly (an inbound deal from your CRM), POST JSON to:

https://app.thawly.co.uk/api/integrations/zapier/webhook

The request must include your bearer token in the Authorization header. The body is a JSON object — we accept exactly these fields:

• companyName (required, ≤ 200 chars)
• dealValue (number or numeric string, optional)
• lostDate (ISO date YYYY-MM-DD or full ISO timestamp, optional)
• lostReason (free text ≤ 500 chars, optional)
• productPitched (free text ≤ 500 chars, optional)
• contactRole (job title, e.g. VP Sales, ≤ 200 chars, optional)

Per Thawly's GDPR posture we reject payloads carrying contactEmail, contact_email, contactName, contact_name, email, phone, phoneNumber or phone_number — remove those fields from your Zap mapping. We surface the rejection (HTTP 400) rather than silently dropping the field so you fix the Zap rather than letting personal data leak into our logs.

Supported event types (outbound Zaps)#

For Zaps out of Thawly, the trigger fires the following event types:

• signal.fired — a new public signal landed for one of your tracked companies and made the digest threshold (statutory filing, news mention, contract award, hiring spike, etc.). Useful for piping high-confidence signals into a Slack channel or a Google Sheet.
• copy.click — your team clicked Copy message on a digest line. Useful for tracking outreach activity in a sheet or appending an activity row to a system Thawly doesn't natively integrate with.

The full list lives in lib/crm/providers/zapier.ts and is the authoritative source — if a third event type appears in the registry, it'll show up here.

Common gotchas#

• Authorization header dropped. Zapier's "Webhooks by Zapier" action sometimes silently drops headers if the JSON body is malformed. Always test the Zap with the Send Test button — Thawly returns a clear 401 / 400 response we plumb back through.
• Date timezones. lostDate is normalised to a date-only YYYY-MM-DD server-side. If your CRM sends a full ISO timestamp in your local timezone, we trim to the date portion in UTC — review the imported lost dates if your CRM stores deals at end-of-day.
• Stringified numbers. Some Zapier sources stringify numeric fields. We auto-coerce numeric strings to numbers in dealValue, but anything that doesn't parse as a finite number returns HTTP 400. Keep dealValue as a number or a clean numeric string in your mapping.
• Duplicate fires. We deterministically dedupe on (companyName + lostDate + productPitched + contactRole), so re-running the same Zap doesn't double-count the deal.

What happens next#

Inbound deals land on the next signal-source pass. Outbound triggers fire roughly when the digest builds (daily for paid tiers, Mondays for free). Once you're set up, watch the Last sync timestamp on the Zapier card on /settings/integrations to confirm the wiring is live.

Coming from a native CRM after all?#

If your CRM is on the integrations page (HubSpot, Salesforce, Pipedrive, Microsoft Dynamics, Zoho, Close, Capsule, Copper), the native path is faster and richer than the Zapier route — see Migrate from HubSpot, Migrate from Salesforce, or the full list in the Help index.