Realtime

APIs 26

Each API is captured as its own OpenAPI definition — every operation, parameter, and response. This is the single most useful machine-readable description of what an API does, and it's what lets us score, lint, mock, and generate against it without asking the provider for anything.

Individual APIs this provider publishes, each with its own machine-readable definition.

Scroll within the panel for all 26 ·

GraphQL 1

Where a provider ships GraphQL, the schema is the contract. We profile it alongside the REST surface so the whole interface is legible in one place.

GraphQL schemas published by this provider.

Semantic Vocabularies 1

JSON-LD contexts give the data shared meaning across APIs. We profile them because semantics are what let a machine reconcile 'customer' here with 'customer' somewhere else.

JSON-LD contexts and semantic vocabularies used across these APIs.

Spectral Rules 1

Governance rulesets we run against this provider's specs — the automated checks behind parts of the score. Profiling them makes the quality bar explicit and re-runnable, not a matter of opinion.

JSON Schema 4

Standalone JSON Schema definitions describe the data models behind the API. We profile them so the shapes are validatable on their own — useful long after a single request is forgotten.

Standalone JSON Schema definitions for this provider's data models.

Examples 9

Real request and response payloads are what turn a spec from abstract into obvious — and they're one of the twelve things an agent needs to call an API correctly on the first try.

Example request and response payloads for these APIs.

Scroll within the panel for all 9 ·

Security Posture 1

Authentication, domain security, vulnerability disclosure, and trust-center signals — the evidence that a provider takes security seriously enough to document it. We profile it because you can't govern what you can't see.

Authentication, domain security, vulnerability disclosure, and trust-center signals.