# OpenAPI specification

> Machine-readable OpenAPI 3.1 specification for the 23 Telecom SMS API — generate typed clients, mock servers, contract tests and import into any API tooling.
> Source: https://docs.23telecom.co.uk/tools/openapi/

Instructions for LLMs: This is one page of the 23 Telecom messaging API docs
(SMS today; more channels planned). Base URL: https://restlink23telecom.com/api/v1,
auth via the X-API-Key header. Match errors on the error_code field, never on
description text. Full docs: https://docs.23telecom.co.uk/llms-full.txt · Schemas: https://docs.23telecom.co.uk/openapi.yaml

The entire public API is described in one OpenAPI 3.1 document — the same
source that powers the [API playground](/api) and the
[Postman collection](/tools/postman).

<p>
  <a class="sl-link-button primary" href="/openapi.yaml" download="23telecom-sms-api.yaml">
    Download openapi.yaml ↓
  </a>
</p>

Stable URL for tooling:

```
https://docs.23telecom.co.uk/openapi.yaml
```

## What you can do with it

**Generate a typed client** in your language:

```bash
# TypeScript (fetch-based)
npx openapi-typescript https://docs.23telecom.co.uk/openapi.yaml -o ./api-types.ts

# Any of 50+ languages via OpenAPI Generator
openapi-generator-cli generate \
  -i https://docs.23telecom.co.uk/openapi.yaml \
  -g python -o ./23telecom-python
```

**Mock the API** for local development:

```bash
npx @stoplight/prism-cli mock https://docs.23telecom.co.uk/openapi.yaml
```

**Contract-test your integration** — validate your requests and our responses
against the spec in CI (Schemathesis, Dredd, Spectral).

**Import into API clients** — Insomnia, Bruno, Hoppscotch and Postman all
accept OpenAPI 3.1 directly.

## Coverage

The spec describes all public endpoints (SMS, messages, statistics, account,
webhooks), the `X-API-Key` security scheme, every documented
[error shape](/reference/errors), and the **delivery webhook** as an OpenAPI
`webhooks` entry — so code generators can type your DLR receiver too.

## Versioning

The spec follows the live API. Breaking changes would ship as a new major
version with a migration period — additive changes (new fields, new
endpoints) land in place. Pin to fields you use, ignore unknown fields.