A request log with the prompt left out

The first time a model request fails, it is tempting to record everything: the prompt, the response, the headers, and the error. That can make one problem easier to inspect. It can also leave private conversations and API keys sitting in a log long after the problem is fixed.

A useful starting point is simple: record what happened to the request, and leave its contents out of routine logs. You can learn a great deal about reliability and usage without keeping a copy of every conversation.

Start with a small request record. For each call, record a timestamp, an identifier generated by your application, the requested model, the outcome, and the elapsed time. When the response provides token usage, record those counts too. If a provider returns a request identifier, it can help connect your investigation with a support request.

For example, a record might tell you that a request for Gemini 2.5 Flash succeeded, took 1.8 seconds, and used the input and output token counts reported in the response. That is enough to begin tracking latency, errors, and usage without storing the question someone asked.

Keep the record consistent across your application. With Vana API, requests can use the OpenAI-compatible endpoint at https://api.vanaapi.com, Anthropic Messages, or Gemini native protocols. Response shapes can differ, so translate the fields you need into a small, consistent log format. Treat missing usage as unknown rather than recording zero.

Decide explicitly which fields are allowed. Copying an entire request object and removing a few sensitive fields is fragile. A library update or a new feature can introduce another field that contains private data. Building a log record from a short list of approved fields makes the boundary easier to understand.

• Keep operational details such as duration, status, token counts, and a safe error category.
• Exclude authorization headers, API keys, cookies, and credentials embedded in URLs.
• Leave prompts, model responses, uploaded files, and tool arguments out by default.
• Use an internal identifier when you need to connect events, and consider whether that identifier still reveals a person.

Error handling deserves particular attention. An error message may repeat part of a request or include an upstream response body. Sending the whole exception to your logging service can undo the care you took elsewhere. Prefer a known error code or a short, sanitized description, and check what your SDK, web server, and monitoring tools capture automatically.

Count retries as separate attempts. One action in your application can produce several API calls if a connection fails or a rate limit triggers a retry. Give each attempt its own record and connect them with a shared operation identifier. This helps explain both delays and usage. A timeout alone does not establish whether the upstream request ran or incurred a charge.

Vana API bills per real token with no monthly fee, so reported token usage is useful when investigating spending. Use your logs to spot changes and reconcile them with billing records. An estimated cost calculated in your application may miss pricing differences, caching details, or requests whose final usage never reached your client.

Make content capture an exception with an end date. Sometimes a bug depends on the actual text. First try reproducing it with invented data. If you need real content, define the purpose, limit collection to the smallest useful sample, restrict access, and set a short deletion period. Follow the consent and privacy requirements that apply to your application. Automated redaction can help, but it can miss sensitive details.

Finally, decide who can read logs and when they expire. Check whether exports and backups preserve copies beyond that period. Your application's logging settings also do not establish what an API service or upstream provider retains; review those policies separately.

If you are starting with Vana API, create an account and make a test request using invented text. Inspect the resulting logs before sending real user data, and confirm that they contain only the fields you intended to keep.