--- title: "Changelog" description: "Every change to the Flowie Exchange API, newest first. Additive, deprecation, and breaking changes are all tracked here." canonical: "https://docs.get-flowie.com/changelog" source: "https://docs.get-flowie.com/changelog.html" --- # Changelog Changelog # What's new Every change to the Flowie Exchange API, newest first. Additive changes land continuously under `/v1/`; deprecations are announced six months in advance and flagged with a `Sunset` response header. How to read this New additive — always safe to adopt. Changed behavior refined — read carefully. Deprec sunset date announced. Break only ever in a new major (`/v2/…`). Fix bug fix. ## v3.46.3 — AFNOR SIREN search answers from the PPF directory 2026-11-03 Fix **`POST /afnor/directory-service/v1/siren/search` and `GET /afnor/directory-service/v1/siren/code-insee:{siren}` now read the PPF directory, like every other AFNOR directory route.** They used to query the Peppol Directory. A name search therefore returned Peppol participants that the French directory does not hold, often with an empty `siren`, and could miss legal units the directory does hold. A `siren` filter now returns that legal unit. A `businessName` filter returns the directory's own name-index matches: a case-insensitive substring, without accents, at most 25 rows. `entityType` and `administrativeStatus` come from the directory (`Public` for public bodies, `C` for a ceased unit). A SIREN absent from the directory answers `404` even when Peppol knows it. When the directory itself cannot answer, both routes return `503` (unreachable) or `502` (it answered with an error), never a `404` or an empty page, so a company is never reported absent because of an outage. The Peppol extension fields (`peppolId`, `city`, `postalCode`) are still filled when available. `POST /afnor/directory-service/v1/siret/search` by name now returns the right 9-digit `siren`; it used to keep the VAT check digits. In the sandbox these routes read the PPF test directory, as the other directory routes already do. ## v3.46.2 — A refusal already recorded can still send its lifecycle message, once 2026-10-30 Fix **`POST /v1/documents/{documentId}/lifecycle` with `rejected` or `failed` now builds the French lifecycle message (CDAR 210 Refusée / 213 Rejetée) when your party already holds that status.** A status set by another route first, a flow for example, used to make the call answer `400` “Transition from 'rejected' to 'rejected' is not allowed”, and no message was ever built. The call is now a re-assert. Nothing is written, no `lifecycle.updated` event is emitted, and the report is dispatched with `compliance.FR.reasserted: true`. It is sent once. If one was already transmitted or is in flight, the response carries `compliance.FR.status: "already_reported"` and its `reportId`. A report that was built but never sent, or a dispatch abandoned for more than 15 minutes, does not count. If the report history cannot be read, the call answers `503` rather than risk a second message. A same-status call on any other status still answers `400`. ## v3.46.1 — Documents sent through the API no longer read as a manual upload 2026-10-29 Fix **A document sent through the API (`POST /v1/documents/send`, a batch send, or an AFNOR `POST /v1/flows` deposit) is now recorded as arriving through the API.** Before this fix, the Flowie app showed it as “Created by … via a manual upload”, the same as a file a person had dropped in by hand. Documents sent from now on carry the API channel. Documents already sent keep their current label. ## v3.46.0 — Check whether a participant can receive a UBL invoice on Peppol 2026-10-26 New **`GET /v1/directory/peppol/{participantId}/capabilities` tells you, before you send, whether an address can receive a UBL invoice or credit note on Peppol.** It is answered from the network itself: the OpenPeppol SML names the participant's SMP, and the SMP lists the document types it accepts. The Peppol Directory cannot answer this, because a participant can be absent from it and still be reachable. The response carries `registered`, `acceptsInvoice`, `acceptsCreditNote`, every listed `documentTypes` identifier and the `smpUrl`. `registered: false` is authoritative: the SML has no record, so no access point can deliver to that address. `null` means the network could not be asked, so never block a send on it. Pass the participant as `scheme:value`, for example `0225:552081317` or `0225:552081317_SUFFIX`. A malformed identifier answers `400` without any lookup, and answers are cached for 15 minutes. See [Peppol capabilities](). ## v3.45.0 — The two MCP servers name each other, and volume goes to the Exchange API 2026-10-26 Changed **Each MCP server’s`instructions` now names the other and says which to use for what.** This server (`/exchange/mcp`) presents itself as the high-volume route — an API key’s budget of 120 to 2,400 requests a minute by plan, `send_documents_batch`, and creating a document as one `send_document` call — and points in-app work (approvals, flows, tasks, budgets, reports) at the app server. The app server (`/agent-hub/mcp`) presents itself as an assistant working at a person’s pace and points volume here. See [Which server to use](). Changed **The app MCP server (`/agent-hub/mcp`) allows 60 requests a minute per user**, one object per call; it was 600. Over it, the `429` (with `Retry-After` and the `RateLimit-*` headers) names the Exchange API and this MCP server as the route for higher volume, with the links in `error.data.higherVolume`. The Exchange API’s own limits are unchanged. Fix **Creating a document from the app MCP server works.** `create_transaction_document` sent fields the platform does not have (`documentNumber`, `dueAt`, `buyerId`) and left out what it requires, so no call could succeed. It now takes the type, the number, the issue date, the other party (`buyerId` when you sell, `sellerId` when you buy) and the lines (`quantity`, `unitPrice`, `taxRate` as a percentage), computes every amount, accepts `idempotency_key`, and still reads the old argument names. ## v3.44.7 — Search sorts on the key you asked for, and documents `totalAmountInclTax` 2026-10-26 Fix **`POST /v1/documents/search` now sorts on the first key of `sort`.** Results are sorted on one key. A `sort` with several keys, a direction in capitals (`"DESC"`) or stray spaces used to be ignored without an error, and the results came back by `createdAt` descending. Now the first key applies, case and spaces are normalised, and a field with no direction sorts ascending. The reference lists the sortable fields. Changed **The total including VAT (BT-112) is documented as`totalAmountInclTax` in search filters and sorts.** `totalAmountDue` keeps working as a synonym, so existing requests are unaffected. A filter that uses both names keeps both conditions. ## v3.44.6 — A prepaid UBL invoice reports its total including VAT 2026-10-22 Fix **`grossAmount` is the total including VAT (BT-112) for a UBL invoice that states a prepayment.** A document sent with `format=ubl-xml` stored its amount due for payment (BT-115, `PayableAmount`) as its total including VAT, so `GET /v1/documents/{documentId}` and the document list showed the amount left to pay as `grossAmount`. The two are now stored apart. `balanceDue` on `GET /v1/payments/documents/{documentId}`, and the move to `paid` after a recorded payment, are measured against the amount due for payment when the document states one, otherwise against the total including VAT. An amount due for payment of zero, a fully prepaid invoice, counts as stated: `balanceDue` starts at `0.00` rather than `null`. Field names are unchanged; documents already stored keep their amounts. ## v3.44.5 — Two identical sends at once: the second waits for the first 2026-10-22 Fix **An identical send that arrives while the first is still being processed now gets the document, not an opaque`409`.** On `POST /v1/documents/send` and the AFNOR deposit `POST /afnor/flow-service/v1/flows`, the Exchange API waits and retries while the request can still finish within about 20 seconds, then answers like any resend: `200` with `Idempotent-Replayed: true`, or `201` if the first attempt had failed. If the first send is still running, the answer is `409` `IDEMPOTENCY_IN_PROGRESS` with a `Retry-After` header and `{"detail": {"code", "message", "retryAfter"}}` (`errorCode` on the AFNOR facade, which now passes `Retry-After` through). `POST /v1/documents/send/batch` does not wait: such an item fails at once with the same error under `results[i].error.detail`. Nothing was done for that request: resend it unchanged after the delay. A `409` for a duplicate document is unchanged. A resend that transaction-documents answers with the existing document is no longer counted as a second sent document and no longer re-links its files and metadata, and a replayed AFNOR deposit, whether served from the idempotency cache or not, no longer emits a second lifecycle message (CDV). See [409 · Conflict](). ## v3.44.4 — Consent screen: use another account, and a notice for accounts with no organization 2026-10-22 New **“Not you? Use another account” on the consent screen.** It forgets the consent session and sends you back to Flowie sign-in with the account picker (`prompt=login`), for the same consent request. Before, the screen named the signed-in account with no way to change it. Changed **An account that belongs to no organization is told so before it approves.** The screen says to create an organization in the Flowie app or ask to be invited, instead of granting access that cannot read or do anything. New **`/.well-known/openai-apps-challenge`** serves the domain-verification token the ChatGPT apps directory issues for a submitted MCP server (`404` until one is configured). Fix **A logged`POST` no longer drops all but one `Set-Cookie` header.** The request logger rebuilt the response from a header dictionary, which keeps only one of several cookies. ## v3.44.3 — Every MCP tool has a title 2026-10-20 New **Each tool on`/exchange/mcp` now carries a `title`**, at the top level and in its `annotations`: the operation’s summary from the [API reference]() (for example _Create (or find-and-link) a company from a VAT number_). Assistants show it instead of the raw tool name, and connector directories expect it. Tool names, arguments and the existing `readOnlyHint` / `destructiveHint` / `idempotentHint` / `openWorldHint` values are unchanged. The Flowie MCP servers are also listed on the official MCP Registry as `com.get-flowie/exchange`, `com.get-flowie/app`, `com.get-flowie/docs` and `com.get-flowie/website`. ## v3.44.2 — One copy-ready page to connect an AI assistant over MCP 2026-10-19 Docs **New page:[`/mcp.md`]().** Copy it whole into an assistant and it has a working configuration: which server to pick (the App server, `/agent-hub/mcp`, for a person using Flowie through Claude, ChatGPT or Cursor; the API server, `/exchange/mcp`, for integrations), ready-to-paste setups for Claude Code, Claude.ai / Claude Desktop, ChatGPT, Cursor and VS Code on production then staging, how sign-in works, the API-key option, rate limits and troubleshooting. `llms.txt`, [Build with AI]() and the agent plugin page lead with it. Docs **`auth.md` no longer says OAuth sign-in, SSO or dynamic client registration are unavailable to MCP clients.** It said dynamic registration was disabled, gave no production MCP URL and pointed at the identity provider instead of Flowie’s authorization server. It now documents what the servers do: a `401` naming the protected-resource metadata, `authorization_servers: ["https:///exchange"]`, dynamic client registration at `/exchange/v1/oauth/register` (public client, PKCE `S256`), the normal Flowie sign-in with SSO and Google, and a 24 h token renewed with a refresh token. The site’s protected-resource documents and MCP server card say the same, and list both production servers. ## v3.44.1 — Signing in to connect an MCP client no longer fails at random 2026-10-19 Fix **The OAuth consent flow works whichever server answers each step.** A connection (Claude, Claude Code, VS Code, Cursor…) could fail after you signed in with `{"detail":"Consent request not found or expired."}`, leaving the client without a token: every call to `/agent-hub/mcp` or `/exchange/mcp` then answered `401`. The consent request, the authorization code and handoff tokens were kept by the one server that created them, and the next step could reach another. They are now shared, encrypted at rest, and an authorization code or a handoff token still works exactly once. Nothing changes for clients; reconnect if a connection failed this way. ## v3.44.0 — Linear webhooks arrive through the Exchange API 2026-10-18 New **`POST /exchange/v1/integrations/linear/webhook` receives Linear’s webhooks** for organizations that connected Linear to their Flowie tasks (staging). It is public like the PunchOut callbacks: Linear cannot hold a Flowie key, so trust comes from Linear’s own `Linear-Signature`, which the Flowie integration bridge verifies. The body and the Linear headers are forwarded unchanged and the bridge’s answer is returned as is; when the bridge does not answer, the route returns `503` and Linear retries. The signature is not kept in the request log. The route is not part of the documented API and is served only where the integration is enabled. ## v3.43.1 — One-click copy for the MCP URLs, and no more sideways scroll 2026-10-18 New **The home page has a “Connect an MCP client” box** with the production URLs of the Exchange API and Flowie app MCP servers, each with a Copy button. Every MCP URL in [Build with AI]() and on the agent plugin page has one too. The App server is no longer marked “coming”: it is live in production. Fix **The documentation no longer scrolls sideways** at window widths between about 1000 and 1650 px when the session pill showed a long label such as “Session expired”. The pill now shortens its label instead of widening the top bar. Fix The agent onboarding FAQ still said OAuth would come to production later. It now describes what OAuth issues today: 7-day keys and a 90-day single-use refresh token. ## v3.43.0 — One MCP server for the API, one for the app 2026-10-17 Changed **`/exchange/mcp` now exposes the whole Exchange API**: every documented operation is a tool, where it used to offer a curated subset of eight tags. `/exchange/mcp/full` serves the same tools and stays available for existing configurations. Existing tools keep their names and arguments; a client that wants fewer tools selects them in its host. New **The Flowie app is an MCP server too, at`/agent-hub/mcp`** (staging). It offers the tools of Flowie’s in-app agent — documents, workflows, approvals, purchasing, budgets, organizations, payments, inbox and more — and acts as the signed-in user, with their permissions. Sign-in uses the same OAuth flow; see [Build with AI](). ## v3.42.0 — Sign in to the Flowie app MCP server with the same OAuth flow 2026-10-17 New **The authorization server now grants _app access_ to the Flowie app MCP server (`/agent-hub/mcp`).** A client whose `/oauth/authorize` request names that server as its `resource` (RFC 8707) is shown a consent screen for full access to the Flowie app as the signed-in user, and `POST /v1/oauth/token` returns that user’s own token instead of an Exchange API key: the app server calls services that act with the user’s permissions. The token lasts as long as the identity provider issues it for (24 hours); when a refresh token is returned (`flw_apprt_…`), `grant_type=refresh_token` renews it here. Only a server on this deployment’s own host qualifies. Every other client is unchanged and still receives an API key. Changed `organization_id` in the token response may be `null` for app access, which carries the user’s organizations in `organization_ids`. ## v3.41.1 — Static files under /docs-public load again 2026-10-17 Fix **Every file served from this API’s`/exchange/docs-public/` copy of the documentation answered `500`** on the deployed version: stylesheets, scripts, images, fonts and most pages. The web framework now listens for a client disconnect while it sends a file, and the API’s request middleware answered it with the request again, which the framework rejects. Static files are now served whole. The documentation at docs.get-flowie.com was not affected, and neither was any `/v1` route. ## v3.41.0 — A clearer consent screen: who gets access, as whom, to what 2026-10-17 Changed **The hosted consent page at`/oauth/consent` now names the application that receives the access.** The name comes from where the authorization code is sent (its `redirect_uri`): Claude, Visual Studio Code, ChatGPT, Cursor, or an application on your own computer, with the exact destination shown next to it. It used to show the shared public client id every MCP client registers with. A name the client gives itself is shown as an unverified claim and never takes the headline when it looks like a known application. The page loads no third-party resources: its font is served from this API. Changed **It shows the signed-in account by email and the number of organizations the key will reach, and folds the permissions into a one-line summary** (how many, how many can change data) that opens to the full list. The page now uses the look of the Flowie web app. Fix **Clicking Approve a second time no longer shows raw JSON.** It answers `404` with a page saying the request was already answered. The deny confirmation uses the same page. ## v3.40.5 — Consent sign-in no longer loops back to the identity provider 2026-10-16 Fix **Signing in on the consent page now lands on the consent screen instead of failing with`ERR_TOO_MANY_REDIRECTS`.** The sign-in session cookie carried the user’s whole access token. For a user who belongs to many organizations that token passes 11 KB, so the cookie exceeded the 4 KB browsers accept and was silently dropped. The consent page then saw no session and sent the browser back to sign in, again and again. The cookie now holds only who signed in. The token stays on the server, bound to the consent request it was obtained for and to that user. An unknown or expired consent request now answers `404` before any redirect to sign-in. ## v3.40.4 — Signing in on the consent page no longer ends on a 404 2026-10-16 Fix **After signing in, the consent flow now returns to`/oauth/consent?req=…`.** The sign-in callback redirected to a relative `./consent`, which a browser resolves against `/oauth/consent/callback` to `/oauth/consent/consent`. That page does not exist, so an MCP client’s sign-in stopped on `{"detail":"Not Found"}` right after Auth0. The redirect is now absolute and keeps the deployment prefix. Approve and deny are unchanged. ## v3.40.3 — VS Code can sign in to the MCP servers 2026-10-16 Fix **The`401` from `/exchange/mcp` and `/exchange/mcp/full` now points at a protected-resource document for that server, whose `resource` is the server’s own URL.** It pointed at the shared `/.well-known/oauth-protected-resource`, whose `resource` is the token audience `https://auth.flowie.me`. RFC 9728 §3.3 tells a client to reject a document that names another resource. VS Code does, so its `initialize` hung and then failed with `Cannot read properties of undefined (reading 'startsWith')`, without ever opening a sign-in. The new documents are served at `/.well-known/oauth-protected-resource/mcp` and `/.well-known/oauth-protected-resource/mcp/full`, and at their path-inserted forms `/.well-known/oauth-protected-resource/exchange/mcp` and `…/exchange/mcp/full`. Tokens, scopes, the authorization servers and the shared document are unchanged. ## v3.40.2 — MCP connections no longer drop with “Session not found” 2026-10-15 Fix **`/exchange/mcp` and `/exchange/mcp/full` no longer answer `404 "Session not found"` partway through a connection.** Each MCP session lived in the memory of the one server that opened it, so on an environment running several replicas a client’s next request regularly reached another one and was refused. Both servers are now stateless: every request stands on its own Bearer token, whichever replica answers it, and `initialize` no longer returns an `Mcp-Session-Id`. Clients need no change. Tools, arguments and authentication are unchanged. Fix **The documentation no longer prints MCP tool counts.** The [endpoints table](), the agent plugin page and the `connect-mcp` skill said 34 curated and 94 full tools; the servers serve more, and the number moves with every release. They now describe what each server covers, and `tools/list` returns the live set. ## v3.40.1 — Final invoice after deposits: both deductions the norm allows 2026-10-12 Fix **The guidance for a final invoice after deposits (XP Z12-014 cases 20 and 21) said never to deduct a deposit as a negative line. That was wrong.** The norm allows two options and recommends the first: one take-back line per deposit at quantity `-1`, referencing the deposit invoice (type `386`), which keeps the VAT and the pre-filled VAT return right. The second, `prepaidAmount` (BT-113), stays available, but the norm notes that it makes the pre-filled VAT return count the deposits’ VAT twice. Do not combine the two. The [deposit section](), the API reference, the description of `document.prepaidAmount` and the UBL generator’s scenario `uc-21-final-after-deposit` now say so. No change to how documents are processed. ## v3.40.0 — A final invoice can reference every deposit invoice and state the amount already paid 2026-10-10 New **`POST /v1/documents/send` accepts `document.billingReferences` and `document.prepaidAmount`.** `billingReferences` is a list of `{id, issueDate}`, one per preceding invoice (BG-3, 0..n), so a final invoice after several deposit invoices can reference each of them; the first entry also fills `billingReference` / `billingReferenceDate`, and sending both with different first invoices is refused with `422`. An invoice number containing `;` or `|` is refused. `prepaidAmount` is the amount already paid, VAT included (BT-113): it is stored on the document and reduces the amount due (BT-115 = BT-112 − BT-113) without touching the taxable base; a `prepaidAmount` above the invoice total incl. VAT is refused with `422`. Each reference is rendered as its own `BillingReference` when your organization's e-invoicing flow reads the `precedingInvoiceReferences` field; otherwise only the first one is. Until now this case could only be sent as `format=ubl-xml`. See [Deposit then final invoice](). ## v3.39.3 — Conformance checks return the validator’s real verdict 2026-10-07 Fix **`POST /v1/documents/validate` and the deposit-time conformance check now return the French validator’s actual verdict.** When the caller authenticated with a Flowie JWT, the request to the validator carried that token, and the validator’s front end rejected the oversized header before checking anything: every call came back `valid: false` with a single `validator_error`, and the check at deposit time was skipped. The validator is now called without the caller’s credentials, so a conforming document is reported valid and a non-conforming one returns its rule failures. Expect real rule ids (XSD, EN 16931, BR-FR) where you previously saw `validator_error`. ## v3.39.2 — No zero-amount stand-in for a document’s XML 2026-10-05 Fix **`GET /v1/documents/{document_id}/xml` and the AFNOR `GET /flows/{flowId}` (`docType=Original` or `Converted`) answer `404` rather than a stand-in that misstates the amounts.** When no XML is stored for a document, the UBL rendered from its structured data is now served only if it carries the document’s amount. A document with no lines and no amount, or a rendering whose payable amount is zero or absent while the document has a total, used to come back as a minimal UBL for 0.00, presented as the document’s XML; it now answers `404` “XML not available for this document”, like a document with nothing to render. Documents whose XML is stored are unaffected. `docType=ReadableView` now applies the same rule to decide whether a document has anything to render as a PDF, so a document is never renderable for one and empty for the other. ## v3.39.1 — Basikon no longer carries another platform’s address 2026-10-04 Fix **The platforms directory gave Basikon the contact address of FISKALTRUST, a different platform.** The DGFiP list we import carries `info@fiskaltrust.fr` on both rows. Basikon publishes no contact address, so `GET /v1/portability/platforms` and the public directory now return `contactEmail: null` for it, and an inter-platform portability message to Basikon stays unresolved until you name the recipient in `to`, instead of being written to FISKALTRUST. The correction is applied on every refresh of the list, so it cannot come back. ## v3.39.0 — Every credential of your organization, in one list 2026-09-30 New **`GET /v1/credentials` lists every credential that can act on your organization**: API keys (including multi-organization agent keys), the OAuth clients your admins created, and the OAuth clients Flowie set up for an integration (`managedBy: flowie`). Each entry gives its type, name, identifier, access, creation and last use, and never a secret. Admins only; `?includeInactive=true` adds revoked and expired ones. The same list is on the API keys page of these docs and on the API credentials page of the Flowie app. ## v3.38.1 — `/v1/me` no longer slows every other call for users in many organizations 2026-09-30 Fix **`GET /v1/me` looks up at most eight organizations at a time.** For a user in a hundred organizations it used to look them all up at once, and on a busy pod the rest of that user’s requests could then fail with `504` “Internal service timeout” for several seconds. Past its time budget the endpoint still answers, with the organizations it did not reach returned by id only (no name) — now alongside the ones it did, instead of dropping every name. ## v3.38.0 — Create your own OAuth2 client credentials 2026-09-30 New **`POST /v1/oauth/clients` lets an organization’s admin create a `client_id` / `client_secret` pair for the OAuth 2.0 client-credentials grant, without asking Flowie.** The client acts as its own technical user, never as the admin who created it, with exactly one role in each organization listed — the read-only viewer role unless another is named. The secret is returned once. `GET /v1/oauth/clients` lists the organization’s clients, `POST /v1/oauth/clients/{client_id}/rotate-secret` issues a new secret and `DELETE /v1/oauth/clients/{client_id}` revokes the client. Only an admin of every target organization can call these, with a user token: API keys and OAuth clients are refused with `403`. See the [authentication guide](), section _Machine-to-machine_. ## v3.37.1 — The other party’s files need access to the other party 2026-09-29 Fix **`GET /v1/documents/{document_id}/pdf` considers the files attached by the other party of the document only when your credentials give you access to that party’s organization.** Since v3.37.0 the endpoint looked for the issuer’s PDF among the files of both parties as soon as you could read the document. A buyer with no access to the seller’s organization now gets the next source instead — a Flowie rendering or a PDF generated from the document — and `X-Flowie-Pdf-Source` says which. ## v3.37.0 — The invoice PDF in one call, and the right one 2026-09-28 New **`GET /v1/documents/{document_id}/pdf` accepts the invoice number as well as the id.** With `X-Flowie-Organization-Id` naming the entity, `GET /v1/documents/FA-2026-0042/pdf` returns the PDF directly — no search call first. A number that matches several documents in that organization answers `409` with the candidate ids, as `GET /v1/documents/{document_id}` does. Changed **Which PDF is served is now fixed, and named in the`X-Flowie-Pdf-Source` response header.** In order: the document’s external file when it is a PDF (`external`); a PDF the issuer attached, deposited with the invoice or embedded in it (`issuer`); a Flowie rendering already attached (`flowie`); a PDF generated from the structured document (`generated`); and only then a platform’s rendering (`pa`). The endpoint used to serve whichever attached PDF came first, which on documents routed through a partner platform was that platform’s rendering, with its own layout and submission pages, rather than the issuer’s invoice. Fix **An XML file is never returned as a PDF.** When the document’s external file is the e-invoice XML (UBL, CII, IDOC) and no PDF is attached, the PDF is generated from the document instead of the XML being served with an `application/pdf` media type. ## v3.36.2 — A lifecycle message says it is about one invoice, and rejects with a rejection motif 2026-09-25 Fix **Every CDAR lifecycle message now carries`MultipleReferencesIndicator` (MDT-74), set to `false`.** The field is mandatory in XP Z12-012 annex A — it states that the status is about a single invoice — and it was missing from every lifecycle flow served by `GET /afnor/flow-service/v1/flows/{flowId}`, so a receiving platform that validates it refused the message. The FNFE CDV schematron does not test the field, which is why ours passed without it. Fix **A deposit Flowie rejects at ingress (`213` Rejetée) now gives the motif `REJ_SEMAN` instead of `NON_CONFORME`.** `NON_CONFORME` is a motif for `210` Refusée and `207` En litige only, so the rejection broke `BR-FR-CDV-CL-09`. The failing rules still travel in the free-text `Reason`. ## v3.36.1 — A document webhook tells you about your document, and only once it is yours 2026-09-24 Fix **`document.received`, `document.updated` and `document.deleted` carry the documented `data`, built for your organization.** They carried the platform’s internal event instead, the same one for every organization on the document — which included the counterparty’s templates (its internal custom field names and their options, such as cost centres) and the counterparty’s own custom field values. `data` now holds `documentId`, `type`, `number`, `direction`, `issueDate`, `dueDate`, `currency`, `netAmount`, `grossAmount`, your own `status`, `sender` and `receiver` (`organizationId`, `name`, `vatNumber`, `peppolId`), `createdAt` and `updatedAt`. `document.updated` adds `changes`, the before/after of each of those fields that moved, and is sent only when one of those fields changed, so `changes` is never empty — an edit to custom fields, yours or the counterparty’s, is no longer a webhook. `document.deleted` carries `documentId`. See [Payload shape](). Fix **A draft reaches the counterparty’s webhooks only once it is shared with it.** A draft names its counterparty before it is shared, and every organization named on a document was notified — so a supplier’s endpoint heard `document.received` for an invoice its customer had not yet sent, and `document.updated` for every edit to it. Document webhooks now go only to the organizations the document is visible to. ## v3.36.0 — A connection can outlive the key it started with 2026-09-23 New **`grant_type=refresh_token` on `POST /v1/oauth/token`.** The token response now carries a `refresh_token`; present it at the same endpoint to get a fresh key. The grant has been advertised in `grant_types_supported`, and echoed back by client registration, since those documents were written — and nothing implemented it. That is not a harmless gap: clients act on the advertisement, refreshing on a `401` and shortly before the stored expiry, so a connection that worked would simply stop at the key’s 7-day expiry, having asked to renew and been refused. New **Refresh tokens rotate.** Each redemption issues a new key _and_ a new refresh token, and revokes the pair presented — OAuth 2.1 requires that of a public client, which every MCP client is. A replayed token answers `invalid_grant`, as does an unknown or expired one; that is the code clients branch on, and anything else reads to them as a transient error worth retrying. A refresh token stays redeemable for 90 days, so an agent in regular use never reaches the bound. Changed **The renewed credential keeps exactly the reach it had** — same organizations, same per-organization scopes, same owning user. Permissions are not recomputed at refresh: they were resolved from `roles-permissions` using the signing-in user’s own token, which is long gone by then. Revoking the key, or letting the refresh token lapse, is what ends the access. Fix **A malformed token request answers`400`, not `500`.** The validation branch put the validator’s own error objects in `error_description`, which are not JSON-serialisable, so the response failed while being written. It is a string now, as [RFC 6749 §5.2]() specifies. ## v3.35.0 — A document comes back with its lines 2026-09-23 Fix **`GET /v1/documents/{id}` returns the document’s lines.** It fetched them — and even resolved their custom field names — then left them out of the response, so an integrator got the header and totals of an invoice with no way to read what was invoiced short of downloading the XML. The response now carries `lines`, one entry per line as recorded on the platform, in the same field names `InvoiceLine` takes on input: `description`, `quantity`, `unit`, `unitPrice`, `netAmount`, `vatRate`, `vatCategory`, plus `vatAmount` and `grossAmount`. `POST /v1/documents/{id}/actions` returns the same shape. The route’s description, which promised the lines in a nested `document` body that was never filled, now says what is returned. New **What a line says about its item comes back too.** `itemAttributes` carries the additional item properties (BG-32, each `name` / `value`), `itemStandardId` and `itemClassificationId` the identifiers (BT-157, BT-158), `allowancesCharges` the line-level allowances and charges (BG-27 / BG-28), and `customFields` the line’s custom fields, keyed by name — your organization’s only: a counterparty’s line fields are never returned. A sandbox document now carries a line as well, so the shape can be built against before going live. Changed **Values read the way the API writes them.** `vatRate` is a percentage (`20.0`), as on input, although the platform stores it as a fraction; `discountRate` is a percentage too, whichever way the platform recorded it; `unit` and `priceBaseUnit` are UN/ECE Rec 20 codes (`KGM`, `HUR`), although the platform stores a unit name. A line is returned as recorded, whatever recorded it: every field is optional, and a line the input schema would refuse — no description, a negative price — still comes back rather than failing the read. ## v3.34.0 — The Approve button works behind the gateway 2026-09-23 Fix **The consent form posted to a URL one prefix short, and answered`404`.** This service is served under `/exchange`, and the paths it declares internally carry no such prefix. Every other URL on the consent page was already built from the incoming request — the form’s own `action` was not, so a reader could register a client, sign in, and reach a correctly rendered consent screen that could not be submitted. It is built from the request now, like the rest of the page. ## v3.33.0 — Every MCP client can sign in, not just the ones we listed 2026-09-22 A redirect to your own machine is now accepted on any port and any path, so a native client needs no entry in any list — today or in future. Fix **A loopback redirect URI matches on any path, not only`/callback`.** The port was already ignored, as [RFC 8252 §7.3]() requires; the path was not, and that quietly excluded most of the ecosystem. The MCP SDK’s own default is `/oauth/callback`, so `mcp-remote` — the generic bridge most remote servers are reached through — and the MCP Inspector were both refused, while Claude Code’s `/callback` worked. Matching the path bought nothing: the only attacker who can receive a loopback redirect is another process on the same machine, and it can serve `/callback` exactly as easily. A URI with no path at all is accepted too. New **Loopback is a rule now, not a list.** Any `http` redirect to `localhost`, `127.0.0.1` or `[::1]` is accepted whatever port and path it carries, so Claude Code, VS Code, Cursor, `mcp-remote`, the MCP Inspector, opencode, Cline, Continue, Goose, Zed and anything built on the official SDKs all connect with no configuration on our side. `ALLOW_LOOPBACK_REDIRECT_URIS=false` turns it off for a deployment that deliberately serves hosted clients only. Changed **The exact-match list is now only for hosted clients.** Those are the ones that redirect to an https URL — Claude on the web, Desktop and mobile; VS Code and Insiders through their `vscode.dev` handler; ChatGPT connectors. Cursor’s old `cursor://` scheme is kept for anyone still on a build before 3.10.17, which is when Cursor moved to a loopback callback because, in their words, many OAuth providers will not accept a custom-scheme URI. Nothing about matching a public host changed: its port and path are part of its origin and are still compared exactly. New **A refused registration is logged with the callback it asked for.** Every hosted entry on that list was found by reading somebody’s failure; now the next unsupported client arrives as a log line rather than a support thread. The `400` already named the URI back to the caller — this records it for us too. ## v3.32.0 — Any MCP client can sign in, including the ones on a loopback port 2026-09-22 This server now runs the authorization-code flow itself instead of sending clients to the identity provider, which is what stopped native clients working at all. New **`GET /oauth/authorize` — a standard [RFC 6749]() authorization endpoint.** The existing `POST /v1/oauth/authorize` takes JSON and returns a consent URL, a shape only a client written against this API can use. Every general OAuth client — and every MCP client is one — opens a browser `GET` with query parameters, so the metadata had to advertise somebody else’s `/authorize`, and it advertised the identity provider’s. Both endpoints work; the JSON one is unchanged. Changed **`authorization_endpoint` and `token_endpoint` are this server’s.** They pointed at the identity provider, and that quietly excluded every native client. The identity provider matches redirect URIs exactly — no wildcards, no port-agnostic loopback — while a native client binds an _ephemeral_ port it cannot know in advance: Claude Code declares `http://localhost/callback` and then listens on, say, `:3118`. It was refused every time, on a different port every time, so Claude Code, VS Code and Cursor could not have worked whatever anyone allowlisted. The identity provider now sees exactly one redirect URI — this server’s own consent callback — and adding an MCP client is one entry in this server’s allowlist rather than a change in the identity tenant. **Nothing about how a person signs in changes:** the consent page still hands them to Auth0 Universal Login, with whatever their organization has configured — SSO, username and password, social. Fix **A loopback redirect URI now matches on any port.** [RFC 8252 §7.3]() requires this for `127.0.0.1`, and the same treatment is applied to `localhost`, which is what Claude Code needs. Scheme, host, path and query must still match exactly, and the rule applies _only_ to loopback — for any other host the port is part of the origin, and ignoring it would widen the allowlist to a different service. Fix **`POST /v1/oauth/token` accepts `application/x-www-form-urlencoded`.** That is what [RFC 6749 §4.1.3]() specifies and what every general OAuth client sends; the endpoint had only ever been driven by our own client, so it accepted JSON alone and answered `415` to everyone else. JSON still works. New **The default redirect allowlist covers the hosted clients.** Claude (web, Desktop, mobile), Claude Code, VS Code and Insiders, Cursor, ChatGPT connectors, and out-of-band. A client whose callback is not listed is refused at `/authorize` with `invalid_redirect_uri` and is never redirected to — bouncing an error to an untrusted URI is the open-redirect problem the allowlist exists to prevent. Protocol errors _after_ that check are returned through the redirect URI, per [RFC 6749 §4.1.2.1](), because a client waiting on a loopback listener cannot read an HTML error page. ## v3.31.0 — An agent credential reaches your own data, and the tools are named after the job 2026-09-21 Signing in to authorise an agent now produces a credential on your real organizations, bounded by what you are actually allowed to do in each of them. Changed **Approving an agent binds it to your organizations, not to a fresh sandbox.** The sign-in was real and the consent screen was real, and then `POST /v1/oauth/token` minted `org_sbx_…` — an empty organization created on the spot — so a connection that reported success showed the agent none of your documents. The credential is now issued against every organization the signing-in user can reach, and it is a `flw_live_…` key because it touches live data. A deployment with no sign-in configured still issues the sandbox key it always did. Changed **Scopes come from your permissions, not from what the agent asked for.** They were checked against this service's own scope list, so a credential said `documents.write` because the client requested it. Each scope is now granted only where `roles-permissions` — the authority every other Flowie service keys on — says the user holds the matching right: `documents.read` needs `read:transaction:invoices`, `send` needs `create:transaction:invoices`, `lifecycle` needs `update:transaction:invoice-lifecycle`. An account holding none of them in any organization is refused at the consent screen rather than handed a key that fails every call. New **`organization_ids` on the token response.** Every organization the credential may act on. Name one in `X-Flowie-Organization-Id` to act there; any other is refused with `403`. Scopes are kept _per organization_ , so an agent whose user approves invoices in one company and only reads them in another cannot carry the first company's rights into the second — the header selects the organization and the rights together. Changed **MCP tools, SDK methods and endpoint anchors are named after the job.** `send_document_v1_documents_send_post` is now `send_document`; `list_documents`, `search_documents`, `get_lifecycle` likewise, across all 139 operations. The old names were FastAPI's generated default — handler, path and method concatenated — and they are what an agent host shows the model on every single request. Six pairs of operations turned out to have been relying on the path suffix for uniqueness (the AFNOR certification twins of the webhook routes, two health checks, and the OCI callback's `GET`/`POST` pair); they are named apart explicitly now. **If you generate a client from`openapi.json`, your method names change with this release.** Fix **The consent page no longer promises a sandbox to someone signing in.** It told every visitor that approving would mint a sandbox key on a fresh organization, including the users about to grant access to their real one. It now names who is signed in and what the key will reach. ## v3.30.0 — What is on screen is what gets signed, and a signed act proves it 2026-09-21 Changed **The agreement form saves itself; the _Update the agreement_ button is gone.** A field that has stopped changing is saved, a value picked from a list is saved at once, and the addresses filled in from the annuaire are saved with them. The deed, its digest and the « still to do » line follow — the inputs are never re-rendered, because replacing a form somebody is typing in steals the caret. Downloading and signing still flush anything in flight first. Fix **The page saves the agreement before downloading or signing it.** The form is a draft; the document is rendered from the stored mandate. So a reader who filled the addresses in and pressed _Download_ got a deed reading « Aucune adresse » and « Pour l’assujetti : — », and one who pressed _Sign_ was refused for a missing `addressScope` sitting two centimetres above the button. Downloading, signing here and uploading a signed copy each flush the draft first. An amendment that changes nothing still changes nothing, digest included. Fix **The attestation quotes the digest that was signed, never a fresh one.** Re-rendering a mandate under a newer template gives different bytes, so a document signed before a template change would have printed today’s hash under « Texte signé » — an empreinte nobody ever signed. The digests now come from the signature record; when the reproduction differs, the act says so, prints both, and names the stored piece holding the text that was signed. New **A signed agreement carries the proof of its own signature.** The `.docx` gains a second page — _Attestation de signature électronique_ — naming who signed, when, by which means, and the recorded digests: the signed text, the mandate, and the evidence-chain entry with the one before it. The agreement’s own pages are untouched, because their bytes are what the first of those digests is taken over, and the attestation says in plain French how to recompute it. An unsigned draft attests nothing. Fix **The act states its date in words.** « Le présent accord prend effet le 2026-09-29 » — an ISO date, in a French deed, in the one line of it carrying a date. It reads _29 septembre 2026_ now (and _1er_ for the first of the month), from a table rather than a locale so the digest cannot depend on the server. Fix **An empty address scope reads as empty.** It printed as a bullet holding a dash — a list of one nothing. It is a sentence: _aucune adresse électronique n’est nommée dans le présent accord : le périmètre reste à compléter_. ## v3.29.0 — A port is live on the next nightly run 2026-09-21 Changed **A request opened without a date d’effet now takes effect on the first nightly annuaire run after the objection window — not a business day later.** The directory is re-pointed by a batch that runs every night at 02:00 Europe/Paris, so a port agreed on day D is live on D+1, weekends included. Planning against the fifteen-business-day backstop cost the taxpayer two or three days of invoices still arriving at the platform they were leaving. Pass `effectiveDate` to choose any other date, exactly as before. New **`clocks.annuaireNextRun` and `clocks.annuaireRunsAt`.** When the directory will actually move, beside `annuaireUpdateBy`, the date nobody may go past. Both are published because the difference between them is what a taxpayer is entitled to know before agreeing a date. Changed **A picked platform is shown by name.** The fields carried `0022`, or the slug `flowie`, while the schema two lines above named the same platform properly. They now read `PENNYLANE (0022)` — the way the deed names it — and the matricule is resolved back out on save, because that is what the annuaire routes on. Fix **The agreement can be downloaded at any moment.** The link lived inside _Sign your own copy_ , a panel that disappears the moment the mandate is signed — so the one document anybody would want to keep became undownloadable exactly when it started to matter. It sits beside the agreement now, signed or not. ## v3.28.0 — An organization you name is one you hold 2026-09-20 Fix **Naming an organization in`X-Flowie-Organization-Id`, `Organization-Id` or `companyId` now only widens access to organizations underneath one you already hold.** The check behind those three was “does org-v2 know this id”, and org-v2 answers that for any organization to any authenticated caller — so a token could be pointed at an organization it had no standing in. Access is now read from the ownership hierarchy: a sub-organization of yours still resolves, a parent, a sibling or an unrelated tenant answers `403`, and an ownership lookup that fails refuses rather than widens. API keys are unaffected — they were already bound to their organization. ## v3.27.0 — The panel reads like a move, and asks each thing once 2026-09-20 New **`clocks.infoHandoverBy`: the handover deadline as a date.** It was published as `infoHandoverBusinessDays: 5` and nothing else, leaving a caller to count _jours ouvrés_ over bank holidays by hand — the one arithmetic this API exists to do. It runs from the notification once one is recorded, and from the opening until then, the same conservative basis as the objection window. Changed **The schedule shows all six deadlines, not four.** The two it hid are the ones the _outgoing_ platform owes — the continuity information it has to hand over, and the date the annuaire entry is re-pointed by — which are exactly the dates a taxpayer chasing a late port has to quote. Changed **The port reads left to right.** The platform being left comes first, under a drawing of the move: _leaving_ → _designated_ , each with the name and matricule the deed will carry. Two stacked fields labelled « désignée » and « quittée » carried a direction only a reader who already knew it could see. Changed **The addresses the annuaire publishes are filled in, not offered.** The page had already read them to say who routes the company; it then reported the empty field as a gap and made the reader press a button to copy them across. The button stays, because an edit has to be undoable, and nothing is written until _Save_. Fix **« Signed by » was asked three times on one screen.** Once as the blank of the deed, then again in each of the two ways to sign — three inputs for one datum, any two of which could disagree, with the last one written winning silently. It is asked once, in the agreement, and each way says whose name it is about to put on the act. Changed **« This company is fully identified » is gone.** The panel above it lists what was found; a line announcing that it found it was one more thing to read where everything else is something to act on. ## v3.26.0 — The platforms are picked from the registry, not typed 2026-09-20 Changed **Both platform fields search the 165 registered PAs.** A dropdown that opens on focus and filters by name or by matricule, fed by `GET /v1/portability/platforms` — one fetch, because a directory of 165 rows is not a search space. Nobody should be typing four digits from memory into a deed. New **Every offered matricule says how sure it is.** `confirmed` (the operator told us), `published` (the operator says so) or `inferred` (its own SIREN routes on it) — as a chip in the list and a full sentence under the field. `0003` looks equally certain whichever way we came by it, and a reader about to sign is entitled to the difference. A platform with no provable number is offered too, and the agreement names it as typed rather than inventing one. Changed **The platform being left arrives already filled in.** The annuaire answered before the reader pressed anything — the panel above the button had just named it — so opening the request carries it. The field says it was pre-filled, and it stays editable. Changed **The agreement names the platform it numbers, as far as it can prove it.** « Plateforme quittée : 0003 » names nobody, so the same registry join the rest of the page uses now reaches the deed — carrying its evidence. The platform designated is named as the annuaire spells it, not by the service's own slug. A matricule its operator confirmed or published is named plainly (`CEGID (0007)`); one we _inferred_ is named with the reservation written into the act itself, because 63 of the 165 registered platforms are in that tier and a binding document may neither drop the name nor vouch for it. Re-rendering an unsigned mandate therefore moves its digest, as any template change does — the digest recorded with a signature is kept beside it and is not recomputed. ## v3.25.0 — Every blank can be filled, and a port cannot start here 2026-09-20 Changed **The designated platform is amendable, and defaults to Flowie.** `incomingPlatform` joins `effectiveDate`, `addressScope`, `signatory` and `outgoingPlatform` on `PATCH …/mandate`. It reads like identity and is not: the decree calls it _plateforme agréée désignée_ , it defaults to us because this is our API, and a taxpayer designating somebody else was previously obliged to open a new request — after reading an agreement that named the wrong platform. New **Every blank in the deed now has a field on the page.** The platform designated and the platform being left had none, so “Plateforme quittée : —” could only ever be a dash. Changed **A port that would start at Flowie is refused with somewhere to go.** A designation moves a taxpayer _to_ us; from us to us is not a port. Naming Flowie as the platform being left — by its id or its matricule, at opening or on an amendment — answers `409` and points at `support@flowie.fr`. A caller who names the platform being left is taken at their word; when nobody names one, the annuaire is asked at opening, best-effort: an annuaire that cannot be read never refuses a port, because silence is not evidence. The page shows the same address instead of a button nobody could use. ## v3.24.0 — The agreement as a real Word document 2026-09-20 New **`GET /v1/portability/requests/{requestRef}/agreement.docx` serves the agreement as an OOXML package.** A genuine `.docx` — content types, relationships, document and styles — rather than markup wearing a Word extension, so Word, LibreOffice and Google Docs open it without argument. It is generated from the text `GET …/agreement` returns, which is the text the digest is taken over, and **nothing is added** : no generation date, no page numbers, so two downloads of one agreement are byte-identical. The response carries `X-Agreement-Sha256`, so a caller holding an older copy can tell it apart from the current text without opening either. Changed ** _Sign your own copy_ hands over that document.** The page fetched a `.doc` it assembled itself; it now asks the API for the real package. One renderer instead of two, and the file the taxpayer signs is the one the API vouches for. Fix **Article 1 was cut in half.** It opens “L’assujetti désigne la plateforme désignée…”, which is how the identity lines in the parties block open too — so its first line was set apart from the rest of its own sentence, on the page and in the document. Identity lines are now recognised only between the parties banner and the clauses. ## v3.23.0 — The agreement looks like the document it is 2026-09-20 Changed **The designation agreement is set as a deed, not as a code listing.** A sheet with margins, a serif face, a centred title, section banners, numbered articles and the address scope as a list — on screen it now reads as the thing somebody is about to be bound by. **The bytes are untouched:** the sheet is built from the exact text the signature is taken over, the digest below it is unchanged, and the verbatim text is kept beside the rendering rather than read back out of it. Changed **Downloading it gives you a document a word processor opens.** _Sign your own copy_ hands over the deed with its formatting, under a `.doc` name, so it arrives looking like what was on screen instead of a wall of monospace. The plain text travels inside the file, so the bytes that were hashed stay with the document they came from. ## v3.22.2 — Signing here says what it kept 2026-09-20 Fix **The new “sign it here” path fell through to the generic confirmation.** Each way of signing has its own sentence — the uploaded document, the agreement approved in Flowie, a signature given on paper — and `accepted`, added with the in-page path, had none. So the way a reader of this page is most likely to sign was the one that could not say what it had kept. It now reads “the text you read here is kept and hashed, as the proof”, and a test fails if a recorded method ever lacks a sentence again. ## v3.22.1 — A refused signature leaves nothing behind 2026-09-20 Fix **`POST /v1/portability/requests/{requestRef}/mandate/signature/accepted` wrote the signatory before it had somewhere to keep the agreement.** The name was amended onto the mandate — an entry in the evidence chain — and only then was the rendered text stored. When the documents service could not take it, the call answered `502` saying nothing had been recorded, while the mandate already named somebody who had signed nothing. The text is now rendered from the mandate as it will be, stored first, and nothing reaches the chain until the artefact is safe. ## v3.22.0 — A formal agreement, and two ways to sign it 2026-09-20 The designation agreement now reads as the deed it is, and the taxpayer who has just read it can sign it without producing a document of their own. Changed **The agreement is written as a formal deed.** Parties identified, numbered articles (objet, plateforme quittée, date d’effet, périmètre des adresses, portée et durée), a signature block, and the reference to article 242 _nonies_ E bis. The five decree items are unchanged — this is how they are set out. **The rendered text therefore differs from the previous wording:** a mandate signed before this release keeps the digests recorded with its signature, which are what that act was taken over, and re-rendering it today shows the current template rather than the bytes that were signed. New **`POST /v1/portability/requests/{requestRef}/mandate/signature/accepted` signs the text as rendered.** The fourth way to sign, and the only one where the artefact and the rendering are the same document: our text is stored and the signature is taken over exactly those bytes. The instant is observed rather than asserted, because the act happens in the call. Refused (`409`) on an incomplete mandate or one already signed, and (`502`) when the text cannot be stored — without the artefact it would be a paper assertion again, so nothing is recorded. New **The page offers both ways, named, side by side.** _Sign it here_ takes the name of whoever signs and records the agreement on screen. _Sign your own copy_ downloads that same text to sign by hand, by e-signature or in your advocate’s wording, then takes the file back. The download is the bytes already on screen, never a second fetch that might differ. New **The addresses covered fill themselves.** The annuaire publishes every addressing line declared for the SIREN, and the page has already read them — so the field offers them in one click and says how many. They stay editable: a scope is the taxpayer’s to decide, and a subsidiary’s line may belong to a port they are not making today. ## v3.21.2 — A recorded signature says so 2026-09-20 Fix **Signing the agreement left no trace on the page.** The signature block is shown while the signature is missing, so recording one removed the block — and with it the line confirming what had just happened. The request carried the signatory, the instant and both digests, and the page said nothing at all. It now states “signed by _name_ on _date_ ”, rendered from the request rather than shown once, so it is still there on the next read. ## v3.21.1 — The “updated” line stays on screen 2026-09-20 Fix **Completing the mandate said nothing, although it worked.** On the Change platform page, filling in the _date d’effet_ , the addresses or the signatory re-rendered the agreement and moved its digest correctly — and the confirmation explaining that the digest had moved was painted onto the panel a moment before the re-read of the request replaced it. The message is now shown on the panel that comes back. ## v3.21.0 — The agreement, filled in, completed and signed in one place 2026-09-19 A request could be opened and signed, but the document it rests on could not be read without asking somebody to sign it — and what opening could not know could never be filled in afterwards. New **`GET /v1/portability/requests/{requestRef}/agreement` returns the designation agreement as it currently reads.** The five items article 242 _nonies_ E bis requires, rendered from the mandate and filled in from whatever was resolved, plus `agreementSha256` — the digest of exactly those bytes, so a caller can show the text and prove afterwards which version was on screen. It reads and writes nothing: until now the agreement came back only from the call that opens an approval check, so seeing the document meant starting a signature. New **`PATCH /v1/portability/requests/{requestRef}/mandate` completes an unsigned mandate.** A request opens from a single identifier, so the address scope is derived and the signatory is usually nobody yet; `mandateGaps` said so and said so for ever. `effectiveDate`, `addressScope`, `signatory` and `outgoingPlatform` can now be sent, singly or together. Each amendment is an entry in the evidence chain carrying only the fields that actually moved, and an amendment that changes nothing changes nothing — including the digest. Changed **The digest moves with the text, and a signed mandate is frozen.** Amending re-renders the agreement, so an approval opened on the old one stops answering for the new one — it is not the agreement that was put in front of anybody. Once a signature exists the text no longer moves: `PATCH` answers `409`, because that digest is what somebody put their name to. What the request _is_ — its reference, its taxpayer, the incoming platform — was never amendable and still is not. New **The Change platform page shows the agreement, and lets you finish it.** Opening a request now displays the rendered text with its digest, above inputs for the date d’effet, the addresses covered and who signs. Updating re-reads the request, so “nobody is named as signing it” disappears the moment somebody is, and signing re-reads it again — signed is not the end of the procedure, it is the start of the clocks. ## v3.21.0 — An agent can register itself and sign you in 2026-09-20 Connecting this server to an AI client now takes a URL and a sign-in, with nothing to configure. New **`POST /v1/oauth/register` — RFC 7591 client registration.** It returns the public application this server already owns rather than creating one. An MCP client will not start an authorization-code flow without a client id, and neither usual way of getting one works here: our identity provider has dynamic registration disabled, and advertises Client ID Metadata Document support that it then refuses at authorization time. Registering against this endpoint gives a client id that is already known and already authorized. The `redirect_uri` is checked here, so an unregistered callback is refused at registration instead of one redirect later. Changed **The authorization-server document describes a complete flow.** It now carries `authorization_endpoint`, `token_endpoint`, `registration_endpoint`, `response_types_supported` and `authorization_code` among its grant types. It previously advertised only the handoff grant with no way to start an interactive sign-in, so every connector that followed it stopped there. The handoff grant keeps its own `handoff_token_endpoint`. Fix **The advertised identity provider is the one this deployment trusts.** It was hardcoded to production, so staging published the production tenant while validating tokens against its own — sending clients to look for an application that exists only elsewhere. ## v3.20.0 — Approving an agent now requires signing in 2026-09-19 The consent flow can be used with a real account, and can no longer be used by a stranger. Changed **Approving an agent requires a signed-in user.** `POST /oauth/consent/{req}/approve` authenticated nobody: it took a request id and minted an authorization code, with no session and no check that the person clicking Approve was the account holder, or anyone at all. Opening a consent link now sends the user to sign in first, and Approve is refused without that identity. New **Sign in with the credentials you already use.** The consent page redirects to Flowie’s own login, so whatever your organization is set up with — SSO, username and password, social — is what you see. Authorization code with PKCE (S256); no new account, and no password ever reaches this API. Changed **A deployment without consent sign-in configured refuses to approve rather than approving anonymously.** It answers `503` and points at `POST /v1/sandbox/bootstrap` for a sandbox credential or the handoff flow for a real account. The previous behaviour is available deliberately, via `CONSENT_ALLOW_UNAUTHENTICATED`. ## v3.19.0 — An unauthenticated MCP request now says how to authenticate 2026-09-19 A client with no credential could not discover that it needed one, or where to get it. It can now. Changed **A request to`/mcp` or `/mcp/full` with no `Authorization` header returns `401` with `WWW-Authenticate: Bearer resource_metadata="…"`.** It previously opened a session, served the full tool catalogue, and reported the 401 as text inside a `200` when a tool was finally called — indistinguishable, to an MCP client, from a broken tool. Only the no-header case changes: a token that is present is still judged by the route that receives it, exactly as before, so every working integration is unaffected. New **`/.well-known/oauth-protected-resource` (RFC 9728).** The document the challenge points at. It names both authorization servers — this API, which issues agent credentials with no human in the loop, and Auth0, which signs a person in — so a compliant client can pick the right one for its caller. Served at the path-inserted variant too. Fix **The curated tool count in the documentation was wrong.** The `/mcp` endpoint serves 47 tools, not the 34 the docs claimed. ## v3.18.4 — A lookup that fails says which failure it was 2026-09-19 Found by driving the published page rather than reading it: a real company could be offered by the picker and then refused by the lookup, with nothing said about why. Fix **`POST /v1/portability/resolve` says which kind of nothing it found.** A 404 covered a company struck off years ago and one incorporated last week alike. The public French register separates them, and its answer now carries into the `detail`: struck off (with the date) means there is no request to open, ever; active but undeclared means there is nothing to port _yet_. The register is asked only when the resolve has already failed, and a register that does not answer leaves the original 404 untouched — a timeout is not evidence that someone’s company is gone. Fix **The Change platform page resolves against the same registry it searches.** The picker read production while resolving read the page’s own sandbox, whose PPF annuaire is the PISTE test directory — so a company the picker had just offered came back unresolvable. Opening a request still writes to the throwaway sandbox key, and when that write fails on a company the page has just shown as routed, it now says so rather than blaming the company. Fix **A rejected sandbox key is replaced, not believed.** The key lives in `sessionStorage`, so one 401 made every later call on the tab fail the same silent way until the tab was closed: press the button, nothing happens. A 401 or 403 now mints a fresh key and retries once, and a failure that survives that is shown with its reason where the button is. ## v3.18.3 — A company with no declared line is still addressable 2026-09-18 Found by running the signing flow end to end rather than reading the spec: the port could be opened and then not signed. Fix **`addressScope` defaults to the company’s own SIREN and SIRET** when the annuaire holds no addressing line and the company is not on Peppol. It used to come back empty, which made the mandate miss a decree item — so [Change platform]() offered a signature and `POST /v1/portability/requests/{ref}/mandate/signature/document` then refused it with `409 addressScope still missing`. A French company is addressable by its SIREN and SIRET whether or not anyone declared a line for it; both go in, because a port covering the legal unit but not the establishment leaves invoices addressed to the SIRET arriving at the platform you are leaving. A declared line still wins, and a non-French registration gets no invented scope. ## v3.18.2 — Sign the agreement with your own document 2026-09-18 There were two ways to sign, and neither fits a taxpayer whose legal representative is not a Flowie user: an approval check needs an account, and asserting a paper signature keeps nothing at all. New **`POST /v1/portability/requests/{ref}/mandate/signature/document` — upload the agreement you signed.** Multipart: the file, who signed it, when. We store the document under your organization and record the signature bound to it, so it replays onto the mandate like any other and `mandateGaps` closes. New **`agreementSha256` is the digest of _your_ file, not of our rendering.** They are different documents — you may have signed your own wording, or your advocate’s — and recording ours as the one signed would be a statement we cannot support. `mandateSha256` still binds to the decree content, so amending the mandate afterwards invalidates this signature exactly as it invalidates an in-app one. New **The same thing from[Change platform](), without an account.** When a request comes back needing a signature, the page asks for the name, the date and the file, and records it. Name, date and file together or not at all: a name with no document is the assertion the platform stopped accepting. Changed **A signature cannot be dated in the future** (`400`), a file over 10 MB is refused (`413`), and an agreement that already has a signature cannot receive a second one (`409`) — the evidence chain folds signatures in order, so accepting one would replace the recorded signatory, instant and document with no trace of the first. An act dated after the moment it is recorded is worse than an acknowledged gap. ## v3.18.1 — Signing a mandate reaches the services it depends on 2026-09-18 Shipped hours earlier in [v3.16.23](<#2026-09-18-sign-in-app>), and it would have failed on the first real call. Fix **`POST /v1/portability/requests/{ref}/mandate/signature` called approval and the documents service with no credentials.** Both calls opened their own HTTP client, so neither carried the bearer token nor the actor headers the documents service authorises a write by — every attempt would have come back `401`/`403` and surfaced to you as `502 The approval service did not answer`, which reads like an outage rather than a missing credential. They now go through the same authenticated path as every other internal call. Fix **The check is scoped to your organization again.** Approval reads `X-Flowie-Organization-Id`; the shared client sends `X-Organization-Id`. A call carrying only one of the two is either unscoped or unauthenticated, so both go out now. ## v3.18.0 — Agent plugin: the tools, the skills and the CLI on one page 2026-09-18 The MCP server and the hosted agent skills existed but were documented apart, and the skills were not documented at all. There is now one page that sets an agent up. New **[Agent plugin]() — public beta.** One setup covering all three agent surfaces: the MCP server (`/mcp` curated, `/mcp/full`), the 14 hosted agent skills, and the CLI. Copy-paste quickstarts for Claude Code, Cursor, VS Code and Codex, a one-request check that the connection works, and an explicit statement of what beta covers — endpoints, auth and the skill index URL are under the [deprecation policy](); individual tool names and skill contents can still change and are announced here. New **The agent skills are documented.** Fourteen skills have been served at `/.well-known/agent-skills/index.json` with a per-skill `sha256` digest, and no page named them. They are now listed, with what each one covers and how to load it in a client that does not read the index by itself. Fix **A failed MCP mount now stops the process instead of logging a warning.** When a dependency resolve broke `FastApiMCP`, the app started healthy and `/mcp` answered `404` on every environment while the documentation advertised 34 tools. All three mounts — curated, full and discovery — now raise at import, so a rollout catches the failure rather than a customer. ## v3.17.2 — The same correction, on the other four deposit paths 2026-09-18 v3.17.0 stopped a raw-body deposit being stored under a type its bytes contradict. It reached one of the five ways to deposit a file; this reaches the rest. Fix **A file sent as a base64`file` attachment is stored under the type its bytes actually are.** That covers JSON mode on [`POST /v1/documents/send`](), `POST /v1/documents/send/batch` and the event path. A PDF declared as `application/json` — the default most HTTP clients send — was persisted as JSON, because the declared type was believed whenever the caller supplied one and the bytes were only consulted when they had not. Nothing that is accepted today starts being refused, and a deposit whose declaration was already right is unaffected. Fix **A declaration more precise than the bytes survives, including the ones an allowlist had missed.** Only an unambiguous binary container overrides the declaration, and text is never second-guessed. A container subtype is kept whenever it says more than the container does: a structured syntax suffix that matches the bytes ([RFC 6839]()’s `+zip` / `+gzip` — this is how a signed `application/vnd.etsi.asic-e+zip` e-invoice keeps its identity), and any type in the vendor tree ([RFC 6838]() `application/vnd.…`), which names one specific format and so is never the generic container itself — an `.xlsm`, `.ppsx`, `.odg` or `.apk` is no longer flattened to `application/zip`. A suffix that _contradicts_ the bytes is still a mislabel and is still corrected. Fix **A declaration that names no type at all no longer becomes one.** `contentType=pdf` — a file extension where a media type belongs — used to be stored verbatim as `pdf`; it is now read from the bytes as `application/pdf`. A declaration that is only parameters (`; charset=utf-8`, which is what an ERP concatenating an empty base type sends) or only whitespace now falls back to the sniff instead of being persisted as the document’s media type. ## v3.17.1 — 0147 is Shine, and the Confidence column is back 2026-09-18 Fix **`0147` belongs to _Shine_ , not _PAYFLOWS_.** PAYFLOWS held it by inference: its own SIREN routes on `0147` in the PPF annuaire. That is because it is a Shine client, not because the number is its own. Shine states the number in its terms of use (§4.1), so the row is now `published` with that quote. `GET /v1/portability/platforms` returns `matricule: "0147"` on Shine and `null` on PAYFLOWS. Fifteen rows are `published` and 63 `inferred`. 92 of 165 rows still carry a matricule. New **The directory shows a Confidence column again.** It says how each number was established (_confirmed_ , _published_ , _inferred_ or _unknown_), and it sorts. Like the confidence filter, it appears only to a signed-in reader, the same reader who can see the numbers. ## v3.17.0 — `gzip` request bodies, and a deposit stored as what it is 2026-09-18 Both changes are additive: no request that is accepted today starts being refused. New **`Content-Encoding: gzip` is decompressed on the way in.** Send a gzip-compressed body (`x-gzip` and lists that reduce to gzip, such as `identity, gzip`, work too) on any endpoint, including the raw-body form of `POST /v1/documents/send`, and the handler reads the payload you meant to send. Useful when the document carries an embedded PDF: an ERP invoice of that shape typically drops by about a third on the wire. A body this service cannot inflate — an encoding it does not implement, a payload that is not really gzip, or one that would expand past its ceiling — is passed through untouched, exactly as before, so nothing that worked stops working. Fix **A raw-body deposit is stored under the type its bytes actually are.** Raw-body mode keeps the payload verbatim under the `contentType` and `filename` you pass in the query string, and nothing checked that the two agreed — a compressed or binary payload deposited as `application/xml` was persisted as if it were XML, so nothing downstream could read it. The declared type is now corrected from the first bytes, the same way the stored file extension already was. Only an unambiguous binary container overrides the declaration; text is never second-guessed, and a more specific declaration wins over a broader one (an `.xlsx` stays an `.xlsx`, not a zip). Changed **Two consequences of that correction, for clients that read them.** `storedFormat` now answers `gzip` for a gzip payload where it answered `binary`, on every deposit route. And when you send no `Idempotency-Key`, the implicit key is derived from the payload including its content type — so a deposit whose declared type was wrong hashes differently after this release, and a retry that crosses the upgrade mints a new document rather than replaying the old one. Only previously-mislabelled deposits are affected; a correctly declared one keeps the same key. ## v3.16.23 — The designation agreement can be signed in Flowie 2026-09-18 A mandate could be _recorded_ as signed — on paper, or in your own tool — but there was nowhere to actually sign one. That left the act the whole port rests on outside the platform. New **[`POST /v1/portability/requests/{ref}/mandate/signature`]() puts the agreement in front of someone.** The text is rendered from the mandate the request already holds — the five items article 242 _nonies_ E bis requires — and an approval check is opened on it for the Flowie users you name. They sign by deciding; what is stored is their decision, its instant and its author, none of which the API supplies. The response carries the text as presented and its digest, so you can show exactly what was signed. A request opened on an identifier alone is refused with `409` rather than rendering the agreement with blanks where the decree wants values. New **[`GET /v1/portability/requests/{ref}/mandate/signature`]() reads the decision back.** `signed` stays `false` while the check is open, refused or withdrawn. The first read that finds a passed one writes the signature into the hash-linked evidence chain, so the request carries its `signedAt` from then on whether or not this endpoint is called again. New **Only a decision on _this_ agreement is a signature.** The check carries the context key `portability::`. An approval vote is scoped to the object it hangs on, so without that key a decision taken on the same document for another reason would read here as a signature. Move the _date d’effet_ or the address scope and the digest moves with it — the earlier decision stops answering for the new agreement, because it is not the agreement that was signed. ## v3.16.22 — The request says what the agreement still needs 2026-09-17 A request opened from [Change platform]() showed its four deadlines and nothing else, so it read as complete — while the plan directly above it said, correctly, that a dated and signed designation agreement is required. New **`mandateGaps` on [`POST /v1/portability/requests`]() and `GET /v1/portability/requests/{ref}`.** Which decree items are still missing — `signatory` when nobody is named, `signature` while the agreement is unsigned. They were only ever inside the first entry of the evidence chain, so a client had to dig for the one fact that decides whether a port can proceed. It sits _beside_ the mandate, never inside it: that object is hashed, and a derived list folded in would change its own digest the moment you signed it. Fix **The page no longer says nothing is missing when the agreement is.** “Nothing missing: this company can be filed as it stands” was about the _company’s identifiers_ , four lines above a block asking for a signed agreement that had never been collected. It now reads “this company is fully identified”, and the receipt lists what the agreement still needs in words. _You re-grant_ became _You provide_ in all three languages. ## v3.16.21 — A name in a field is no longer a signature 2026-09-17 The designation agreement is what authorises a port: it is what the outgoing platform may object to as `mandate_invalid`, and what the administration asks for when a port is contested. Changed **`signatory` declares who will sign; it no longer signs.** Supplying the name used to stamp `signedAt` with the server’s clock, so the mandate claimed to be signed when nobody had seen a document and nothing was kept. `signedAt` now stays `null` until an act is recorded, and `mandateGaps` reports `signature` until then — a gap the outgoing platform would otherwise raise five business days later. A client that read `signedAt` as proof was reading its own input echoed back. New **`signedAt` and `signatureMethod` on [`POST /v1/portability/requests`]().** A mandate signed outside Flowie — on paper, or in your own tool — is signed, and these record it: you assert the instant, we keep it verbatim in the hash-linked evidence chain with how it was taken (`paper`, `external`, `approval`). What the platform will not do is invent the instant on your behalf. New **A signature is bound to the agreement it signed.** The record carries the SHA-256 of the mandate’s data and of the rendered document, so amending the _date d’effet_ or the address scope afterwards leaves a signature that no longer verifies — the port that was agreed to is not the port being made. The two digests are separate on purpose: rewording the document does not void past signatures. ## v3.16.20 — The deadlines read as dates, in the page’s own language 2026-09-17 The four clocks on [Change platform]() are legal deadlines — notification, objection window, _date d’effet_ , twelve-month continuity — and every one of them printed exactly as the API spells it. Fix **`2026-09-21` became _21 septembre 2026_ on the French page, _21 settembre 2026_ on the Italian one.** An ISO date on a French page is foreign at best and ambiguous at worst: a reader who takes it for a day-month reads the objection window as March. The month is spelled out in the page’s own language, which no locale can misread, and the ISO value stays in the `