Tools & Integrations

Integrate the Turris Public API into your development workflow with the tools below.

MCP Server

The Turris Public API documentation is available as a Model Context Protocol (MCP) server. MCP connects AI tools directly to our documentation, so you get accurate, up-to-date answers about the API without leaving your editor.

Cursor

Install the MCP server in Cursor with one click

VS Code

Install the MCP server in VS Code with one click

Manual Setup

Add the following to your MCP client configuration:

{
  "mcpServers": {
    "turris-public-api": {
      "url": "https://docs.turrisfi.com/mcp"
    }
  }
}

Compatible with any MCP client including Claude Desktop, ChatGPT, Cursor, VS Code, Windsurf, and more.

Postman collection

Explore and test the Turris Public API in Postman without leaving this site. The collection is a file this documentation serves, so you import it from a URL rather than forking a workspace, and it is regenerated with every release alongside the reference pages. There are two ways in. Start with the curated collection; fall back to the full OpenAPI import when you need an endpoint the collection leaves out.

Import the curated collection

The collection lives at:

https://docs.turrisfi.com/postman/turris-public-api.postman_collection.json

Import the collection

In Postman, choose Import, paste the URL above into the link field, and confirm with Import. A collection named Turris Public API appears in your workspace.

Set your variables

Open the collection and go to its Variables tab. Set base-url to the environment you are targeting, then fill in client-id and client-secret with the credentials from Settings > API in the web app.

Environment	`base-url`
Sandbox	`https://public.api.sandbox.turrisfi.com`
Production	`https://public.api.live.turrisfi.com`

Credentials are environment-specific and are not portable between sandbox and production. See Environments for what else differs.

Get a token

Send Authentication API > Get OAuth Token once. The Authentication API folder sits at the top level of the collection, beside the version folders, because the token endpoints are shared by both versions. Its response script stores the token in turris-access-token, and every other request in the collection inherits it as bearer auth. You do not paste the token anywhere.

Send requests

Open the version folder you want to work in. Every request under it is ready to send. Optional query parameters are present but disabled, so a request is valid exactly as it arrives; enable the ones you want.

What is inside

One collection, Turris Public API, with four top-level folders:

Folder	Contents
Authentication API	OAuth and Restricted Access Token flows. Shared by both versions.
Health Check	Service heartbeat. Shared by both versions.
v1	The frozen carrier surface: 41 requests across 12 sub-folders, paths shaped `/v1/agents`. No persona segment.
v2	Two persona folders. `Upstream` holds 38 requests across 12 sub-folders, paths shaped `/v2/upstream/agents`. `Downstream` holds 39 requests across 12 sub-folders, paths shaped `/v2/downstream/producers`.

v1 and v2 > Upstream use the same 12 sub-folder names, so a carrier migrating from v1 finds each request in the same place on both. v2 > Downstream does not mirror them. Only Contacts, Licenses and Appointments share a name with a v1 sub-folder; the other nine (Licensed Entities, Producers, Licensing Overview, License Requests, Markets, Corporate Registrations, Compliance Configurations, Documents, Surplus Lines) exist on the agency surface only, and there is no v1 agency surface for them to mirror.

Your credential works in exactly one persona folder and returns 403 in the other. The collection says so in its own folder descriptions: Upstream warns that “an agency credential gets 403 on all of them”, and Downstream that “a carrier credential gets 403 on all of them”. If every request in a folder is refused, you are in the wrong folder rather than misconfigured. Read Which API is mine? to confirm which surface your credential is for and what that 403 looks like.

Choosing a version

Pick the version by picking the folder. Each one sets {{api-version}} for the requests inside it, so a request cannot reach the version you did not choose. You do not need to edit anything to switch. Tokens are interchangeable between versions of the same surface, not across surfaces. A carrier or MGA token works in both v1 and v2 > Upstream, so you can migrate endpoint by endpoint. An agency token works in v2 > Downstream only.

The collection covers the endpoints most integrations use, not the entire API. Each surface has its own complete reference: the Carrier & MGA reference covers /v2/upstream/* and v1, and the Agency reference covers /v2/downstream/*, which is v2 only. Every endpoint in either reference works whether or not it appears in the collection. To have all of them in Postman, import the OpenAPI document as described next. If you are not sure which reference applies to you, start at Which API is mine?.

Import the full OpenAPI document

The OpenAPI documents that render this reference are served from this site too, and Postman can import an OpenAPI 3 document from a URL:

https://docs.turrisfi.com/openapi/v2.json

For the frozen carrier v1 surface, use https://docs.turrisfi.com/openapi/v1.json instead. Choose Import, paste the link, and when Postman asks how to import it, pick Postman Collection. You get one request per operation, so every endpoint in the reference is present, including the ones the curated collection leaves out. What you do not get is the curated collection’s plumbing. The generated requests have no per-folder version scripts, no response script that stores the token, no bearer auth wired to a variable, and no disabled optional query parameters; every parameter arrives enabled with a placeholder value. You set the Authorization header or collection auth yourself, and you trim query strings request by request. That trade is worth it when you need an endpoint the curated collection does not include. For everything else, the curated collection is faster to use.

Keeping your collection in sync

Both the collection and the reference pages you are reading are generated from the same OpenAPI documents in the same release. The collection at that URL therefore always matches this reference: a request in the collection cannot describe a field the reference does not, and a change to the reference is a change to the collection in the same deploy. To pick up changes, import the same URL again. Postman recognises the collection you already have and the import dialog offers Replace. Choose it, then open the collection’s Variables tab and re-enter any value that came back empty. Those values are yours, not the file’s, so Replace is still the right choice over Import as a copy, which leaves you with two collections and no way to tell which one you configured. The Changelog announces every API change. When an entry lands that touches an endpoint you use, that is the cue to re-import. The changelog also publishes an RSS feed, so a feed reader can tell you without you checking. If you forked the collection from the retired public Postman workspace, that fork no longer receives updates. Import from the URL above once and use Replace from then on.

Start Here

API Conventions