Shift note: seven privacy checks for an API relay

An API relay adds another service between your application and a model provider. That can simplify access, but it also adds questions about who receives your data and what happens afterward. Before sending customer records, source code, or internal documents, work through these seven checks. Record the answers, their source, and the date so the next person on duty can repeat the review.

Draw the request path before adding credentials

1. Ask which organizations receive each part of a request. Map your application, the relay, the upstream model provider, and any services involved in logging, monitoring, or support. Include prompts, attachments, responses, account identifiers, and request metadata.

Ask whether the relay terminates encrypted connections and processes readable content. Encryption in transit does not, by itself, prevent an intermediary from reading a request. Obtain a written explanation of the data path rather than assuming that a forwarding service cannot inspect content.

Separate content logs from billing records

2. Ask exactly what the relay records. “We keep logs” is not specific enough: logs might contain only timestamps and token counts, or they might include complete prompts and responses. Ask about error traces, abuse investigations, and temporary diagnostic logging too.

Request separate retention periods for content, operational metadata, billing records, and backups. If logging can be disabled, confirm which categories the setting covers and whether it applies to your account, project, or individual request.

Check upstream rules for the route you will use

3. Ask which upstream provider processes your selected model and which data-use terms apply. For example, if you plan to request Claude Haiku 4.5, confirm the actual processing arrangement rather than treating the model name as proof of a particular privacy policy.

Ask whether prompts or responses may be used for training, evaluation, or abuse monitoring at either layer. Also ask whether retries, fallback routes, or provider substitutions can change the recipient. A relay’s own commitments do not automatically describe every upstream arrangement.

Confirm processing locations and contract coverage

4. Ask where request content, logs, and backups are processed or stored. If your organization has regional restrictions, find out whether routing is pinned to a region or can move during an incident. An available endpoint location does not necessarily establish the location of every processing step.

For personal or regulated data, request the applicable data processing agreement and subprocessor information. Have your privacy or legal owner review them. A newcomer should gather the evidence, not independently decide that a service meets every legal obligation.

Identify who can inspect requests and change access

5. Ask which employees, contractors, and support staff can access request content, under what circumstances, and whether those accesses are recorded. Check your side too: who can view usage, create keys, export logs, or invite colleagues?

Use separate credentials for development and production where supported. Keep keys out of repositories and prompts. When using coding tools, inspect what they send: repository files, terminal output, and configuration files can contain sensitive material even when your typed prompt does not.

Rehearse deletion and incident handling with dummy data

6. Send a synthetic request containing no real secrets, then walk through the available usage views and support process. Ask how to request deletion, which records it covers, how backups are handled, and what exceptions apply. A request disappearing from a dashboard is not evidence that every retained copy has been deleted.

Find the security contact and ask how customers are notified of incidents. Keep this contact alongside your key-revocation procedure so an on-call engineer can act without searching through marketing pages.

Approve a limited relay trial before production traffic

7. Relay365 is worth considering when you want pay-as-you-go access to multiple model families through tools such as Claude Code, Codex, Gemini CLI, or an OpenAI SDK. That convenience is a reason to evaluate it, not evidence of particular privacy controls.

If that setup fits your workflow, create a Relay365 account and begin with synthetic data. Keep sensitive traffic out until the relevant questions above have documented answers. Close the review with a clear decision: approved data types, permitted routes, unresolved questions, and the person responsible for checking again when terms or routing change.