Use case: Receive lead data from a publisher, attach it to the inbound call, and send it to the right buyer at the right time.

Audience: Publishers sending pre-call lead data into Moja. This is not a guide to configuring buyer-side RTB endpoints.

A data-pass campaign has two separate decisions:

How does the data enter Moja?
Which buyers are allowed to receive it?

Data can enter on the inbound RTB ping itself, or on a separate call_data webhook. The second decision is the same either way. An Agent Availability Check can send the lead data to every buyer being evaluated. A Pre-Bridge Check sends it only to the selected buyer.

Choose the right path

What are you trying to do?	Use
Receive publisher fields on the inbound RTB ping	Inbound RTB query, body, or header fields + matching Custom Tags
Receive publisher fields on a static or DID call that may arrive before the data	`call_data` incoming webhook + Wait For Pre Call Webhooks
Send data to every buyer Moja evaluates	Agent Availability Check
Send data only to the selected buyer before connection	Pre-Bridge Check

Recommended default: Use a Pre-Bridge Check when the payload contains personal information, the buyer charges per request, or non-selected buyers should not receive the lead.

Part 1: Receive publisher data in Moja

Choose one inbound method. Do not stack both unless the publisher truly sends two independent payloads.

Path A: Data arrives on inbound RTB

Use this when the publisher posts an inbound RTB request and the lead fields are already on that request.

Create a Custom Tag in Moja for every extra field you need to keep, such as lead_id, zip_code, publisher_sub_id, or income_range. Create the tags before traffic. A later Call Flow will not recover ping fields that were never stored.
Have the publisher send those fields on the inbound RTB request as query parameters, JSON body fields, or headers.
Moja normalizes inbound RTB tags and parameters before routing-plan resolution and Call Flow execution, so filters, RTB bodies, Agent Availability Checks, and Pre-Bridge Checks can read them.

Do not add Wait For Pre Call Webhooks for this path. Ignore on inbound RTB requests is enabled by default, so the wait node is skipped during inbound RTB evaluation. The ping already carries the data; there is no separate webhook race to wait for.

Do not create a Custom Tag named call_id. That key is reserved for Moja’s call id. A publisher’s own id must use a different key, such as pub_call_id or external_id.

Path B: Data arrives on a separate call_data webhook

Use this when the call is a static or DID path and the publisher fires lead data separately, often at the same time as the call.

Go to Webhooks → Incoming.
Create an incoming webhook with type call_data.
Attach the incoming webhook to the campaign that receives the calls.
Create a Custom Tag for every extra field you need to preserve.
Give the portal-generated webhook URL to the publisher. Do not rebuild the URL from an example.

Correlation key

The publisher must send caller_id. Moja matches the request to the campaign call using the campaign and caller ID.

Send the same normalized E.164 caller_id on the webhook and the call, for example +15555551212.
phone_number is not a substitute for caller_id on this endpoint.
A successful webhook response confirms that Moja received the request. It does not, by itself, prove the data was attached before routing began.

Illustrative JSON payload:

{
  "caller_id": "+15555551212",
  "lead_id": "publisher-lead-123",
  "zip_code": "37919"
}

This shows the request body only. Use the webhook URL and authentication key generated in your portal; do not reconstruct a URL from this example.

Handle the timing race

A call can arrive before or alongside the publisher’s webhook. Add Wait For Pre Call Webhooks to the campaign Call Flow before the Routing Plan node.

Open the campaign’s Call Flow.
Place Wait For Pre Call Webhooks before routing.
Set a bounded wait from 1 to 10 seconds. The portal default is 1 second.
Define what happens when required data is missing: continue without it, branch to an IVR, or end the call.

Important: The wait node continues to the next node when its timer expires, even when no matching request was found. Add a condition after it if routing must not continue without a required tag.

Part 2: Send data to buyers

Part 2 does not change based on Path A or Path B. Once the fields are tags on the call, disclosure timing is the same.

Option A: Agent Availability Check

Use an Agent Availability Check when each evaluated buyer must confirm eligibility or staffing before Moja chooses a destination.

Moja runs enabled availability checks across the routes being evaluated. A passing buyer remains eligible. A buyer whose check fails or times out is skipped, and routing continues.

Disclosure warning: Because this happens before selection, the same prospective lead can be sent to more than one evaluated buyer.

Use this only when:

Every evaluated buyer is allowed to see the submitted fields.
The buyer’s endpoint is genuinely an eligibility or agent-availability check.
You understand any per-request charge imposed by the buyer.

Configure it on the relevant Target or RTB Target. The standard timeout defaults to 1000 ms. Treat errors and timeouts as unavailable.

Option B: Pre-Bridge Check

Use a Pre-Bridge Check when the lead data must go only to the selected buyer.

The check runs after Moja selects that route and before the caller is bridged. Its response can allow the connection, reject it, or move the call to failover.

Go to Webhooks → Pre-Bridge Checks.
Create the request with the buyer’s URL, method, headers, query or body, timeout, and pass conditions.
Insert Moja tags in the request, such as [CALLER_ID], [ZIP_CODE], and your configured Custom Tags.
Set explicit outcomes for pass, fail, error, and timeout: connect, reject, or fail over.
Attach the check to the buyer’s route in the Routing Plan.

Important: Creating a Pre-Bridge Check does not activate it. It runs only on routes where it is attached.

Examples

SSDI on a static number with a pre-call webhook

A publisher sends an SSDI call to a campaign number and posts lead data to the campaign’s call_data webhook.

The publisher sends caller_id, lead_id, zip_code, and the approved qualification fields.
The Call Flow waits briefly for the matching webhook.
Moja applies fields whose Custom Tags already exist.
Routing evaluates eligible buyers.
The selected buyer receives the approved payload through its attached Pre-Bridge Check.
If the buyer passes the request, Moja bridges the caller. If it fails, errors, or times out, the route follows the configured outcome.

SSDI on inbound RTB

The same buyer handoff works when the publisher includes those fields on the inbound RTB ping instead of a separate webhook.

Custom Tags exist before the ping.
The publisher sends lead_id, zip_code, and the approved fields on the inbound RTB request.
Moja stores matching tags during ping evaluation. There is no wait node.
When the correlated inbound RTB call arrives through the allocation and call path Moja created for that request, routing uses those tags. This is not a generic lookup that attaches an earlier RTB ping to any later call on a static DID.
The selected buyer still receives data only through the attached Pre-Bridge Check, unless you intentionally used Agent Availability Check.

Payload rules

Send only fields needed for routing and handoff.
Create matching Custom Tags before testing, whether the source is inbound RTB or call_data.
Use consistent lower-case tag names when configuring custom fields. Existing upper- or mixed-case references still resolve because tag matching is case-insensitive.
Use the portal-generated authentication details. Never place secrets in screenshots or shared tickets.
Do not send sensitive personal information to an Agent Availability Check unless every evaluated buyer is authorized to receive it.
Confirm whether the buyer bills for every request, every accepted request, or every connected call.

Timeout and retry behavior

Step	When it times out or fails
Inbound RTB ping fields	Missing Custom Tags are dropped. There is no wait. Add filters or a Call Flow condition if required fields must be present.
Wait For Pre Call Webhooks	The flow continues. Use a following condition to enforce required data.
Agent Availability Check	That destination becomes ineligible; routing continues to other eligible routes.
Pre-Bridge Check	Moja follows the configured timeout or error outcome: connect, reject, or fail over.

Design live-call integrations around short, bounded timeouts. Do not rely on automatic retries during the same routing attempt. If a receiving system needs asynchronous retries after the call, use the appropriate post-call integration instead.

Test checklist

Confirm required Custom Tags exist before sending traffic.
Inbound RTB path: send a ping that includes the extra fields, then confirm those tags are present on the request and the later call.
Webhook path: confirm the incoming webhook is attached to the correct campaign.
Webhook path: send a test with a unique normalized E.164 caller_id and verify the webhook and call use the exact same value.
Webhook path: test webhook-before-call, webhook-during-wait, and no-webhook cases.
Confirm missing-data fallback follows the intended branch.
For Agent Availability, confirm which buyers received requests and which passed or failed.
For Pre-Bridge, confirm only the selected buyer received the request.
Test pass, fail, error, and timeout outcomes before sending live traffic.
Confirm the call connects or fails over exactly as configured.

Pass publisher data into Moja and send it to buyers (data-pass campaigns)