Audience: Moja customers who migrated from Ringba and their Ringba-based publishers.

Use case: A publisher has useful caller data in Ringba — for example caller ID, ZIP code, Ringba call ID, address, geo, or other custom fields — and the Moja customer needs that data available in Moja before routing the call onward.

This workflow is for a normal/static call path into Moja. The publisher does not need to export the call through Ringba RTB for this approach.

Plain-English workflow

The publisher receives or generates caller data in Ringba. Examples include caller ID, Ringba call ID, ZIP code, address, geo fields, or other tags.
The publisher sends the call into the Moja customer. The call can route into Moja through a normal/static inbound path.
The publisher fires a Ringba tracking pixel/webhook to Moja. The pixel sends caller_id plus the additional fields the Moja customer needs.
Moja matches the data to the call by caller ID. caller_id is required. phone_number is not a substitute for matching.
Moja applies matching custom tags to the call. Extra fields apply as tags only when the same custom tag names already exist in Moja.
Moja uses the data for routing, reporting, or buyer handoff. For example, Moja can pass zip_code into an outbound RTB request so a buyer can decide whether to bid on or accept the call.

Key requirements

Use the call_data incoming webhook type.
Send requests to https://webhooks.moja.cloud/call-data.
Include moja_auth_key on the query string for every request, even for POST requests.
Include caller_id. Moja returns 400 Missing caller_id parameter when it is missing. E.164 format, such as +15555551212, is preferred.
Create the custom tags in Moja before sending extra fields such as zip_code, ringba_call_id, or publisher_sub_id.
Attach the incoming webhook configuration to the correct campaign so the received data can enrich that campaign’s calls.
Configure the webhook lifespan/match window. When the pixel may arrive with or after the call, put Wait For Pre Call Webhooks in the campaign call flow before the routing plan; the wait is optional if pre-call data reliably arrives before the call. Always define fallback behavior.

Definitions

Ringba sharable tags

Sharable tags are Ringba fields that can be passed from one Ringba instance to another when a call is transferred.

Important distinction: sharable tags are primarily a Ringba-to-Ringba feature. In this Moja workflow, they matter because they identify which values exist in Ringba and which values the publisher may be able to send to Moja through a tracking pixel/webhook.

Ringba tracking pixel / webhook

A Ringba tracking pixel is an outbound request Ringba can fire when a call event happens.

For this workflow, the publisher uses a Ringba pixel/webhook to send call data from Ringba to Moja.

The pixel must include:

caller_id — required so Moja can match the data to the call. E.164 format, such as +15555551212, is preferred.
ZIP code, if available and needed
Ringba inbound call ID, if useful for troubleshooting
Any other fields the Moja customer needs downstream, using field names that match Moja custom tags

Use the earliest reliable Ringba call event where the required values are already populated. Validate the exact trigger in the publisher’s Ringba account.

Data enrichment URL

A data enrichment URL is a Ringba publisher-side mechanism that can attach extra data, such as ZIP code, before or during the call flow.

If ZIP code is not coming from standard Ringba fields or sharable tags, the publisher may be enriching the call and then passing ZIP/caller data as URL parameters.

Moja incoming webhook / pre-call data

A Moja incoming webhook receives data from an external system and can attach it to a call.

For this workflow, use the incoming webhook type call_data. Ringba sends Moja a request containing caller_id and fields like zip_code. Moja uses caller_id to match the incoming data to the active or soon-to-arrive call.

Authentication and payload examples

Authentication rule

moja_auth_key must be included on the query string. Do not send the auth key only in the JSON body.

This applies to both GET and POST requests:

https://webhooks.moja.cloud/call-data?moja_auth_key=YOUR_AUTH_KEY

If a Ringba/ReadyMode-style client drops query parameters on POST, Moja will reject the request with 401 Missing moja_auth_key parameter. Confirm the final request URL in the client’s pixel preview or request logs.

GET example

GET https://webhooks.moja.cloud/call-data?moja_auth_key=YOUR_AUTH_KEY&caller_id=%2B15555551212&zip_code=33139&ringba_call_id=optional-ringba-call-id

Field behavior

Field	Required?	Notes
`caller_id`	Yes	Required for matching. `phone_number` is not a substitute for `caller_id`.
`zip_code`	No	Use only if the same custom tag exists in Moja and the value is needed downstream.
`ringba_call_id`	No	Useful for troubleshooting if a matching Moja custom tag exists.
Other fields	No	Applied as tags only when the key matches an existing Moja custom tag name.

Customer-side guide: Moja customer / migrated Ringba buyer-network

What you need from your publisher

Confirm they can fire a Ringba tracking pixel/webhook when a call is sent to your Moja number.
Confirm the pixel can include caller_id.
Confirm the pixel can include the fields you need, especially ZIP code if routing depends on ZIP.
Confirm whether those values come from Ringba sharable tags, custom tags, URL parameters, or a data enrichment URL.
Confirm which Ringba trigger they plan to use and whether the required fields are populated at that trigger time.
Ask them to use Ringba’s live token picker and pixel preview rather than copying sample placeholder tokens.

What you configure in Moja

Create an incoming webhook configuration with type call_data.
Copy the generated auth key and build the full endpoint as https://webhooks.moja.cloud/call-data?moja_auth_key=YOUR_AUTH_KEY.
Create custom tags for each extra field you want attached to calls, such as zip_code, ringba_call_id, or publisher_sub_id.
Attach the incoming webhook configuration to the correct campaign using the campaign’s incoming webhooks setting.
Configure the webhook lifespan/match window so Moja can match webhook data that arrives shortly before or shortly after the call.
Use a campaign call flow for routing when pre-call fields matter. Put a Routing Plan (or other routing nodes) after any wait/enrichment steps so Moja has a chance to attach Ringba pixel data before ZIP-based filters, RTB bids, or buyer selection run.
Add a Wait For Pre Call Webhooks node near the start of that call flow when timing is uncertain. Set a short duration so the flow pauses briefly for the Ringba pixel/`call_data` match, then continues into the routing plan. Why: the call and the pixel are separate paths — if routing runs immediately, Moja may decide before zip_code or other tags exist on the call.
Optional when data reliably arrives before the call. If the publisher’s pixel consistently lands early enough that Moja already has the match when the call arrives, you can skip or minimize the wait node. Keep lifespan/match window configured either way, and re-add wait if you see 200 webhooks with missing tags or late enrichment.
Configure the fallback path if the data does not arrive in time, such as routing without ZIP, routing to a default buyer, or declining according to your business rules.
Configure routing/RTB logic (in the routing plan or later nodes) to use the incoming fields, such as passing zip_code into the outbound RTB request.

Testing checklist

Run at least one controlled test call before relying on the workflow.

The call arrives in Moja.
The Ringba pixel fires.
Moja incoming webhook logs show a received request.
The request URL includes moja_auth_key on the query string.
The request contains caller_id.
The caller ID format matches what Moja sees on the call. E.164 format, such as +15555551212, is preferred.
Custom fields arrive with the expected names.
Matching custom tags already exist in Moja.
The incoming webhook is attached to the campaign receiving the call.
The pre-call webhook data is matched to the call within the configured window (after any Wait For Pre Call Webhooks duration).
The call follows the intended route or fallback path.
The downstream buyer/RTB request includes the expected fields.

Publisher-side guide: Ringba publisher

Goal

Send caller data from your Ringba account to your partner’s Moja account at the time you send the call.

This lets your partner continue receiving important fields — such as ZIP code or call metadata — even if the call is no longer going Ringba-to-Ringba.

Step 1 — Confirm which fields are available

Confirm which values exist in Ringba before configuring the pixel:

Caller ID
ZIP code
Ringba inbound call ID
Address or geo fields
Any custom/sharable tags your partner needs

Step 2 — Map Ringba values to Moja fields

Use Ringba’s live token picker and pixel preview to select the real token for each value. Do not rely on example brace macros from documentation.

Moja field	Ringba setup instruction	Notes
`caller_id`	Select Ringba’s live caller ID token.	Required. Must match the phone number Moja sees on the inbound call.
`zip_code`	Select the live ZIP/postal token, data enrichment output, or custom tag value.	Moja customer must create a matching `zip_code` custom tag first.
`ringba_call_id`	Select the live Ringba call ID token.	Optional but useful for troubleshooting.
Other custom fields	Select the live Ringba token for each agreed field.	The key must match a Moja custom tag name to apply as a tag.

Step 3 — Configure the Ringba pixel/webhook

Use the Moja customer’s endpoint:

https://webhooks.moja.cloud/call-data?moja_auth_key=YOUR_AUTH_KEY

Recommended method:

Use POST with JSON body when Ringba preserves query parameters on POST.
If the tool drops query parameters on POST, use GET or adjust the pixel setup so moja_auth_key remains on the final request URL.
Confirm in Ringba’s pixel preview/logs that the final URL still contains moja_auth_key.

Step 4 — Test with the Moja customer

Place a controlled test call.
Confirm the Ringba pixel fired.
Confirm the final request included caller_id and the needed fields.
Confirm Moja received the webhook and matched it to the call.
Confirm downstream routing or buyer handoff used the expected data.

Failure modes and fixes

401 Missing moja_auth_key parameter

Cause: The request did not include moja_auth_key on the query string.

Fix: Put moja_auth_key in the URL query string. If using POST, confirm the sending platform does not strip query parameters from the final POST URL.

401 Invalid auth key

Cause: The key is present but does not match the Moja incoming webhook configuration.

Fix: Copy the auth key from the correct Moja call_data incoming webhook configuration and confirm the webhook has not been deleted or replaced.

400 Missing caller_id parameter

Cause: The request did not include caller_id.

Fix: Send caller_id in the JSON body or query string. Do not rely on phone_number alone.

Webhook receives 200 but the call is not enriched

Possible causes:

The incoming webhook is not attached to the campaign receiving the call.
The webhook type is not call_data.
The custom tags do not exist in Moja.
The caller ID format does not match the call.
The webhook arrived outside the configured lifespan/match window.
The call flow does not include a long enough Wait For Pre Call Webhooks node.

Fix: Verify campaign attachment, webhook type, caller ID format, custom tag setup, lifespan/match window, and Wait For Pre Call Webhooks / fallback behavior.

ZIP code does not appear downstream

Cause: The request may include ZIP, but the Moja custom tag may be missing or named differently.

Fix: Create the exact custom tag name in Moja, such as zip_code, then send the same key from Ringba. Verify the downstream routing/RTB mapping references the same field name.

Data arrives after the call has already routed

Cause: The call arrived before the Ringba pixel/webhook.

Fix: Add or tune a Wait For Pre Call Webhooks node before the routing plan in the call flow. Set the duration long enough for the pixel to arrive but short enough to avoid a poor caller experience. If the pixel already arrives before every call, the wait can stay short or be removed after you prove it. Always configure a fallback path.

Short version to send to a Ringba publisher

Please configure a Ringba pixel/webhook to send caller data to our Moja incoming webhook when you send the call to our Moja number.

Moja endpoint:

https://webhooks.moja.cloud/call-data?moja_auth_key=YOUR_AUTH_KEY

Requirements:

Use Ringba’s live token picker for each value.
Include caller_id. This is required for Moja to match the data to the call.
Include ZIP code and any other agreed fields.
Keep moja_auth_key on the query string. Body-only auth will fail.
Confirm the final request in Ringba’s pixel preview/logs before testing.

Example POST body:

{
  "caller_id": "+15555551212",
  "zip_code": "33139",
  "ringba_call_id": "optional-ringba-call-id"
}

Implementation ownership

Publisher: Configures the Ringba pixel/webhook and selects the correct live Ringba tokens.
Moja customer: Creates custom tags, attaches the call_data incoming webhook to the campaign, uses a call flow with optional Wait For Pre Call Webhooks before the routing plan when timing requires it, configures fallback behavior, and maps fields into routing or buyer handoff.
Moja support: Helps validate webhook receipt, caller ID matching, campaign attachment, and downstream field mapping during testing.

Passing Ringba pre-call data into Moja with tracking pixels