How to Send Angi Leads to JobTread Without Losing Source Data

A lead arrives from a marketplace. Someone in the office opens the notification, opens the job-management system, and re-enters the customer’s name, phone number, address and job details.

The manual step costs time. The larger problem is that the lead source can disappear during the handoff. Months later the business knows it closed a job without knowing whether that job started with a marketplace, a Google Ads click, a referral or a website form.

A useful workflow carries the source into the job record, checks for duplicates before it creates anything, and tells a person when it cannot finish the handoff. Saving typing is the secondary benefit.

This article describes connecting Angi leads to JobTread through Zapier. The same design applies to a website form reaching a CRM, an inquiry reaching an intake or scheduling system, an ad platform lead reaching a customer record, or a finished job reaching your marketing reporting.

The systems change. The questions do not. What data should move? How do we avoid duplicates? What happens when a field is missing? Who finds out when it fails? Can the business still connect the outcome to the source?

Keep the Lead Source Attached to the Job

When a job is created by hand, the source is whatever someone remembered to type, entered differently by different people, or left blank. Reporting built on that is unreliable in a way nobody notices until they need it.

A business usually knows how many inquiries each channel produced. It often cannot say which channels produced booked work. Those are different questions, and only the second should decide a budget. The source that generates the most inquiries may not generate the best jobs.

When the workflow writes a consistent source label instead, it stays attached to the record. The team can compare channels against whatever outcome it cares about later: estimates, booked work, completed jobs, revenue.

Angi Sends Leads Through a Webhook

Angi does not appear as a standard Zapier app in this workflow, so there is nothing to pick from a list. The connection starts with Zapier’s Catch Hook trigger, which generates a URL that can receive lead data.

The feed does not turn on by itself. Angi’s integration team has to configure the account to send leads to that URL, and until someone does, the Zap receives nothing at all, live or test. Confirm the current process with your Angi account representative rather than assuming the webhook alone is enough. If the account has not been configured to send data, confirm that before troubleshooting the workflow itself.

JobTread provides an official Zapier integration with both lookup and creation actions, including finding and creating jobs, customers and locations. The lookups are what make a careful workflow possible, because they let you ask whether something already exists before you write.

Platform Notes

Zapier documents Catch Hook as a trigger that receives requests from another system and parses the request body. JobTread publishes an official Zapier integration with both lookup and creation actions for jobs, customers and locations, and Zapier hosts templates for creating customer and job records from incoming webhook data.

Available actions, field names, permissions, pricing and setup differ by account and change over time. Confirm the current vendor documentation before you build. Verified 2026-09-08.

Keep Lead Sources Separate When Reporting Needs Them Separate

In this build two lead products used separate accounts and separate webhook destinations, so we used two nearly identical Zaps. Each preserved its own account and source label on the way into JobTread.

That was a reporting decision, not an architectural rule. A single Zap is fine when the payload carries a reliable source field and the distinction survives. The number of Zaps does not matter. What matters is that the source arrives in a consistent field and is still there when someone reviews completed work. The number of Zaps is a design choice; the reporting requirement is the part that matters.

How the Lead Moves From Angi to JobTread

Most steps move data forward. Two exist to prevent quiet failure: a duplicate check before anything is created, and a fallback to a person when the record cannot be written.

One Lead, End to End

The run is linear until the last step, where it either creates the record or tells someone it could not.

How to read it Follow steps 1 to 6 top to bottom. The workflow then either creates the record or sends the lead to the office for review.

1. 1 Webhooks by Zapier Catch Hook receives the lead
2. 2 Filter by Zapier Confirm the lead belongs to this account
3. 3 Code by Zapier Map the marketplace service label to a job type
4. 4 JobTread Look for an existing job The duplicate check, before anything is created.
5. 5 Filter by Zapier Stop duplicate leads No new customer or job is created.
6. 6 JobTread Look up the service address

Two outcomes are possible

Create path

A new lead with a valid location

7. 7 JobTread Create the customer and the job

Saved with contact details, the service address, the job type and the source label.

Review path

The record needs a person to look at it

7. 7 Email by Zapier Send the lead to the office

The office receives the lead details, the reason it stopped and the source label.

Check for Duplicates Before You Create Anything

A lead source may send the same inquiry more than once. If the workflow creates a record every time a payload arrives, the business ends up with duplicate customers, duplicate jobs and two people making the same call.

So the lookup runs before any create action, and a filter stops the run when the lead is already there.

When the source provides a stable, unique lead ID, use that as the duplicate key. Names, phone numbers and addresses are weaker matches: people change numbers, households share surnames, and the same property generates a genuinely different job a year later that address matching would silently discard.

If the source does not provide a reliable ID, write down the fallback matching rule and test it against real edge cases before trusting it.

Test Duplicate, Missing-Field and Failed-Write Cases

A single successful test proves the workflow can create a record once. It does not prove the duplicate rule, the field mapping, the exception path or the reporting fields work.

Before anyone relies on it, test that:

• A new lead creates the expected customer, location and job record.
• A duplicate lead does not create a second one.
• A new lead is not mistaken for a duplicate.
• Required fields arrive in the expected format.
• Missing or blank fields follow the documented fallback.
• An unknown service label is flagged rather than mapped to the wrong job type.
• A rejected record reaches a person with enough detail to act.
• Source, account and job-type fields land where reporting will look for them.
• The office can act on an exception without opening the automation.
• No test exposes client, lead or account data in a system that should not hold it.
• The finished record supports the report the business expects to run later.

That last one is the point of the other ten. A Zap can run green while writing the wrong source label or creating a duplicate job, so test the business outcome, not whether a tool returned a check mark.

Map Marketplace Service Labels to Your Job Types

Lead marketplaces describe work in far more detail than a job-management system needs for reporting. Something has to reconcile the two. If nothing does, every job lands as Other, or a person picks from a dropdown and you are back where you started.

Keep both values on the record:

• The original marketplace label, so someone can see what the source sent and spot a wrong match.
• The mapped job type, so reporting stays consistent.

Then decide what an unmatched label does, because new labels will appear. Route them to a review queue, assign a Needs Review type, or pick another documented fallback. Do not let an unknown label quietly become the wrong job type.

Send Failed Handoffs to a Person

An integration saves the office time only if the team also learns when it did not finish.

Once staff rely on the integration they stop checking the portal. That is the point of building it, and it is also the risk: a silent failure becomes a missed lead you paid for.

So the exception path is one of two designed endings, not error handling bolted on afterwards. When the record cannot be created, the run sends the office the lead details and the reason it stopped.

That path begins after the location check, which gives the workflow a chance to stop before it writes an incomplete or unusable record.

Send Only the Data the Next System Needs

An integration should not become a reason to copy every field into every tool. Before connecting two systems, decide which fields the next team needs to act on, which are needed for reporting, and which should stay where they are.

Then decide who can see the destination system and how long the data stays there.

For healthcare, therapy and other regulated work this is not a detail. Review the data flow with the organization’s privacy and compliance advisers before moving client information between systems, and confirm every tool in the chain is appropriate for the kind of data passing through it. Some systems are deliberately limited here, and the limit is usually there for a reason.

Five Decisions to Make Before You Build

1. Get the feed switched on first. Create the webhook, have the source enable it, then wait. Everything downstream is guesswork until you can see a real payload.
2. Collect several real leads and read them. Which fields are always present, which are sometimes missing, and which arrive in an inconsistent shape. This is where field inconsistencies become visible.
3. Define the duplicate rule before you add any create action. Building the working path first means retrofitting the guard, and retrofitted guards tend to cover half of what they should.
4. Define the exception path. Which inbox or queue receives an uncreated lead, and what the message needs to contain for someone to act without opening the automation.
5. Agree the reporting fields before the first live lead. Source labels, account names and job types are painful to add retroactively.

When a Lead Integration Is Worth Building

It is worth evaluating when staff repeatedly re-enter leads from a portal or inbox, when source information disappears before a job is created, when the office cannot compare channels against booked work, or when leads arriving after hours need routing consistently.

It may not be worth building when volume is low, when the source data is too incomplete to be useful, or when the manual process is already quick and written down. A documented manual process beats a fragile automation.

Start with one source and one destination. A small workflow you can watch is easier to test than a project connecting everything at once. It runs inside tools you already pay for, though vendor changes, API limits and permissions still need occasional attention.

This workflow is an example, not a template. Your lead source, destination system, required fields, privacy obligations and reporting needs may call for a different design.

Need a Clearer Handoff Between Marketing and Operations?

We connect the systems that handle inquiries, scheduling, customer records and reporting. That might be a marketplace or website lead into a CRM or job-management system, a website form into an intake or scheduling system, an ad platform lead into a customer record, or a finished job back into marketing reporting.

Start with the handoff that creates the most manual work or the biggest gap in your reporting, and we will tell you honestly whether it is worth connecting. More on scheduling and lead intake integrations, or see how this sits alongside ads and search work on the Best Austin Handyman project.