​

STIR/SHAKEN attestation

​

What the attestation levels mean

​

Signing vs. signalling: who does what

1. Orbit computes the level. On every outbound call — API-initiated calls, dialer campaigns, transfers, conference dial-out, verification calls — Orbit resolves the caller ID against your ownership and lease records and any delegate certificates you registered, producing A, B, or C.
2. Orbit signals the level. The resolved level travels on the outbound INVITE as the custom X-Devotel-Attest: <A|B|C> SIP header.
3. Devotel’s wholesale softswitch signs. Every outbound leg terminates on the carrier-of-record softswitch Devotel operates. It holds the STIR/SHAKEN signing certificate, reads the signalled level, and cryptographically signs the PASSporT at that level — it will never sign higher than what the platform attests.

​

Reading attestation on inbound calls

• Pre-verified results (the common case). Devotel’s softswitch verifies the PASSporT signature upstream and forwards the result as an RFC 8588 Verstat / P-Attestation-Indicator value (TN-Validation-Passed-A/B/C, TN-Validation-Failed, No-TN-Validation). This is the state for roughly all PSTN inbound traffic.
• Raw Identity header. When no pre-verified result is present, Orbit decodes the PASSporT payload and surfaces the claimed attestation level — flagged as not yet verified.

​

Tenant attestation policy

​

The policy fields

​

What the policy does — and does not do

curl -X PUT "https://api.orbit.devotel.io/api/v1/compliance/attestation/policy" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_attestation": "A",
    "downgrade_handling": "alert",
    "inbound_min_verification": "B",
    "flag_unverified_inbound": true
  }'

​

Reading the posture snapshot

{
  "data": {
    "policy": {
      "target_attestation": "A",
      "downgrade_handling": "alert",
      "inbound_min_verification": "B",
      "flag_unverified_inbound": true,
      "updated_at": "2026-08-20T14:03:11.000Z"
    },
    "originating": {
      "summary": {
        "total": 12,
        "meeting_target": 9,
        "below_target": 3,
        "by_level": { "A": 9, "B": 3, "C": 0 }
      },
      "numbers": [
        {
          "phone_number": "+14155550100",
          "source": "owned",
          "attestation": "A",
          "meets_target": true
        },
        {
          "phone_number": "+14155550777",
          "source": "leased",
          "attestation": "B",
          "meets_target": false
        }
      ],
      "numbers_truncated": false
    },
    "inbound": {
      "window_days": 30,
      "window_start": "2026-07-27T10:15:00.000Z",
      "window_end": "2026-08-26T10:15:00.000Z",
      "summary": {
        "total": 1840,
        "verified": 1712,
        "unverified": 96,
        "spoof_risk": 32,
        "verified_rate": 0.9304
      }
    }
  }
}

• originating.numbers[] lists each of your originating numbers with the level calls from it actually attest at: owned (a number your org owns through Orbit) → A, leased (an active pool assignment) → B. A number you hold neither way is never listed. meets_target compares that applied level against your target_attestation, and originating.summary aggregates the same into meeting_target / below_target counts. The list caps at 500 numbers (numbers_truncated tells you when you hit the cap).
• inbound.summary classifies the inbound calls that arrived on your DIDs over the trailing 30-day window: signed calls at or above your inbound_min_verification floor count as verified; signed-but-below-floor and off-net (unknown) calls count as unverified; failed and unsigned (none) calls count as spoof_risk when flag_unverified_inbound is on, otherwise they fall into unverified. verified_rate is the verified share of all inbound calls, or null (not zero) when there was no inbound traffic in the window — so you can tell “no calls” apart from “0% verified.”

​

Raising from B to A is an ownership play, not a PUT

1. Purchase or port the numbers into Orbit so your org owns them outright.
2. Move your outbound traffic onto the owned DIDs.
3. Re-read the posture snapshot — those numbers now resolve to A and meeting_target closes the gap.

​

What you control

• Number ownership (highest-leverage). Owning a number through Orbit is the only path to A attestation. If your answer rates matter, run your traffic from owned DIDs rather than pool or external caller IDs.
• Delegate certificates. If you legitimately control numbers you don’t own on Orbit — verified external caller IDs, hosted or bring-your-own numbers — register the ATIS-1000092 delegate certificate you obtained from your service provider. Active certificates raise those numbers from C to B. Revoke a certificate and its numbers fall back to their ownership-based level immediately.
• Attestation policy. Set your org’s target attestation level, how below-target downgrades are handled in reporting (monitor or alert), the inbound verification floor treated as verified, and whether unsigned inbound calls are flagged as spoof-risk.
• Branded calling (Rich Call Data). On A-attested calls, registered US carriers can render your verified brand name, logo, and reason-for-call on the recipient’s handset (ATIS-1000095). Orbit passes your brand assets to the softswitch, which matches them against your per-carrier registration. Carriers without RCD support fall back to plain attestation plus CNAM.
• CNAM pairing. Register the calling name carriers display alongside your number. CNAM and attestation work together: attestation proves the number, CNAM names it.

​

Limits to be aware of

• On-net vs. downstream. Devotel signs every outbound call on-net, at the level Orbit signals. What downstream carriers do with that signature — displaying “caller verified”, rendering RCD, or applying their own spam analytics — is outside Orbit’s control and varies by carrier and handset.
• A is ownership-only. No configuration raises a non-owned number to A. Delegate certificates cap at B by design.
• RCD is carrier-dependent. Branded calling renders only on carriers where your brand registration is complete; elsewhere the call still carries full attestation, just without the rich display.
• Inbound raw Identity is unverified. When only a raw Identity header is present, the level is the caller’s claim, not a cryptographically verified result — the pre-verified Verstat path covers the overwhelming majority of PSTN inbound.
• Certificates are not chain-validated. Registering a delegate certificate stores the authorization artifact you provisioned out-of-band; Orbit checks its status and validity window, not its cryptographic chain.

​

Responding to ITG traceback requests

# 1. Log the traceback request as soon as it arrives
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "traceback_ref": "ITG-2026-04117",
    "source_number": "+14155551234",
    "campaign_description": "Warranty robocall complaint against this originating number"
  }'

# 2. Acknowledge receipt to the ITG
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback/$CASE_ID/acknowledge" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

# 3. File your disposition and close the case
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback/$CASE_ID/respond" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "disposition": "number_disabled", "close": true }'

​

How the SLA verdict is computed

​

Your posture, Orbit’s ledger

​

Deep dives

• Voice channel overview — carrier-of-record architecture
• CNAM & caller ID — register and dispatch calling names
• Voice data residency & retention — where attested call data lives
• Attestation API — delegate certificates, attestation policy, and posture snapshots under Compliance endpoints
• ITG traceback workflow — the traceback case endpoints above, plus the full schema in the Compliance endpoints reference