API Client Log

The API client log records calls made against the platform's API — who called, what they asked for, and what happened.

Where to find it

Architect Panel → Activity:

• Activity Log — the data changes an API call caused
• Record Read Log — reads, where the datastore has read auditing on

Architect Panel → Integration & Connections:

• API Clients — the clients whose calls appear here
• API Server — the server configuration
• OpenAPI Specification — what the API exposes

What a call records

• Client — which API key made the call.
• Method and datastore — what was asked for.
• Scope — the access the call was made under.
• Status and outcome — how it ended.
• Rows returned.
• Duration in milliseconds.
• IP address and user agent.
• Request digest — a fingerprint of the request.
• Message — detail where something went wrong.

One client per integration

This log is only as useful as your client naming. Five integrations sharing one key produce a log in which every question ends with "but which system was that?".

Separate clients mean you can see one integration's behaviour, revoke it without affecting the others, and hold each to its own scope. It costs nothing to do and cannot be retrofitted to historical entries.

Row counts show intent

An integration fetching a handful of records per call is doing lookups. The same client returning tens of thousands is extracting your database.

Both are legitimate in the right context, but they are different activities, and the row count is what distinguishes them. A change in that pattern — a client that fetched fives now fetching thousands — is worth a question even when every call succeeded.

Duration is your early warning

Durations creeping up over weeks mean a query is outgrowing its data. This is visible here long before anybody reports slowness, because integrations tolerate delays that people would complain about.

Watch the trend rather than individual calls; a single slow call is noise.

Failures in a row mean something changed

Scattered failures are normal. A client failing consistently from a particular moment means something changed — an expired credential, a revoked scope, a caller updated at the other end. The message field usually says which.

Authentication failures deserve particular attention: repeated failures from an unfamiliar address are somebody trying keys.

What it does not record

This log describes the calls. What a call changed is in the Activity Log, and what it read is in the Record Read Log where that datastore has read auditing enabled. An investigation into API activity usually needs at least two of the three.

Housekeeping

API logs grow quickly on a busy integration. There is a scheduled housekeeping task for this — enable it, and set a retention that keeps enough history to see a trend.

Worked example

A partner integration starts failing every call at 09:15 on a Tuesday, with an authentication message. Their client credential had been rotated at their end without telling anybody. Because each partner has their own client, the fault was visibly confined to one integration, and the other six were provably unaffected — which was the first question asked.

Recommendations

• One API client per integration, always.
• Watch row counts for changes in pattern, not just for errors.
• Track duration trends as an early warning.
• Enable API log housekeeping and set retention deliberately.