Developers

One webhook. Then the phone rings.

If your system can send a POST request, it can place a governed, personalised phone call. No telephony knowledge, no SDK, no infrastructure project.

bash
curl -X POST https://api.bedrock.pressone.co/v1/signals/webhooks/{your-signal-token} \
  -H "X-Signal-Secret: $SIGNAL_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "event_id": "kyc-stall-user-84213",
    "phone_number": "+2348012345678",
    "name": "Emeka",
    "pending_step": "ID upload",
    "metadata": { "funnel": "kyc", "cohort": "2026-07" }
  }'

One valid POST → one call. Authorization: Bearer is accepted as an alternative to X-Signal-Secret. Dynamic template parameters ride as top-level string fields (or a nested parameters object, if you prefer). Responses are explicit: 202 accepted, 200 duplicate (your event_id was already processed — the original outcome is returned, no second call), 401 bad credentials, 422 rejected with the reason, 503 transient — retry safely.

The model

  • A Signal is a configured call use case. Message template, voice, keypad options, and one active webhook endpoint. You create it in the dashboard; your code only ever sends events.
  • Personalisation from the payload. Template parameters ({{name}}, {{pending_step}}) are filled from each event's top-level fields. Events missing required parameters are rejected before dispatch, with the missing fields listed — a bad event never becomes a bad call.
  • Idempotency on your event_id. Redeliveries and retries on your side do not create duplicate calls.
  • Keypad capture. Define single-digit options (1 = send link, 2 = request callback, 9 = opt out); the pressed digit and its label come back in the call record. An opt-out digit writes straight to the account's do-not-call list.
  • Guardrails are platform-side. Suppression checks, calling windows, and frequency limits run before dispatch on every event. Your bug cannot become a 2 a.m. call storm.

Consuming results

Call outcomes are delivered as account-level webhook events through the PressOne developer add-on:

signal.call.initiated
signal.call.ringing
signal.call.answered
signal.call.completed

signal.call.completed is terminal for every outcome — answered, busy, no answer, failed, expired, suppressed, rejected — and carries the Signal ID, run ID, call ID, recipient, final status, duration, keypad response, failure reason, and your original metadata. Deliveries are HMAC-signed, retried with backoff, idempotent per event, and covered by a delivery audit log.

Straight answer on gating: programmatic result consumption requires the developer add-on on your PressOne account. Dashboard reporting — every run, call, and keypress — is included with Signals itself.

The "press 1 and we'll text you the link" pattern, honestly: Signals captures the keypress and hands it to you in the completed event. The text message is yours to send — one webhook consumer, one SMS call from your own stack, exactly the way you'd act on any other event. Signals places calls; it does not send SMS on your behalf. If your script promises a text, your system keeps that promise.

Test before you're live

Send a test payload to validate acceptance without placing a call, or place a real test call to your own phone. Test runs are marked as tests and excluded from production reporting and result events.

No event pipeline? No problem.

Signals also runs without code: download the CSV template generated from your Signal's own parameters, fill it, upload it, review the validation preview, confirm. The upload is the run. Failed and unanswered recipients can be re-run in one action.

What we won't pretend

  • Calls are triggered by your events about your existing customers. There is no bulk-list campaign mode, by design.
  • Retries are explicit: a manual "re-run failed" action targeting only unanswered/failed recipients. There is no silent automatic redial.
  • Conversational AI calls are not available today.

You are integrating against what exists, and what exists is deliberately narrow: an event in, a governed call out, a signed record back.

Ship it this afternoon.

Request access, wire one webhook into your staging environment, and ring your own phone before your standup ends.