Building on Subsidia for your clients

You keep your stack: your models, your retrieval, your automations, your interface. Subsidia adds the layer your clients' legal team asks for, one call at a time: personal data masked before it reaches an external provider, usage metered per client, and a signed proof for what the AI did.

This page is the map. The Partner API is the reference for provisioning and billing; the other pages are linked where they apply.

A model call is counted in questions. A Vérificateur check calls no model and is counted as a control, separately. Both appear on each client statement.

A key that names at least one capability is restricted to those routes; anything else answers 403 scope_denied. Keys created before scopes existed keep their full access, which is why a key for a client application must be created through the partner API, which requires a capability.

Two optional ceilings protect you from a runaway integration:

• monthlyQuestionLimit refuses the key with 402 API_KEY_BUDGET_EXCEEDED once the calendar month's questions are used. It is counted from usage logs, so it can lag a burst by a few seconds: a guard rail, not a meter. Verifier controls do not count.
• ratePerMinute answers 429 with Retry-After. The counter is shared across server instances.

Change either later with PATCH /developer/api-keys/:id. See Authentication and Rate limits and quotas.

If your product already answers from a retrieval pipeline, the fastest win for a regulated client is to check each answer against the passages that retrieval returned, before showing it. You send the answer and the passages; you get a verdict per claim and a signed report, and Cortex is not involved.

The report says coverage.mode: "provided": it attests that this text, against these passages, gave these verdicts. It does not attest that the passages come from your client's documents, because Subsidia did not see those documents. Say so in your own product copy; the report already does. Details in Le Vérificateur.

A key with the reflex scope can create, edit, run and follow flows. Three things stay with a signed-in person on purpose: deciding an approval, registering notification channels and connections (they hold credentials), and switching on unattended outbound sending. An outbound step (an email, a POST to a service) therefore always waits for a person, unless a person has allowed that flow to run unattended.

To let a flow call a client's software, a person registers the service once in the app (Reflex, Connections) with its base URL and credential headers. The stored values are never shown again and a step can only supply a path, so a flow cannot send the credentials anywhere else. In the cloud, private addresses and redirects are refused.

Read GET /engine/approvals and push approvals to your own notification tooling with the flow.approval.requested webhook. The scheduler itself runs on on-premise installations, not in the cloud.

Instead of polling, subscribe to source.ingested, source.failed, knowledge.contradiction_detected, knowledge.stale, flow.run.finished and flow.approval.requested. Payloads carry identifiers and status, never document or answer content. A failed delivery is retried three times quickly, then after 5 minutes, 30 minutes, 2 hours and 12 hours. Signature checking, the delivery log and replay are in Webhooks. In the cloud, webhook URLs must be public addresses.

For clients who want Subsidia on their own machine, sign the desktop app in with your partner account and pick the client's workspace. The machine is paired and appears in GET /partner/devices. It renews its certificate daily and keeps working offline for the certificate's lifetime; the state reads offline after 3 days without contact and expiring shortly before the offline tolerance ends. A machine whose version is behind the latest release is flagged.

Who is who. The client is the data controller. You, the integrator, are its processor: you design and operate the application. Protypa, which publishes, hosts and administers Subsidia, is your sub-processor, and the sub-processor relationship is to be covered in the data processing agreement between you and the client.

Where data goes. Documents, conversations, accounts, journals and certificates are stored in France on hosted servers administered by Protypa. On each question, names, emails, phone numbers, addresses and IBANs are replaced by aliases before anything is sent to an external model provider, and the answer is restored in clear for the user. Each client has its own list of authorised model providers; to keep every question inside the European Union, authorise only an EU provider or run a local model on a dedicated machine. A question sent to an authorised provider is processed by that provider after masking.

What Subsidia can prove and control.

• One signed certificate per answer, chained to the previous one, with fingerprints only and no plain content. It can be verified offline without trusting Protypa.
• Isolation per client workspace, and dossiers that can be reserved to named people.
• An access journal: who consulted what, with human reads and AI reads distinguished.
• The AI Act usage register, exportable and signed (Le Registre).
• Access keys per client, with a ceiling, revocable immediately; a client can be suspended and restored.
• No automatic outbound sending (email, message, service call) without a person's approval, enforced by the engine rather than left to the model.

What Subsidia does not claim.

• No certification (ISO 27001, SOC 2, HDS) and no independent penetration test to date.
• Masking greatly reduces the risk of using an external provider; it is not anonymisation in the GDPR sense.
• French hosting covers stored data, not the processing a provider does on a masked question you chose to authorise.
• Subsidia does not sell data, does not train models on clients' data and claims no right over it or over your tools.

Transparency to the client's staff. A client workspace is owned by you. Every member sees a notice that you run it and can reach its documents, its access journal and its keys, and a client administrator can acknowledge that notice. The acknowledgement is visible to you in the client list (managedAckAt in GET /partner/clients). Do not rely on this being invisible: a client team that finds out later will not trust the rest.