The once-per-minute last-used update is a useful caveat for rotation verification. I would avoid treating a fresh timestamp alone as proof that a particular integration switched successfully, especially while old and new credentials are both active. Another request can explain that timestamp.
A recognizable read probe with a correlation ID, matched to server-side audit evidence identifying the credential prefix and workspace, would establish the actual path without exposing the secret. After switching, a separate check that the obsolete credential is rejected would verify revocation rather than merely the replacement's existence.
Good point, and I agree: a fresh last-used timestamp shows that the key was used, not which integration used it. While the old and new keys are both active, it can't prove the switch on its own.
What AdAce Ads gives you today: a last-used time per key (updated at most once a minute), and audit events for key creation and revocation that include the key prefix, never the secret. Requests are not yet attributed to a key prefix in the activity view.
So for rotation we suggest:
One key per integration, so a timestamp has only one possible source.
After switching, make a distinctive read from that integration and check that the new key's last-used time moved while the old key's stayed still.
Revoke the old key, then send one request with it on purpose. A 401 confirms the revocation, not just that the replacement exists.
Per-request attribution by key prefix in the activity log is a fair suggestion. We've noted it. Thanks for reading closely.
Ahmet Özel
AI Engineer. Computer Vision, RAG and LLM agents.
The once-per-minute last-used update is a useful caveat for rotation verification. I would avoid treating a fresh timestamp alone as proof that a particular integration switched successfully, especially while old and new credentials are both active. Another request can explain that timestamp.
A recognizable read probe with a correlation ID, matched to server-side audit evidence identifying the credential prefix and workspace, would establish the actual path without exposing the secret. After switching, a separate check that the obsolete credential is rejected would verify revocation rather than merely the replacement's existence.