Public records requests and integration logs: what should be in them
Integration logs can quietly become records you have to search, review and produce. What tends to end up in them, how to keep them lean, and how to respond when a request names them.
When a public records request arrives, the clerk's office searches the places records live: email, the document system, the permit system, shared drives. Integration logs are rarely on that list. They should be, because they can hold far more than anyone expects.
This post looks at what ends up in integration logs, why it matters for requests, and how to keep those logs useful without turning them into a second records system. It is general guidance, not legal advice. Your state's law and your counsel decide what counts as a record.
What integration logs tend to hold
Every integration tool keeps some kind of log. The question is what is in it. Common contents include:
- Run details: when it ran, how long it took, and whether it worked.
- Counts: how many records were read, written, skipped or failed.
- Record IDs: which permit, request or payment was moved.
- Error messages: what went wrong, often including part of the record.
- Request and response bodies: the full contents of each API call, kept for debugging.
The first three are metadata. The last two can contain names, addresses, phone numbers, complaint text and payment details.
Why it matters for a request
More places to search
If integration logs contain record contents, they may be responsive to a request about a person, an address or a case. Staff then have to search them, which means knowing they exist and having a way to search them.
More to review and redact
Raw API bodies are hard to read and hard to redact. A single log entry might hold a resident's name, an officer's notes and a payment reference in one blob of text.
Inconsistent retention
The source system follows your retention schedule. A log that keeps full copies may follow none, so records you have properly destroyed in the source could still sit in a debug log.
Keep the logs lean
The simplest approach is to keep record contents out of integration logs entirely. A lean log still answers the operational questions:
| Question | Answered by |
|---|---|
| Did the nightly permit sync run? | Run time and status |
| How many records moved? | Counts per step |
| Did permit B-2041 reach the GIS layer? | Record IDs on each side |
| Why did a record fail? | Error text with personal details masked |
None of that needs the permit applicant's name.
Practical steps
- Turn off request and response body logging in production, or limit it to short, deliberate debugging windows.
- Mask email addresses and phone numbers in error text.
- Log IDs, not values, when tracing records.
- Delete debug exports and spreadsheets when the problem is fixed.
Know what you do keep
Even a lean integration platform keeps some records of its own: run history, an activity log of who changed what, and, if you use AI features, a log of those calls. These may well be records under your law.
Write them into your inventory:
- What it is: for example, "run history for integration flows".
- What it contains: counts, timings, record IDs and masked errors.
- How long it is kept: and who set that period.
- How to export it: in a format your office can review.
When a request names the integration
Sometimes the request is about the integration itself: "all records showing when permit data was sent to the county", or "logs of changes to the payment interface". Be ready to answer three kinds of question.
- What happened to a record? Trace it by ID across runs.
- Who changed the flow, and when? The activity log and version history.
- What did the flow do? A plain-language description of each step.
If the platform can export these with a checksum, your office can show the export wasn't altered after it was made.
A short checklist for your records manager
- Is every integration platform listed in our records inventory?
- Do its logs contain record contents, or only metadata?
- Is its retention period set deliberately, and documented?
- Can we place a legal hold on it?
- Can we export what it keeps for a request, quickly?
How SentraBridge handles it
SentraBridge doesn't keep the records it moves, so there are no record contents in its logs to search. Run history keeps counts, timings, record IDs and error text with emails and phone numbers masked. Retention is set per workspace, a legal hold stops removal, and one export bundles everything kept for a request, with checksums. See the security page and monitoring for details.