Pushing records with push targets

Push targets send the Loan Officers, Real Estate Agents, Companies, and properties you find in Model Match straight into the tools your team already works in, shaped with the field names each tool expects. Set one up once, and getting a record into your CRM takes a single click.

 

In this article:

1. What a push target is
2. Workspace and personal push targets
3. Creating a push target
4. Choosing which fields are sent
5. Testing and managing a push target
6. Pushing a single record
7. Pushing many records at once
8. Troubleshooting push targets
9. Technical reference for developers
10. Frequently asked questions

What a push target is

A push target in Model Match is a saved destination, such as a CRM intake URL, a Zapier catch hook, or a GoHighLevel inbound webhook, that you can send records to on demand, with each field named the way the destination expects.

Every push target has:

• Name: what the target is called when you pick it from the Export menu.
• URL: the HTTPS address records are sent to.
• Method: POST or PUT.
• Request headers: optional, usually a single Authorization header your destination gave you.
• Record type: the one kind of record it accepts, such as Loan Officers or properties.
• Field mapping: which fields are sent, and what each one is called on the receiving side.

 

Workspace and personal push targets

Every push target in Model Match is either a workspace target, shared with your whole team, or a personal target that only you can see. You choose which when you create it, and that choice can't be changed later.

	Workspace push target	Personal push target
Typical use	The company CRM	Your own CRM or your own Zap
Where it lives	Settings → Workspace → API, in the Push targets section	Settings → Personal → My push targets
Who can create and edit it	Workspace owners and admins	Any member, for their own
Who can see and push to it	Every member (viewers can see it but can't push)	Only you
Label in the product	No badge	A Personal badge beside its name
If its creator leaves the workspace	Stays in place	Deleted, along with its push history

Apart from who owns and sees them, the two kinds behave identically: same form, same record types, same field mapping, same test, same history.

Personal targets stay private. Other members never see your personal target in settings or when they push, and while workspace owners and admins can manage any target in the workspace, a colleague's personal target doesn't appear in an admin's own lists either.

The defaults above can be adjusted in your workspace's role permissions. The relevant permissions are View push targets, Create push targets, Update push targets, Delete push targets, and Push records for workspace targets, and View own push targets, Create own push targets, Update own push targets, Delete own push targets, and Push records to own targets for personal ones.

 

Creating a push target

Let's add one. Both settings pages use the same form, so these steps work for workspace and personal push targets alike.

1. Open Settings → Workspace → API and scroll to Push targets for a workspace target, or open Settings → Personal → My push targets for a personal one. Click Add push target. 
2. Enter a Name, such as "Sales CRM". This is what your team sees in the Export menu, so name it after the destination.
3. Paste the destination's URL. It must start with https://.
4. Choose a Method: POST or PUT. If the destination's instructions don't say, use POST.
5. Choose a Delivery option:
   • One record per request: each record is sent as its own request, with the record as the body. This is the default.
   • Batches: each request carries a JSON array of records, up to the Records per request you set (1 to 500, default 100).
6. Add any Request headers your destination requires, usually a single Authorization header. You can add up to 20.
7. Choose the Record type this target accepts.
8. Review the Fields sent to the target (covered in the next section), then click Create target. 
9. Model Match shows the target's signing secret once. Copy it only if you run your own receiving endpoint and plan to verify requests. Zapier, GoHighLevel, and most CRM intakes ignore it. Click I've saved it to continue.

Each target accepts exactly one record type, and the Export menu only lists targets that match the record on screen. To send both Loan Officers and properties to the same CRM, create two targets.

The record types you can choose from:

• Loan officer: a mortgage loan originator.
• Real estate agent: a real estate agent.
• Mortgage company: a mortgage company.
• Branch: a mortgage company branch.
• Loan: one recorded mortgage, including the property, terms, borrower, seller, and originator.
• Property: a parcel, including address, owner, structure, and loan and sale history counts.
• Real estate office: a real estate brokerage office.

Request header values are stored securely and never shown again. When you edit a target later, a saved header appears as a masked placeholder, and leaving it blank keeps the stored value.

 

Choosing which fields are sent

The field mapping on a Model Match push target decides exactly what your destination receives. Each row pairs a Model Match field on the left with the name your destination expects on the right.

When you choose a record type, Model Match fills in a sensible starting mapping: name, contact details, location, and headline production, under lowercase keys such as first_name, email, and volume_12mo. A new target works on its first save without any changes.

To adjust it:

• Add mapping: adds a row. Pick the Model Match field, then type the destination's field name.
• Reset to defaults: restores the starting mapping for the record type.
• Send every field: clears the mapping, and the form then reads "Every field of the record is sent as-is."

A few things worth knowing:

• Production windows: production figures like volume and units default to the trailing 12 months. For Loan Officers, Real Estate Agents, mortgage companies, and Branches, the same fields are available for 3, 6, 12, 14, 18, and 24 months, so you can map 3-month volume and 24-month volume to separate destination fields. Loans and properties don't have production windows.
• Nested fields: a destination name with a dot, such as properties.email, is sent as a nested value. HubSpot-style intakes often expect this.
• Empty values: if a record has no value for a mapped field, that field is left out of the request entirely rather than sent blank.
• Changing the record type: resets the mapping to the new type's defaults.

A target can hold up to 200 mappings. Map only what the destination will actually use, and the records arriving in your CRM stay clean.

Testing and managing a push target

Click any push target in Settings → Workspace → API or Settings → Personal → My push targets to open its page.

1. Click Send a test right after creating a target.

A test sends a sample record of the target's type, with every field filled in and shaped by your mapping, through the same path a real push takes. The result reads like "Delivered (200, 143ms)" or "Failed (401, 98ms — …)", and it's recorded in the push history like any other send.

The target's page also shows:

• Status: Enabled or Disabled, with a button to switch. A disabled target disappears from the Export menu and refuses new pushes, but keeps its settings and history.
• URL: with a copy button.
• Signing secret: masked, with a rotate button. The new value is shown once, and the old one stops working.
• Request headers: names only, never values.
• Accepts: the record type and either the number of mapped fields or "every field".
• Push history: the last 50 sends, filterable by All or Failures. Each row shows the record, the time, and the outcome.

Every row in Push history has a Replay button, which re-sends the same record to the target's current URL and headers. Replays are marked "replay" in the list, and they work even while a target is disabled, so you can fix a bad Authorization header and resend everything that failed.

Deleting a target removes it for everyone who could use it, along with its push history, and can't be undone.

A test before your team's first real push saves you from finding a broken header the hard way.

 

Pushing a single record

You can push a single record from a Market Insights search, an individual volume report, or a record in the Model Match CRM.

1. Open the record and click Export, then choose a push target from the list.

The list shows only enabled targets that accept this record type. If you have both workspace and personal targets for it, they appear in two groups, Workspace and Personal.

Under each target's name you'll see the last result for this record at that target: "Never pushed", "Pushed 2h ago", or in red, "Failed 5m ago · HTTP 401". A green check marks targets where the last push of this record succeeded, so you can tell at a glance whether it's already in your CRM.

Choosing a target sends the record immediately, with no confirmation step. When it finishes you'll see one of three messages:

• "Pushed to Sales CRM": the destination accepted it.
• "Sales CRM rejected the push (HTTP 500)": the destination answered with an error.
• "Couldn't push to Sales CRM": the push couldn't be made at all.

A single push is one attempt and isn't retried automatically. If it fails, fix the cause and push again, or use Replay in the target's push history. Pushing the same record twice sends it twice, so check the status line before you resend.

Pushing many records at once

You can push an entire set of records, up to 5,000 at a time, from Market Insights search results, an individual volume report, or any list in the Model Match CRM. Bulk pushes work with both workspace and personal push targets.

1. Open your search results or list, click Export, and choose a push target.
2. A bulk push runs in the background, so you don't need to keep the page open. Progress is reported as counts of records sent, failed, retrying, and canceled, along with which records failed and why. You can cancel a bulk push while it's running: anything already in flight finishes, and everything still waiting is marked canceled.

The target's Delivery setting decides how many requests your destination receives:

• One record per request: one request per record. A 5,000-record push is 5,000 requests.
• Batches: arrays of up to Records per request records each. 5,000 records at 100 per request is about 50 requests.

Batches are much faster. As a rough guide, with One record per request a quick destination takes 5,000 records in about five minutes, and a slow one takes about half an hour. Batches cuts that by roughly the batch size.

Unlike single pushes, bulk pushes retry on their own. If the destination is busy, times out, or has a server error, Model Match tries each record up to five times, waiting longer between attempts. If the destination looks like it's down, Model Match pauses sending to it for a couple of minutes rather than hammering it. Errors that won't change on a retry, such as a rejected Authorization header, fail on the first attempt.

A few edge cases:

• Changes mid-push: if the target is disabled, its record type changes, your workspace loses the plan, or the person who started the push loses access, the remaining records are skipped and counted as failed.
• Mapping edits mid-push: apply to records not yet sent, so the destination could receive a mix of old and new shapes.
• Duplicates: in rare cases a destination may receive the same record twice. If that matters to your CRM, have it de-duplicate (see the technical reference below).
• Very large records: a single record over roughly 240 KB can't be sent and is marked failed.

Every record in a bulk push shows up individually in the target's push history, so a failed one can be replayed on its own. For any destination that accepts arrays, Batches is the setting that makes a 5,000-record push feel routine.

Troubleshooting push targets

Most push target problems come down to plan, record type, or a destination setting:

• Push targets don't appear under Export: your workspace isn't on Premium, Ultra, or an eligible Enterprise plan.
• A target is missing from the list: no enabled target accepts that record type, the target is disabled, or it's a colleague's personal target.
• The list says "No push target accepts this record type": create a target for that record type under Settings → Workspace → API, or under My push targets for one only you use.
• "Failed · HTTP 401" or 403: the Authorization header is wrong or expired. Edit the target and re-enter the header value.
• Single pushes fail but bulk pushes work, or the reverse: check Delivery. Batches always sends an array, even for one record.
• A field is missing on the receiving side: either it isn't in the mapping, or that record has no value for it, in which case it's left out of the request.
• You can't add a workspace target: by default only owners and admins can. Add a personal one under My push targets, or ask an admin.

After any fix, click Send a test on the target's page. A "Delivered" result confirms the destination is accepting pushes again.

Technical reference for developers

This section is for teams building their own receiving endpoint. If you're sending to Zapier, GoHighLevel, or a standard CRM intake, you can skip it.

Every push from Model Match carries these headers, in addition to any you configured:

Header	Meaning
X-Push-Signature	sha256=<hmac>: HMAC-SHA256 over <timestamp>.<body> using the target's signing secret
X-Push-Timestamp	The timestamp used in the signature
X-Push-Entity	The record type: originator, agent, company, branch, loan, property, or office
X-Push-Entity-Id	The record's id. Not sent on batch requests, since each array element is its own record
X-Push-Target	The push target's id

Bulk pushes add:

Header	Meaning
X-Push-Batch-Id	Identifies the bulk push
X-Push-Item-Id	Identifies one record, or one array of records. Stable across retries, so it's the key to de-duplicate on
X-Push-Item-Count	Number of records in the array (Batches delivery only)
X-Push-Signature-V2	sha256=<hmac> over <timestamp>.<itemId>.<body>. Verify this one if you de-duplicate on the item id, since the original signature doesn't cover it

The internal record-type ids in X-Push-Entity differ from the product labels: originator is Loan officer, company is Mortgage company, and office is Real estate office.

Model Match sets Content-Type, Content-Length, Host, and any header starting with X-Push-, so those can't be overridden in a target's request headers.

Payload example. A Loan Officer target with this mapping:

[   { "source": "nmlsId", "target": "external_id" },   { "source": "contact.workEmail", "target": "properties.email" } ]

receives this with One record per request:

{ "external_id": "12345", "properties": { "email": "sam@work.example.com" } }

and this with Batches, the same object inside an array:

[{ "external_id": "12345", "properties": { "email": "sam@work.example.com" } }]

Responding. Answer with any 2xx status to mark a push delivered. Your endpoint has 10 seconds to respond. On bulk pushes, a 429, 408, any 5xx, or a timeout is retried up to five attempts in total, starting around 30 seconds apart, doubling, capped at 15 minutes, and honoring your Retry-After header. Any other 4xx is treated as final.

Signature verification is optional. The scheme matches Model Match webhooks, so a receiver that already verifies webhook signatures can reuse that code. Delivery is at least once, so receivers that can't tolerate duplicates should de-duplicate on X-Push-Item-Id.

Frequently asked questions

Does pushing records use credits? No. Single pushes, bulk pushes, and tests don't use any credits.

I lost the signing secret. Can I see it again? No, but you can replace it. Open the target's page and rotate the secret. The new value is shown once, and the old one stops working immediately, so update your receiving endpoint at the same time.

Can I turn my personal push target into a workspace one? Personal and workspace targets are set when they're created. To share a destination with your team, create a new workspace target with the same URL, headers, and mapping, then delete the personal one.

A teammate left the company. What happens to their push targets? Their personal push targets, and the push history for them, are deleted when they leave the workspace. Workspace push targets they created stay in place and keep working for everyone else.

We downgraded our plan. Are our push targets gone? No. Your existing targets are still listed in settings, and you can view or delete them. Creating, editing, testing, and pushing to them is available again once you're back on Premium, Ultra, or an eligible Enterprise plan.

Why is my CRM showing the same loan officer twice? Model Match sends a record every time someone pushes it, so pushing the same Loan Officer twice creates two sends. Check the status under each target's name before pushing, and have your CRM match on a stable field such as NMLS ID so repeat pushes update a record instead of creating a new one.