Skip to main content
The Spam Monitoring API watches your outbound phone numbers and tells you when a carrier starts flagging them as spam or scam-likely. OptimalDial places periodic test calls to each monitored number across the major US carriers (AT&T, T-Mobile, Verizon), records the label each carrier shows, captures a screenshot, and exposes the result through these endpoints — or pushes it to you over webhooks. It’s available to every account with an API key and an active subscription. Standard rate limits and the 429 envelope apply, exactly as on the rest of the v1 API.

Lifecycle

  1. POST /api/v1/spam/numbers — add a number. Verification is auto-initiated (a call or SMS to the number).
  2. The recipient reads back the code; you submit it to POST /api/v1/spam/numbers/{id}/verify. Missed it? …/verify/resend.
  3. Once verified, OptimalDial re-tests the number daily across each carrier.
  4. You read results via GET /api/v1/spam/numbers / …/{id} (latest per-carrier status), …/{id}/history (recent runs), and …/{id}/screenshot (the captured image) — or subscribe to the spam.detected and number.verified webhook events.

The MonitoredNumber object

The CarrierStatus object


Verification (SMS or call)

Verification is required for the monitoring service to function — OptimalDial must verify the number before it can place test calls on its behalf. It is not an ownership or security gate; it’s a carrier prerequisite for the test traffic.
  • The add endpoint auto-initiates verification. By default it places a call (verification_method: "call"); pass "sms" to receive a text instead.
  • The recipient reads back (or copies) the code and you submit it to …/verify.
  • SMS isn’t deliverable to landlines. Requesting "sms" for a non-SMS-capable number returns 400 — fall back to call.
  • Use …/verify/resend to re-send the code, optionally switching method (e.g. from sms to call).
A number’s verified flag flips to true once a correct code is submitted, and the number.verified webhook fires.

Add a monitored number

Registers a number for monitoring and auto-sends a verification code. Returns 201 with the new MonitoredNumber and a verification block describing how the code was dispatched.

Request body

Response

201 Created:

Errors


Submit a verification code

Submits the code the recipient received. On success the number becomes verified and daily monitoring begins.

Request body

Response

Errors


Resend a verification code

Re-sends the code, optionally switching delivery method. Use this if the first call/SMS was missed, or to fall back to call when sms couldn’t be delivered.

Request body (optional)

Response

Errors


List monitored numbers

Returns your monitored numbers, each with its latest per-carrier status, plus the maximum your plan allows.

Query parameters

Response

spam_monitoring_limit is your effective limit: the numbers included with your plan plus any additional numbers purchased at $5/month each. It is null when your plan (or an admin account) has no cap. Adding a number beyond this limit returns 403. Numbers already monitored beyond the limit (for example after a downgrade) are kept but not tested — the oldest numbers up to the limit are the ones that receive daily tests. Owners can raise the limit from Billing → Spam Monitoring Add-On in the dashboard.

Errors


Retrieve a monitored number

Returns a single MonitoredNumber with its latest per-carrier status.

Errors


List recent test runs

Returns the number’s individual test runs from the last 7 days, newest first. Each row is one carrier’s test on one day.

Response

The TestRunHistoryItem object

Errors


Get the latest screenshot

Streams the most recent captured screenshot for the number as a binary image/jpeg — not JSON. Pass carrier to select a specific carrier’s screenshot; omit it for the most recent across carriers.

Query parameters

The response body is the raw JPEG bytes with Content-Type: image/jpeg. Write it straight to a file (as above) rather than parsing it as JSON. Screenshots captured before the JPEG rollout may still return image/png for up to 7 days (the screenshot retention window) — check the Content-Type header if the distinction matters to you.

Errors


Stop monitoring a number

Removes the number from monitoring. No further test runs are scheduled.

Response

Errors


Webhook alerts

Instead of polling, subscribe to spam-monitoring events on your existing webhook endpoints. They use the same HMAC signing, headers, and retry behaviour as every other event — see the Receiving webhooks guide. Register interest by including the event types when you create or update an endpoint:
See the webhooks guide for the full payload bodies. In short, spam.detected carries the flagging carrier, label, SIP response, and a screenshot_available flag; number.verified carries the number’s id, phone, carrier, and verification time.