SYNDERESIS / API OPERATE
Hosted customer API · Contract reviewed 7 November 2026
Security, privacy and data handling
On this page
Keep your integration's access, logs and retention deliberate. This page describes the reviewed customer API handlers and separates their application behavior from hosting and model-provider arrangements.
Read the Privacy & GDPR Notice and obtain the processing terms relevant to your deployment before sending sensitive or regulated information.
Transport and access
Use the canonical HTTPS endpoint. Keep customer API keys in server-side secret storage. The implementation stores hashes of customer API keys and browser credentials; key creation returns the complete customer key once.
The native API applies no-store response headers and request correlation. Browser sessions use secure cookies and CSRF controls for mutations. Customer keys do not confer the session-only authority needed to manage all account keys.
CORS is not enabled for the documented customer API. Put your own authenticated backend between a browser/mobile client and Synderesis. CORS is a browser behavior, not a substitute for authorising your own users.
Application data flows
| Data | Reviewed application behavior | Integration implication |
|---|---|---|
| API request messages and answer text | The documented native completion handlers pass content to configured generation infrastructure and do not create a server conversation-history record. | Send the transcript needed for each call. Your own application may retain its own copy. |
| Retrieved passages | Passed as request context and, for answers/search, returned to the caller. | Treat passages as source material; verify attribution and licensing for redistribution. |
| Tool definitions and results | Supplied by the caller and passed through the transcript interface. Client functions execute in your application. | Send the minimum useful data and enforce your own function permissions. |
| Usage and quota records | Account ID, key prefix, endpoint, model attribution, token counts, status and accounting/reservation metadata are recorded. | Stateless conversation handling does not mean no operational records exist. |
| Profile and key metadata | Retained for account access, lifecycle and service operation. | Profile reads contain personal data; restrict and avoid unnecessary logging. |
| Provider and infrastructure processing | Governed by the configured route and applicable provider/hosting arrangements. | Application behavior alone does not establish provider retention or training-use terms. |
The store parameter does not enable a stored-conversation API in the documented transcript handler. Do not send private material on the assumption that store=false overrides infrastructure logs or a provider's policy.
Logging and observability
Log request ID, endpoint, HTTP status, latency, model alias and usage where needed. Redact Authorization, X-API-Key, cookies and any application secrets. Avoid recording prompts, source passages, responses, tool arguments/results or personal profile data by default.
The reviewed request-validation logging is metadata-oriented. Separately enabled operational question/answer improvement logging has different retention implications; verify deployment settings rather than assuming it is always disabled.
Your own monitoring, reverse proxy, SDK debug mode and error reporting can create additional content copies. Review those components as part of your integration.
Storage and retention
The published privacy notice describes account/usage retention, content categories, deletion, infrastructure logs and independent provider retention. It generally describes security/infrastructure logs as normally retained for no more than 30 days, with stated incident/legal exceptions. Provider retention and backups follow their separate arrangements.
Do not interpret that policy period as a universal 30-day limit on every item, or as zero data retention. The documented handlers' lack of a conversation-history write does not control copies in your application or upstream services.
Before production, establish these details for the selected service:
- Controller/processor roles and the applicable processing agreement.
- Hosting/model subprocessors and processing locations.
- Whether provider input/output can be retained or used for training.
- Log categories, retention periods and incident exceptions.
- Backup retention and deletion propagation.
- Access controls, audit access and incident contact arrangements.
These are deployment and contractual facts. The code alone cannot verify all of them.
Account deletion
Use the self-service Account deletion flow. The implementation fences access and revokes credentials as deletion begins, with remote cleanup work able to remain pending. The privacy notice explains remaining operational/legal records and third-party retention.
Deletion of a Synderesis account does not delete copies you stored in your own application, exported files or independently retained provider records. Provide your users with a clear description of your application's own retention and deletion process.
Deployment boundaries
An EU company or a Frankfurt application function is not proof that all inference, logs and network processing stay in the EU. Model routes and private deployment arrangements can differ.
For a deployment that requires a specific retrained checkpoint, private infrastructure, residency constraints, offline operation or a dedicated isolation boundary, obtain an explicit verified arrangement. This API guide does not grant those properties to the standard hosted endpoint.
Source and answer handling
Treat user prompts, retrieved text and tool results as untrusted input. Render model output safely, validate tool arguments and keep consequential decisions under the appropriate human/application authority.
Catholic alignment describes the model's intended direction. It does not guarantee that every response or citation is correct. The native answer metadata describes retrieved context; it does not establish a fully validated structured doctrinal answer.