How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Need help?

Contact us
Superdial

SuperDial API

Asynchronous REST API for submitting structured data extraction requests against insurance payers and retrieving the results. Submit a request (single or batch) against an account-provisioned schema, discover the inputs a schema requires, resolve payer names to dialing numbers, and read results by ID or by batch. Terminal results are delivered by an HMAC-SHA256-signed webhook. Auth is a short-lived bearer token exchanged for an API key/secret pair.

Documentation Provider Profile APIs.io OpenAPI GitHub

This API exposes 7 operations across 6 paths, organized into 3 resource areas, and defines 17 schemas. It is described by OpenAPI 3.0.0, at version 1.0.0.

Requests are made against a single base URL, https://robodialer-service-api-9nc4t1p9.uc.gateway.dev.

7 operations 6 paths 17 schemas 5 GET2 POST

Metadata

The identity and technical contract details declared by the specification.

Specification
OpenAPI 3.0.0
API Version
1.0.0
Base URL
https://robodialer-service-api-9nc4t1p9.uc.gateway.dev
Authentication
API Key, API Key, HTTP Bearer
Resource Areas
3

Authentication & Security 3

SuperDial API declares 3 security schemes for authenticating requests. An API key is passed in the header as Robodialer-API-Key (apiKey). An API key is passed in the header as Robodialer-API-Secret (apiSecret). It accepts HTTP bearer tokens (bearerAuth).

  • apiKey — Your SuperDial API key
  • apiSecret — Your SuperDial API secret
  • bearerAuth — Bearer token obtained from the /v1/auth endpoint

Paths & Operations 7

Across 6 paths, the API surfaces 7 operations — 5 GET, 2 POST. They span 3 resource areas: Authentication, Schemas, Requests. Each is listed below with its method, path, parameters, and response codes.

Authentication 1

SuperDial employs Bearer Authentication. Fetch a bearer token using your API Key and API Secret, then pass it as Authorization: Bearer on subsequent calls.

GET
/v1/auth
Authenticate and get token
→ 200401
Schemas 3

Discover the schemas provisioned for your account and the required input keys for each. All non-2xx responses use the uniform {error, message, [details]} envelope (see the ApiErro…

GET
/v1/schemas
List schemas
→ 200401404500
GET
/v1/schemas/{schemaId}/required-inputs
Required inputs for a schema
1 param → 200400401404500
POST
/v1/schemas/{schemaId}/required-payer-inputs
Resolve payer names against a schema's required inputs
1 param body → 200400401403404500
Requests 3

Endpoints for creating and reading requests (structured data extraction jobs). All non-2xx responses use the uniform {error, message, [details]} envelope (see the ApiError schema).

POST
/v1/requests
Create a Request
body → 200207400401404500
GET
/v1/requests
List Requests
3 params → 200401400404500
GET
/v1/requests/{requestId}
Retrieve a Request
1 param → 200404500401

Schemas 17

The contract defines 17 schemas that model the data the API accepts and returns. The most detailed are RequestResponse (28 properties), CreateRequestPayload (9 properties), PayerLookup (6 properties), RequiredPayerInputsResponse (4 properties). Each schema is shown below with its type and property counts.

ApiError
object
Uniform error envelope returned by every non-2xx response from /v1/requests and /v1/schemas. The error field is a stable machine-readable code; the message fie…
3 properties 2 required
SchemaSummary
object
One row in the GET /v1/schemas response.
3 properties 3 required
ListSchemasResponse
object
Success response from GET /v1/schemas.
1 property 1 required
RequiredInputsResponse
object
Success response from GET /v1/schemas/{schemaId}/required-inputs. Carries both required and optional input field lists; the two are disjoint: if a name is requ…
3 properties 3 required
RequiredPayerInputsRequest
object
Request body for POST /v1/schemas/{schemaId}/required-payer-inputs.
1 property 1 required
RequiredPayerInputsResponse
object
Success body from POST /v1/schemas/{schemaId}/required-payer-inputs. Carries the schema's own requiredInputs/optionalInputs (identical shape and semantics to G…
4 properties 4 required
MatchedPayerEntry
object
A payers[] entry for a name that resolved to a canonical payer. The resolved phone number is intentionally omitted: dialing happens server-side and is never ec…
3 properties 3 required
PayerInputError
object
A payers[] entry for a name that could not be resolved. This is an inline, per-payer error: it does not fail the whole request. Distinguished from MatchedPayer…
3 properties 3 required
AuthTokenResponse
object
Response from GET /v1/auth. Contains a short-lived bearer token usable as Authorization: Bearer on subsequent calls.
1 property 1 required
GatewayErrorResponse
object
Error envelope returned by the API Gateway for auth failures and routing errors. Distinct from the service's own ApiError envelope: gateway responses use {code…
2 properties 2 required
SimpleErrorResponse
object
Standard error envelope. The error field is a human-readable message describing what went wrong; per-endpoint examples are listed under each response.
1 property 1 required
CreateRequestPayload
object
9 properties 2 required
CreateRequestBatchPayload
object
1 property 1 required
PayerLookup
object
Payer/phone lookup outcome, returned on POST /v1/requests success responses and on the GET /v1/requests read endpoints. Always present on a created request whe…
6 properties 6 required
CreateRequestSuccess
object
Success response from POST /v1/requests on a single-item POST. internalId is echoed only when supplied in the body. payerLookup is present on every created req…
4 properties 2 required
CreateRequestBatchResponse
object
Response from POST /v1/requests on a batch POST. Each entry in requests is positionally aligned with the input and is either a CreateRequestSuccess payload or…
1 property 1 required
RequestResponse
object
28 properties

Specification

The full machine-readable OpenAPI contract behind this narrative.

Source

superdial-api-openapi.yml Raw ↑
#Requests#Schemas#Authentication#Webhook
← Back to S APIs
API Details
ID
superdial:superdial-api
Base URL
https://robodialer-service-api-9nc4t1p9.uc.gateway.dev
Docs
https://docs.superdial.com/introduction
Provider
Superdial
APIs.io →  GitHub →
Explore more
All APIs Providers APIs.io Network
Work with this as data

Every API here is available over the API and to AI agents over MCP. APIs is not yet its own endpoint on the v1 API. Reach this content through network search and the tag graph, or the MCP server below.

Installs https://mcp.apievangelist.com/mcp in Claude, Cursor, VS Code and the rest — one button, every client.

MCP tools for apis
4 tools reach this content
  • search_api_evangelistSearch every content type across the network at once.
  • find_relatedThe shared-tag relevance graph — what else covers this.
  • get_tagEverything one tag labels, across all content types.
  • guide_topicPRO — a curated bundle for a topic: area, guidance, rules, papers, stories, services.
All tools & prompts
Call it yourself
curl for this page
Search the network for this 
curl "https://api.apievangelist.com/v1/search?q=superdial-superdial-api&limit=10"
Everything under a tag 
curl "https://api.apievangelist.com/v1/tags/superdial-superdial-api"

Discovery needs no key. Full bodies and the synthesis endpoints are Pro.

Get an API key

Free tier, no email required. Sign in with whichever identity you already have.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have. Your account

Where this information came from

This is an independent, third-party profile of SuperDial API, published by API Evangelist. We do not operate, host, resell, or support these APIs, and we are not affiliated with or endorsed by the company unless stated above. Everything here is built from publicly available information — the company's own site, developer portal, documentation, public repositories, and the specifications it publishes for public use. Nothing is obtained by breaching a system, defeating an access control, or using credentials.

The Kin Score and Agent Readiness rating are independently calculated assessments of a company's public API artifacts, scored against a published rubric. They are not certifications, endorsements, security assessments, or audits.

Corrections, re-scores, and removal are free — no partnership or purchase required, and you do not need to justify the request. A removed company is recorded as unrated, never scored zero for having asked. Acknowledgement within one business day; removal within two.

info@apievangelist.com · Read the full data-sourcing policy →
On a security or compliance team? Put security in the subject line and you will get a person, not a form — we will tell you exactly which public URLs this profile was built from.