FEATURE ENHANCEMENT RELEASE

Location: Webhooks → Incoming
Release Date: March 27, 2026

We've introduced a powerful new webhook type — update_fields — that lets you update multiple call record fields in a single postback request. No more chaining separate revenue and tag updates — handle everything in one call.

What's New

update_fields Webhook Type — A new unified incoming webhook type that accepts any combination of field updates in one request.

The following fields can be updated on an existing call record:

converted (boolean) — Mark a call as converted or remove conversion status
call_converted_at (datetime or null) — Set an explicit conversion timestamp
revenue_paid_out (number) — Override the revenue payout amount
publisher_paid_out (number) — Override the publisher payout amount (completed calls only)
reason (string or null) — Set or clear the call reason/disposition
no_payout_reason — Set or clear a payout hold reason. Values: Campaign preconversion, Condition not met, Caps exceeded, or null (completed calls only)
add (object or array) — Add or update tags on the call
remove (string or string[]) — Remove tags by key

GET and POST Support — Send postbacks via POST (JSON body) or GET (query parameters). GET support is useful for simple integrations, tracking pixels, or systems that can only fire a URL. GET is also now available on the existing update_revenue and update_tags endpoints.

Flexible Payload Structure — Fields can be sent at the top level or nested inside a fields object — both formats work. Calls can be identified by call_log_id or phone_number.

Live and Completed Call Support — Postbacks work regardless of call state. Completed calls are updated directly. For live/active calls, updates are queued and applied when the call completes.

Why This Matters

Handle conversion + revenue + disposition + tags in a single request instead of managing multiple webhook configs. GET support opens the door to simpler integrations that don't require building a POST request.

Example Use Cases

A lead management system sends a single postback when a lead converts: sets converted, revenue, and reason — all in one request
A tracking pixel fires a GET URL with revenue and conversion data as query parameters
A CRM updates publisher payouts and hold reasons on completed calls for billing reconciliation

Getting Started

Navigate to Webhooks → Incoming → Create
Select type update_fields
Copy the generated auth key and endpoint URL
Configure your external system to send POST or GET requests with the call identifier and fields to update
Test with a completed call to verify fields are updated correctly

Note: The existing update_revenue and update_tags webhook types continue to work exactly as before.

Batch Updates — Now Available

Batch updates are here. As of April 3, 2026, the update_revenue, update_tags, and update_fields postback types accept an array of call_log_id values — letting you update up to 50 calls in a single request.

Existing single-ID requests are unchanged. Batch support is fully backward-compatible.

What's new

Previously, each postback request updated exactly one call. Now you can pass call_log_id as a JSON array to apply the same update to multiple calls at once.

Before (single — still works):

{
  "call_log_id": "abc-123",
  "converted": true,
  "revenue_paid_out": 25.50
}

Now (batch):

{
  "call_log_id": ["abc-123", "def-456", "ghi-789"],
  "converted": true,
  "revenue_paid_out": 25.50
}

Key details

Supported postback types	`update_revenue`, `update_tags`, `update_fields`
Maximum calls per request	50
HTTP method required	POST with a JSON body. (GET continues to work for single-ID requests only.)
call_log_id and phone_number	You cannot pass an array `call_log_id` together with `phone_number` in the same request. Use one or the other.
Same values applied to all calls	The field values in the request body are applied to every call in the array. To set different values per call, send separate requests.

Response

The response for a batch request includes:

call_log_ids — IDs that were successfully updated.
failed_call_log_ids — IDs that could not be updated. Empty if all succeeded.

{
  "call_log_ids": ["abc-123", "def-456"],
  "failed_call_log_ids": ["ghi-789"]
}

A failed ID does not block the rest of the batch. Check failed_call_log_ids on every response and retry individually if needed.

Examples

Batch update_revenue:

POST {base_url}/update-revenue?moja_auth_key={auth_key}{
  "call_log_id": ["abc-123", "def-456", "ghi-789"],
  "revenue_paid_out": 25.50
}

Batch update_tags:

POST {base_url}/update-tags?moja_auth_key={auth_key}{
  "call_log_id": ["abc-123", "def-456", "ghi-789"],
  "add": [{"customer_type": "premium"}],
  "remove": ["old_tag"]
}

Batch update_fields:

POST {base_url}/update-fields?moja_auth_key={auth_key}{
  "call_log_id": ["abc-123", "def-456", "ghi-789"],
  "converted": true,
  "revenue_paid_out": 25.50,
  "disposition": "sale"
}

Webhook Postbacks: Multi-Field Call Updates