OpenAPI spec

The full machine-readable definition lives at:

https://post-mate.com/v1/openapi.json

It's OpenAPI 3.1, regenerated on every deploy from the same Zod schemas the API itself uses for input validation — so the spec can never drift from runtime behaviour.

What you can do with it

• Generate a typed client SDK for any language (TypeScript, Python, Go, Ruby, etc.) using openapi-generator-cli, openapi-typescript, or swagger-codegen.
• Lint your requests before sending them, using tools like Spectral or Stoplight.
• Import into Postman / Insomnia to get an interactive request builder.
• Generate mock servers with prism or similar tools for local development.

Example: TypeScript SDK in 30 seconds

npx openapi-typescript https://post-mate.com/v1/openapi.json -o post-mate.d.ts

That gives you a fully-typed paths interface you can use with any HTTP client:

import type { paths } from './post-mate';

type CreatePostBody = paths['/posts']['post']['requestBody']['content']['application/json'];
type Post = paths['/posts']['post']['responses']['201']['content']['application/json'];

async function schedulePost(body: CreatePostBody): Promise<Post> {
  const res = await fetch('https://post-mate.com/v1/posts', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.POST_MATE_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(body),
  });
  return res.json();
}

Versioning

The current spec is v1. We commit to additive-only changes — new endpoints, optional fields, additional response keys — without bumping the version. Breaking changes (renames, type changes, field removals) get a v2 and a 6-month deprecation runway on v1.

If a breaking change is necessary, we surface it as a banner in the dashboard and in the Sunset HTTP header on v1 responses.