Skip to main content

API clients

Postman, Insomnia, Bruno, and Hoppscotch all import an OpenAPI spec from a URL and generate a request collection automatically. There's no curated download to keep in sync — point your client at the canonical spec URL and the generated collection always reflects the current v1 contract.

Spec URLs​

  • https://app.preview.trakrf.id/api/openapi.yaml
  • https://app.preview.trakrf.id/api/openapi.json

Either format works; pick whichever your client prefers.

Importing​

Postman​

  1. File → Import → Link.
  2. Paste the YAML or JSON URL above.
  3. Postman creates a collection named TrakRF API with one request per operation, organized by tag.
  4. Open the collection's Variables tab and set:
    • baseUrl to your environment host (https://app.trakrf.id for production, https://app.preview.trakrf.id for preview accounts). The bare host with no /api/v1 suffix — operation paths already include the version prefix. The API is served from the app. subdomain, not the marketing site.
    • bearerToken to your API key (the JWT shown once at creation). See Authentication → Mint your first API key for how to create one.
  5. The collection's Authorization is preconfigured as a Bearer token referencing {{bearerToken}}.

Insomnia​

Create → Import From → URL, then paste a spec URL. Insomnia generates a request collection. Configure environment variables for the host and bearer token the same way as Postman.

Bruno​

Collection → Import Collection → From OpenAPI Spec, then paste a spec URL. Bruno stores collections as files on disk; you can commit them alongside your own code if useful.

Hoppscotch​

Collections → Import/Export → Import from OpenAPI URL, then paste a spec URL. Hoppscotch runs in the browser; the imported collection persists in local storage.

TypeScript with openapi-fetch​

If your integration generates a TypeScript client from the same spec URL above instead of using a GUI client, the openapi-fetch runtime needs one extra step: it does not auto-send Content-Type: application/merge-patch+json on PATCH calls, despite the spec declaring this content type on every PATCH operation. A literal translation of the spec into client.PATCH(...) returns 415 unsupported_media_type on the first call.

The fix is a mergePatchMiddleware registered once on the client so every PATCH site is handled automatically. The full snippet (≈30 lines, plus an optional createTrakrfClient wrapper) lives in Quickstart §5 — TypeScript with openapi-fetch — copy it into your project rather than overriding Content-Type per call.

The openapi-generator-cli typescript-fetch target and the Python openapi-generator handle merge-patch correctly out of the box; this workaround is specific to the openapi-fetch runtime path.

Refreshing​

The spec moves with each platform deploy. Re-import (or use your client's "sync from spec URL" option when available) to pick up the latest operations.