← All platforms

API Report Card · Phone · Methodology v1.1

Dialpad

Name: Dialpad API Report Card
Item: Dialpad
Rating: 77
Author: Peter Lohmann

Preliminary grade

C+ 77/100

38.50 / 50 raw

Evidence tier

Baseline verified

Date run

Oct 11, 2026

Evaluating model

Claude Opus 4.8

Verification coverage

100%

Live-test battery

Complete

Checks

27 of 27 scored

NOTE: This grade is produced by an AI analysis run against the same published grading file, which you can download and check here. The scope is deliberately narrow: API and data access. It is not Peter Lohmann's opinion of Dialpad as a software platform, and it says nothing about Dialpad's features, reliability, interface, support, or standing in the industry.

Where the points came from.

Five categories, each worth a fixed share of the 100 points. A category earns the fraction of its checks it passes, times its maximum.

Category 1

Letter grades are absolute, never curved.

The same numeric bands apply to every platform. Nothing here is scored relative to the rest of the board.

A+97-100

A93-96

A−90-92

B+87-89

B83-86

B−80-82

C+77-79

C73-76

C−70-72

D+67-69

D63-66

D−60-62

Fbelow 60

What this means for you.

One paragraph per category, in plain language.

1 · Functional Coverage

15 / 15 points

Dialpad's API exposes essentially the whole communications platform. You can read users and calls, send texts, place, transfer and end calls, provision and assign phone numbers, manage call routing, and subscribe to real-time events for calls, texts, contacts and agent status. For automations and AI agents built around phone and text workflows, the surface is broad and mature. The one gap: inbound texts arrive through event webhooks, because there is no message-history endpoint to read them back.

See technical details

2 · Design & Reliability

5 / 10 points

The API is a clean, predictable REST interface, errors come back structured with a machine-readable reason, and uptime is public on a status page with its own API component. The weak spots are the reliability guarantees. There are no idempotency keys, so retrying a failed send can text someone twice. There is no concurrency control, so the last write wins. There is no documented rate-limit contract, with no 429, no Retry-After and no limit headers. And webhooks are signed but come with no documented retry or ordering promise. Plan to build your own dedup, backoff and webhook reconciliation.

See technical details

3 · Access Control

3.5 / 5 points

You can issue multiple named keys, scope them somewhat, set them to expire or revoke them yourself, and test in a separate sandbox with its own credentials. What you cannot do is mint a read-only key, so handing a limited key to an AI agent or a third party carries more risk than it should. A dedicated, narrowly scoped OAuth app and close monitoring are the workaround.

See technical details

4 · Docs & AI-Ready

3.8 / 5 points

An AI coding tool can work with this API well: there is an OpenAPI file, a maintained official Python SDK, a first-party MCP server, an llms.txt index, and a Markdown version of every reference page. The reference has no copy-and-paste request examples, it documents none of the error responses your code will actually hit, and the public changelog has not been updated since July 2025.

See technical details

5 · Access & Cost

11.3 / 15 points

Once you are on a plan that includes the API, getting a key is instant and self-serve: a company admin creates it in the product, with no sales call. The catch is the plan. API access is not on the cheapest tier, and Dialpad's own pages disagree on exactly which tier includes it, so confirm yours does before you build.

See technical details

Every check, and why it scored that way.

The same 27 checks are applied to every platform. What changes is which are N-A and what the core objects mean for that kind of software. Each mark below is quoted from the run's own report. Marks are AI-generated and cover API access only.

Category 1 · Functional Coverage

15 / 15

C1.1

Object coverage

weighted coverage ≈ 91% (21.0/23), no critical object absent. Users/Calls/Contacts/CC/offices/webhooks/recordings/rooms/stats = 1.0; Messages = 0.5 (REST send-only, history via events); Fax/settings = 0.5. [OAS path list; packet C1]

Yes

C1.2

Core operational actions

weighted ≈ 100%; create/update present for every critical write workflow: POST /sms, POST /call, POST+PATCH /users, POST /numbers/assign, plus broad POST/PATCH across resources (OAS: 56 POST / 24 PATCH). (documentation/OAS-graded — writes not executed live) [OAS; packet C1]

Yes

C1.3

Delete or lifecycle actions

weighted ≈ 100%; all principal lifecycle actions present (26 DELETE ops + status/transfer/hangup/assign/unassign). (documentation/OAS-graded) [OAS; packet C1]

Yes

C1.4

Change notification

event subscriptions cover call / sms / contact / agent_status + a changelog catch-all, with rich call-event states; ≥ 0.85 weighted of critical+important state changes. [event-subscriptions.md; call-events.md]

Yes

Category 2 · Design & Reliability

5 / 10

C2.1

Modern conventions

REST, resource-oriented, standard verbs, JSON, /api/v2. [OAS; reference pages; live 200]

Yes

C2.2

Consistent typing

schemas typed, but core id fields are inconsistent: live id returns as a string while the OAS types several IDs int64, and ID typing varies across objects (ContactProto.id string vs ActiveCallProto.id int64). [smssend.md; webhookscreate.md; OAS parse; live step 2]

Partial

C2.3

Structured errors

live 404/401 return a structured body with error.code, human-readable error.message, and machine-readable error.errors[].reason (notFound/required), correct HTTP status, consistent across cases. (Observed behavior; note: the docs document no errors — this does not rescue C4.1.) [live step 4]

Yes

C2.4

Duplicate prevention

no idempotency keys/headers anywhere (OAS: 0); POST /sms and POST /call (consequential writes) can duplicate on retry; only contacts PUT is naturally idempotent. (documentation-graded) [OAS parse; packet C2.4]

C2.5

Graceful handling under load

numeric limits are published, but there is no documented 429, no Retry-After, no backoff guidance, and live responses carry no X-RateLimit-* headers. [rate-limits.md; live step 5]

C2.6

Pagination

cursor pagination works (traversal verified live, page 1→2), but no documented stable-ordering guarantee, no total-count, and a ≤100 cap. [getting-started.md; OAS; live steps 2–3]

Partial

C2.7

Bulk or incremental export

async CSV export exists (Stats API) but covers only call records/stats; no updated-since/delta sync; other objects via cursor lists only. [stats-api-dialpad-analytics.md]

Partial

C2.8

Webhook security and delivery reliability

JWT HS256 signed payloads (shared secret), but no documented retry policy, no replay/dedup guidance, and events may arrive out of order. (documentation-graded) [event-subscriptions.md; webhookscreate.md; call-events.md]

Partial

C2.9

Concurrency and conflict control

no ETag/If-Match/version fields and no 409 semantics (OAS: 0); last-write-wins. [OAS parse; usersupdate.md]

C2.10

Versioning and backward compatibility

explicit /api/v2 path version + per-endpoint "added on" notes and a v1 archive, but no formal backward-compatibility policy or defined deprecation window. [packet C2.10]

Partial

C2.11

Request traceability

every response carries a unique x-cloud-trace-context identifier, but it is undocumented by Dialpad and not referenced in the support flow (which asks for the key's last 4). [live step 1/5; getting-help.md]

Partial

C2.12

Service availability and status transparency

public Statuspage with a dedicated "API Platform" component, incident history, and published uptime (e.g., Calling 99.999%/30d). No SLA, but uptime present. [status.dialpad.com]

Yes

Category 3 · Access Control

3.5 / 5

C3.1

Read-only credentials

no read-only credential mode; scopes are action/export-oriented and endpoint access is gated by a user/admin role flag, not a read-only grant; admin keys act across all users. [oauth.md; api-key-generation.md]

C3.2

Scoped credentials

per-key/token scope selection (Dialpad-approved) + Access Control Policies, but ACPs bind to users, not API credentials, their permission sets are write-only and AI-contact-center-scoped, and OAuth has an undefined basic-access floor. [api-key-generation.md; access-control-policies.md; accesscontrolpoliciesassign.md]

Partial

C3.3

Multiple keys

multiple named API keys in the admin "API Keys" list. [api-key-generation.md; Help Center]

Yes

C3.4

Rotation and revocation

self-serve key expiration set at creation + OAuth POST /oauth2/deauthorize revocation. [api-key-generation.md; oauth.md]

Yes

C3.5

Test and production isolation

separate sandbox host and credentials (sandbox.dialpad.com vs dialpad.com), confirmed in OAS servers. [authentication-basics.md; OAS]

Yes

Category 4 · Docs & AI-Ready

3.8 / 5

C4.1

Complete self-serve reference

~200 public reference pages with typed params + 200-response examples + schemas, but no request/code samples and no documented error responses (confirmed: live errors exist but are undocumented). [userslist.md; live step 4]

Partial

C4.2

Reliable machine-consumable path

OpenAPI 3.x spec (Dialpad GitHub, auto-generated from live OAS) + actively maintained official Python SDK (python-dialpad, updated 2026-03-31) + a first-party MCP server. [github.com/dialpad/dialpad-python-sdk; dialpad.com/mcp]

Yes

C4.3

AI-readable documentation

comprehensive llms.txt index + clean per-endpoint Markdown (.md twin on every page). [llms.txt; packet C4.3]

Yes

C4.4

Kept current

on-site changelog is ~15 months stale (latest July 2025) and irregular, though the SDK/OAS pipeline is current and endpoints carry version-added notes; no formal deprecation policy. [developers.dialpad.com/changelog]

Partial

Category 5 · Access & Cost

11.3 / 15

C5.1

Self-serve API key

a company admin creates keys in-product (name, expiration, scopes) with no sales call or approval for key creation itself. [api-key-generation.md]

Yes

C5.3

Not commercially gated

API access is tier-gated with inconsistent first-party sources: FAQ ("Enterprise plans include Admin and Reporting APIs"), help docs (reportedly Pro+), dev docs (silent), pricing page (no mention of API). Not on the entry Standard tier. The operator's own key authenticated live, confirming API access is enabled on his plan (tier not disclosed). [dialpad.com/faq; dialpad.com/pricing; live step 1]

Partial

What works

Near-complete coverage of calls, texts, users, phone numbers, routing and contacts
Place, transfer and end calls and send texts straight from the API
Real-time event subscriptions for calls, texts, contacts and agent status
Structured errors with a machine-readable reason, confirmed live
A separate sandbox with its own credentials
Multiple named keys with expiry dates, and self-serve revocation
An OpenAPI file, a maintained Python SDK and a first-party MCP server
An llms.txt index and a Markdown version of every reference page
A public status page with a dedicated API component and published uptime
Self-serve keys created by your own admin, with no sales call

What to watch

No idempotency keys, so a retried text or call can go out twice
No concurrency control: the last write wins
No documented 429 or Retry-After, and no rate-limit headers on live responses
Webhooks are signed but have no documented retry or ordering guarantees
No read-only key, so every credential can act, not just look
Inbound texts come only through webhooks; there is no message-history endpoint
No changed-since sync; the bulk export covers call records only
Error responses work at runtime but are not documented anywhere
The public changelog has not been updated since July 2025
API access is not on the cheapest plan, and Dialpad's pages disagree on which tier includes it
Writes were graded from documentation, not tested live

Check it yourself.

Both files behind this page, in full.

NOTE: Grades are AI-generated from the published grading file, and cover API access only.

Dialpad’s full report

The complete markdown report this page is built from, including the evidence packet, the run metadata and every check in full.

Download the Dialpad report

The grading file

The exact rubric behind every score on this page. Same file, every platform. Run it yourself and compare.

Download the methodology

Found a factual error in your grade?

Tell us and we will fix it. Every mark on this page traces to a specific piece of first-party evidence or a live API call, and the full report is published so you can see exactly what was checked and what it was checked against.

Confirmed factual errors are corrected immediately.

Everything else waits. We do not rescore piecemeal on request, because a board where some vendors have been re-run and others have not is not a fair comparison. Shipped improvements, changed documentation and disagreements about judgement all go into the next full rerun.