Connecting CoverGuard to Zapier

Put CoverGuard to work inside the tools you already use — get a Slack message the moment a carrier stops writing on a home in your book, log every quote to a spreadsheet, or push a new lead straight into your CRM, without anyone writing code.

Who this is for: Agents, Lenders and Insurance professionals on a Professional plan or above. Where: Sys Admin → Developer → Zapier. Time: ~10 min for your first Zap.

New here? Do Getting started first (signup, terms, your first property check).

What you can automate

Zapier connects CoverGuard to 9,000+ other apps. You pick a trigger (something that happens in CoverGuard) and Zapier does the rest in whatever tool you choose.

…and what CoverGuard can do for you

Triggers send data out. Actions let a Zap do something in CoverGuard:

Nothing here needs an engineer. If you can build a Zap, you can build these.

Connect your account

1. Go to Sys Admin → Developer → Zapier and select Connect Zapier.
2. Copy the connection key it shows you. It is displayed once — paste it somewhere safe before you close the panel, or generate a new one later.
3. In Zapier, add a CoverGuard step and choose Connect a new account.
4. Paste the key. Zapier confirms the connection and you are ready to build.

That key only reaches the Zapier surface. It cannot read or change anything else in your account, and its permissions are fixed when it is created — nobody can widen them later, including you.

Build your first Zap

Start with the one that pays for itself fastest:

1. In Zapier, create a Zap and choose CoverGuard → Carrier Stopped Writing as the trigger.
2. Pick your connected CoverGuard account.
3. Choose a sample record so you can map fields. If your account is brand new and has no history yet, Zapier shows a representative example instead — that is normal, and real data flows once the Zap is live.
4. Add whatever action you want: a Slack message, a task, a row in a sheet.
5. Turn the Zap on.

From then on it fires the moment the event happens. There is no polling and no delay.

Checking a brand-new address

The Check a Property action behaves differently the first time it sees an address, and it is worth knowing why.

If CoverGuard has assessed the property before, you get the full answer straight away. If it hasn't, CoverGuard has to go and gather federal and commercial data for that specific address — which takes longer than Zapier will wait. So the step returns immediately with a status of pending, and the work continues in the background.

To use the result, add a second Zap with the Property Check Completed trigger. It fires the moment the assessment lands. (There is a "wait for a first-time assessment" toggle if you would rather the step block — only use it if you are comfortable with a slow step.)

What it means

Zaps fire on real events, instantly. When something happens in CoverGuard we deliver it to your Zap straight away, rather than Zapier checking every few minutes.

Turning a Zap on subscribes it; turning it off unsubscribes it. You never manage anything on the CoverGuard side — the Developer page shows Zapier-managed subscriptions as read-only so nobody deletes one by accident and quietly breaks a live automation.

Delivery is at-least-once. Very occasionally the same event can arrive twice (a retry, or a resend after an outage). Zapier de-duplicates these for you automatically, so a Zap will not run twice for one event.

The data in a Zap is the same data in your Record. Risk scores and premium figures are modeled estimates — decision support, not a binding quote or appraisal. Don't wire a Zap that treats a modeled premium as a final price to a client.

What your plan includes

The hourly limit exists to protect you. Zapier bills by task, and a market-wide event — a carrier withdrawing from an entire state — can touch every property in your book at once. The ceiling stops a single day from consuming a month of your Zapier plan. Anything held back is recorded, so nothing disappears without a trace.

Personal or company-wide. By default a connection sees your book — a Zap you build works on your clients and your properties. On Team, a company owner or admin can create a company-wide connection instead, whose Zaps see every member's activity. That is what most brokerages want: "alert us when a carrier exits on any of our listings", not just yours.

Company-wide is deliberately restricted to owners and admins, because it means one person's Zap can see everyone's work. A regular member can always connect their own personal one.

Tips

• Start with one Zap. Carrier exits and renewals are where the money is; the rest can wait.
• Filter early. If you only care about high-value clients, add a Zapier filter step right after the trigger so you spend tasks on events that matter.
• Name your connection. If you keep separate connections for testing and production, give them names when you create them — the Developer page lists them by name.
• Disconnect properly. Removing a connection in CoverGuard also switches off every Zap it was feeding, so there is no way to leave data flowing to a credential you thought you revoked.
• Watch for a loop if you sync clients both ways. A Zap that creates a CoverGuard client from your CRM, plus a second Zap that creates a CRM contact whenever a CoverGuard client is added, will feed each other. Pick one direction, or add a Zapier filter so each Zap ignores records the other one made.

Troubleshooting

Do this next

• Set up a re-shop workflow around carrier exits and renewals.
• Building something custom instead of using Zapier? The same events are available directly — see the API reference.