New store leads into any app, with Zapier

Zapier connects thousands of apps to each other without any code. FisherLeads is where you find online stores the moment they launch, each one confirmed live and enriched with the founder contact, platform and tech it runs. Put the two together and every new store that matters to you flows straight into the tools your team already uses.

FisherLeads does not install a button inside each app. Instead it pushes new matching stores to you in real time as a signed webhook. Zapier catches that webhook with a single trigger, and from there you decide where each store goes. That one connection is the hub: build it once, and you can route the same store to a CRM, a spreadsheet, a chat channel or anywhere else Zapier reaches.

Because the trigger is generic, Zapier is the most flexible way to work with the FisherLeads feed. You are never limited to a fixed list of destinations. If Zapier supports an app, FisherLeads can feed it, and you can change where your leads land at any time without touching FisherLeads again.

The whole connection rests on one trigger. In FisherLeads you create a webhook with a filter that describes the stores you want. When a new store matches, FisherLeads sends it to a unique Zapier address as a signed request. Zapier catches it with the Webhooks by Zapier trigger, using the Catch Hook event.

From that single trigger, everything else is up to you. A Zap can have one action or many, run in a straight line or branch down different paths, and send the same store to several apps in one pass. The store data arrives as a set of fields you map into whichever actions you choose.

This is why Zapier suits teams who want options. You can start with one simple action today, a row in a sheet or a message in Slack, then grow the same Zap into a full routing engine for your pipeline later, all without any code.

FisherLeads is efficient about delivery. When several stores match at once, it does not send a separate request for each one. Instead a single delivery can carry up to fifty stores together, grouped inside a leads array in the request body.

A plain Zap acts on the first store in that array. If you want an action to run for every store in a batch, add a Looping by Zapier step after the trigger and before your action. The loop walks through the leads array and runs the rest of the Zap once per store, so fifty new stores become fifty rows, fifty records or fifty messages.

For low volume filters where matches arrive one at a time, you may not need a loop at all. Add it when your filter is broad enough that several stores can land in the same delivery and you want to capture all of them.

A Zap can do far more than one action. Because every store arrives through the same trigger, you can shape what happens to it with the tools Zapier already gives you. Add a Filter step to continue only when a condition is met, for example only stores with a verified email or only those above a certain revenue band, so downstream apps stay clean.

Use Paths to branch. Send US stores to one CRM pipeline and the rest to another, or route beauty stores to one owner and apparel to a different one, all inside a single Zap. Each path can have its own actions and its own filters.

You can also fan out. A single store can create a CRM company, append a row to a sheet and post to Slack in the same run, so one launch updates your whole stack at once. Build the hub once and let it feed everything downstream.

If you would rather not use Zapier, point the FisherLeads webhook straight at your own endpoint and send the stores onward yourself. When new stores match, FisherLeads sends a single signed POST with the batch of leads. Each lead has the same shape as the API, so your own code can route it anywhere Zapier can, and more.

Every delivery is signed so you can be sure it came from FisherLeads. Compute an HMAC SHA256 of the raw request body with your webhook secret (shown next to the webhook in the dashboard) and compare it, constant time, to the X-FisherLeads-Signature header before you trust the payload.

Prefer to pull rather than be pushed to? The REST API returns the same feed, newest first, with the same filters as the dashboard. Poll it on a schedule and push the results into any app from your own code. Read access is on the Business plan; higher limits are on Enterprise.

You almost never want every new store flowing into your apps. Each webhook carries a filter, set in the dashboard when you create it, so only matching stores are sent. Filter by platform, country, niche, site type, revenue band and whether the store has a verified email. Create several webhooks with different filters if different teams or different Zaps want different stores.

Filtering at the source keeps your destinations clean and keeps your Zapier task usage down, since Zapier only ever sees the stores that matter to you. You can filter again inside the Zap with a Filter step, but filtering first at the webhook is the cheapest place to do it.

Stores reach your Zap within seconds of going live. FisherLeads pushes matches as they happen rather than on a nightly batch, so your pipeline is always current.

Deliveries are reliable. Zapier replies with a success status when it catches a request, which acknowledges it. If the delivery fails or times out, FisherLeads keeps the leads and retries on the next pass, and after repeated failures the webhook is paused automatically so a broken URL does not pile up. Use the Test button in the dashboard to send a signed ping and confirm everything is wired before you rely on it.

Every webhook is signed with an HMAC SHA256 of the body using a secret only you and FisherLeads hold, so you can verify each delivery really came from us and was not tampered with in transit. Zapier catches it over HTTPS.

The integration is one way: FisherLeads sends new stores to you. It does not read, store or scan anything in the apps you connect through Zapier. Nothing from your CRM, sheet or workspace ever comes back to FisherLeads. What flows onward is the public store data in the table above.