CallerAPI Documentation
  1. Use cases
CallerAPI Documentation
  • Quckstart
  • Use cases
    • For carriers (MNOs/MVNOs)
    • CPaaS platforms
    • Cloud communications providers
    • SIP trunking providers
    • PBX/Cloud PBX
    • UCaaS vendors
  • Account
    • Balance and email
      GET
  • Spam protection
    • Spam score + HLR
      GET
    • Fetch daily spam reports
      GET
  • Fraud prevention
    • Ported date
      GET
    • Porting history
      GET
    • Online presence
      GET
    • KYC user identity
      POST
  • Data partners
    • Upload spam reports
      POST
    • Upload contacts
      POST
  • Voice
    • Coming soon...
  • SMS
    • Coming soon...
  • SIP Trunking
    • Coming soon...
  • Schemas
    • Spam protection
      • Spam score request
      • Business info
      • Carrier info
      • Complaint (without number)
      • Daily spam reports request
      • Complaint (with phone)
  1. Use cases

For carriers (MNOs/MVNOs)

Stop spam before it hits your subscribers:#

A customer's main line gets flagged. Legit calls go missing. "Spam Likely" splashes across phones that should never wear that label. They blame you. You don't control the analytics vendors. You do control your edge.
This page is the playbook to cut nuisance traffic without burning good callers. Straight talk. Actionable. Slots in at the SBC.
NOTE
Where CallerAPI sits
At the edge (SBC or ingress proxy). You ask one question before ring: "Do we let this through?" CallerAPI answers with a tier (SPAM / BUSINESS / UNKNOWN) and the why, meaning the raw data. You enforce. That’s it.

What we're actually fixing#

Subscriber experience: less junk ringing, fewer bad labels leaking to handsets.
Support load: fewer "why was I blocked?" tickets because every decision has a reason string.
Revenue protection: less trash to route, fewer dispute credits, cleaner enterprise QoS.

How you run it (keep it boring and predictable)#

CaseDefault actionWhat actually happensWhy this is sane
SPAMBlockDon't ring. Play a short message. Log reason.Obvious junk and known-bad ranges. Save network + agent time.
BUSINESS, but has spam reportsChallengeLightweight IVR (press-to-continue) with a tight timeout.Humans pass. Robocallers choke. Keeps false positives down.
UNKNOWNAllowRoute normally. It is probably a personal number.Don't punish, probably clean traffic.
WARNING
Start conservative. Put borderline traffic in Challenge, not Block. Tighten after a week of data.

The first 30 days#

1
Week 1 - Pilot and test
Make decisions but don’t enforce. Log tier + reasons. Build two live lists: must-pass (VIP ranges, emergency services) and must-block (known abusers).
2
Week 2 - Turn on enforcement
Enforce SPAM = Block on consumer inbound and noisy enterprise DIDs. Keep BUSINESS (with spam reports) = Challenge. Publish a one-line "why blocked" string to ops.
3
Week 3 - Tune by product
Prepaid, postpaid, enterprise trunks behave differently. Adjust per-offer thresholds. If challenge pass-through is high, your thresholds are too tight.
4
Week 4 - Automate the boring stuff
Cache low-risk decisions for a short window to shave latency. Keep signed decision logs on; they settle disputes fast.

What to measure (and how to read it)#

Spam interception rate - if it stalls, widen "SPAM." If complaints spike, you went too far.
Challenge pass-through - low = you're hitting humans; simplify the challenge or loosen thresholds.
ASA / Abandon on enterprise queues - should improve as junk drops.
Dispute rate - every block needs a reason you can hand to the customer. If you can't explain it, don't enforce it.
TIP
Fast win: roll out on the noisiest enterprise DIDs first. It’s where you earn trust immediately.

Edge cases you will hit (handle them up front)#

VIP and critical services
Short codes & bursts
Roaming / recent ports
Neighbor spoofing

Cost & Data Control - High-volume "Daily Spam Report" mode#

Not every carrier wants per-call lookups. Some just want today’s spam intelligence, vetted by our algorithms and humans, for a flat monthly fee. Expenses stay flat. No surprise bills. Here’s that path:
What you get
A daily report of confirmed spam/abuse numbers observed network-wide, validated by our systems and review team. Delivered as a tenant-scoped dataset.
Why it exists
You want predictable cost and an easy ingest step. One (or few) fetches per day. Apply it at the edge. Done.
How you use it
Pull today's reports in JSON format, load into your SBC/edge cache, and enforce the same High/Medium/Low policy... Now you’re using a curated list, not per-call decisions.
Service definition:
Endpoint: a dedicated Daily Spam Report endpoint provisioned per tenant.
Format: JSON.
Fields: number, created date, violated date, consumer state, subject (spam category), robocall (yes/no).
Cutover time: The spam reports are compiled, verified and updated each day before 13:00 UTC, they cover the past 24 hours.
Validation: algorithmic scoring + human review pass on high-impact entries.
Retention: last 24 hours available via the same endpoint.
License: carrier-wide use for inbound controls at your edge.
Price: flat monthly fee (no per-call charges).
Purpose: cost control and predictable ops for very high traffic.
INFO
Ask us to enable Daily Spam Report for your tenant. We'll return a hardened URL, auth method, and a sample file so your ops can wire the nightly job.
You control region and retention policies on your side.
When to use this mode vs real-time:
Use Daily Report if you need budget certainty and can tolerate day-level cadence.
Use Real-time when you need per-call context (queue, geography, campaign) and want IVR challenges on the gray zone.

Rollout etiquette with enterprise customers#

Tell them exactly what happens: obvious garbage is blocked, the gray zone is challenged, and every decision is logged with reasons. Share weekly stats for their DIDs. When they dispute a block, show the reason string. Trust climbs. Churn drops.

Talk to an expert
Make your telco spam-free by integrating CallerAPI.
Modified at 2025-08-08 16:22:26
Previous
Quckstart
Next
CPaaS platforms
Built with