> ## Documentation Index
> Fetch the complete documentation index at: https://staging.docs.flowsign.app/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Flowsign is one word with a lowercase s.
> The REST API base URL is https://my.flowsign.app and every endpoint lives under /api/v1.
> When answering API questions, cite the HTTP method and endpoint path.
> API access needs the Enterprise plan and an API key with the API access permission.

# API specification

> The OpenAPI document behind the endpoint pages, and what to do with it.

Every page under **Endpoints** is generated from one OpenAPI 3.0.3 document. The same file drives the code samples and the request and response schemas, so what you read there is what the API accepts.

## Fetching it

The document is published with these docs at [docs.flowsign.app/api-reference/openapi.json](https://docs.flowsign.app/api-reference/openapi.json). It needs no API key.

```bash theme={null}
curl -O https://docs.flowsign.app/api-reference/openapi.json
```

## What it contains

* **47 operations** across 32 paths, grouped by tag. Each carries a summary, a description of its rules and the permission it needs, and an `operationId` such as `getPackagesByPackageId`.
* **One security scheme**, `ApiKey`: HTTP bearer authentication with a token in the `fsk_*` format, applied to every operation. See [Authentication](/api-reference/authentication).
* **The `x-workspace-id` header**, declared on every operation as optional, with the rule that it may only repeat the key's own workspace id. See [Workspaces](/api-reference/workspaces).
* **The `Error` schema**: `{ error, details? }`, where `details` maps a field path to a list of messages. Every operation declares `401`, `402`, `403`, `422` and `429` with this schema, plus whichever of `400`, `404`, `409` and `413` apply to it. See [Errors and rate limits](/api-reference/errors).
* **Success responses** wrapped as `{ data }`: `201` for creates, `200` otherwise. The download endpoints declare a binary body instead.
* **`WebhookPayload_*` schemas**, one per webhook event, such as `WebhookPayload_PACKAGE_COMPLETED`. They describe the `data` object of each delivery so you can generate types for your listener. See [Events](/webhooks/events).

## Server

The document lists a single server, **Production** at `https://my.flowsign.app`. There is no sandbox: requests from a copied sample or a generated client go to your live workspace.

## Versioning

`info.version` is `1.0.0`. The specification is regenerated with every change, so the file you fetch matches the pages you read.

## Generating a client

The document works with standard OpenAPI tooling.

* **Generate a client** with a tool such as OpenAPI Generator, openapi-typescript or NSwag, pointing it at the URL above, then configure the client with your key as the bearer token.
* **Import into Postman or Insomnia** with their OpenAPI import and set the `ApiKey` bearer token once at collection level. Both read the server URL, parameters and example values from the file.

<Tip>
  The plain-text exports and MCP server on [Use with AI](/api-reference/use-with-ai) cover the whole docs site, endpoint pages included, for agents that read documentation rather than a specification.
</Tip>
