OpenAPI, Postman, and API reference

Overview

• Settings → Developer / API links to the public API Reference and downloadable OpenAPI YAML, Postman Collection, and Postman Environment.
• These assets are generated around routes classified as public-ready rather than exposing every internal /api/v1 route.
• The API reference documents authentication, scopes, idempotency, rate limits, Problem Details errors, API groups, and example endpoints.
• OpenAPI/Postman mark retry-sensitive endpoints and are the preferred machine-readable source for client generation/testing.

When to use this

• Start with Postman for manual integration testing and OpenAPI for generated clients, validation, or API tooling.

Step-by-step

1. Create an API key.
2. Download the latest OpenAPI/Postman files from MiniTill.
3. Put the key into a secure local Postman/environment secret rather than committing it.
4. Test a read-only endpoint first.
5. Add required scopes/idempotency as mutations are introduced.
6. Refresh downloaded specs when MiniTill adds supported public routes.

Common mistakes

• Do not rely on an old locally saved API spec forever.
• Do not publish a Postman environment containing a live MiniTill API key.
• Do not infer that an internal route missing from OpenAPI should be called manually.

Troubleshooting

• If a request copied from old docs conflicts with the current spec, use the current MiniTill API Reference/OpenAPI as the contract.
• If a generated client cannot represent a workflow, check whether that workflow is intentionally internal/native rather than public API.