Skip to main content

Run a Pre-Bridge Check before the call connects

Create an HTTP Pre-Bridge Check, attach it to a routing-plan route, and connect, reject, or fail over from the response.

Written by Moja Bot

Location: Webhooks → Pre-Bridge Checks, then Routing Plan → route
​ Use case: After Moja selects a destination, call an external URL before the call is bridged — connect, reject, or fail over from the response

A Pre-Bridge Check runs after a route or target is selected and before Moja bridges the caller. Use it when the check needs to know which buyer won, and the result must decide whether the call connects.

This is not an inbound webhook and not an outbound postback. Creating the check does not run it. It only runs on routes where you attach it.

When to use a Pre-Bridge Check

Goal

Setup

Same eligibility or compliance URL for every buyer on the plan

One check, attached to each route that should run it

Each buyer has its own ping URL, key, or pass rule

One check per buyer, attached only to that buyer’s route

Need caller metadata before any buyer is chosen

Use an inbound call_data webhook, not a Pre-Bridge Check

Need to notify a system after the call ends

Use an outgoing webhook

Required steps

  1. Collect the receiver’s URL, method, headers, query or body, timeout, and the fields that mean pass.

  2. Go to Webhooks → Pre-Bridge Checks and create the check.

  3. Set the request. Use uppercase tags in the URL, query, or body, such as [CALLER_ID], [ZIP_CODE], [STATE].

  4. Add response conditions (for example available equals true, or targets.count greater than 0). Combine with AND when every condition must pass.

  5. Set outcomes for pass, fail, error, and timeout: connect, reject, or fail over.

  6. Open the routing plan and assign the check on the route that should run it. Repeat per route if each buyer has its own check.

  7. Place a test call that can select that route. Confirm the check in the call life log: route selected → check result → connect or reject — before the outbound bridge.

What to send

Send only what the endpoint requires. Typical fields are caller number, state, and ZIP. Put secrets in the URL or headers the receiver specified. Do not copy another account’s API key into a cloned check.

If the receiver needs a lead field that is not a system tag, create that Custom Tag first and put it in the request.

How to test

  1. Confirm the check is on the route that will win, not only saved in Pre-Bridge Checks.

  2. Place one in-hours call that is eligible for that destination.

  3. Open the call life log. You should see the check URL result and the pass/fail/timeout decision.

  4. A pass with connect should dial the target. A fail/error/timeout set to reject should end before bridge (often with no buyer connect).

Troubleshooting

Check never appears on the call

Not attached to the route that was selected, or the call never reached a routing-plan destination.

Always reject

Condition field path does not match the JSON the endpoint returns, or fail/timeout is set to reject. Inspect the logged response.

Timeouts

The endpoint is slower than the check timeout. Raise the timeout only if the buyer agreed; otherwise treat slow as fail.

Wrong buyer received the check

The check is on the wrong route, or one shared check was attached to every route. Use a buyer-specific check when URLs or keys differ.

Related articles

Did this answer your question?