The buyer activity feed surfaces meaningful mutations across your workspace — CREATE, UPDATE, DELETE, ARCHIVE, and EXECUTE actions on advertisers, campaigns, creatives, media buys, products, and packages — along with the actor that performed them (a human user or a service token / agent) and the time the change was recorded.Use audit logs for:
Compliance — produce a tamper-evident trail of who changed what and when across multi-tenant workspaces.
Debugging — reconstruct the sequence of events around a campaign that suddenly stopped pacing or a creative that flipped to rejected.
Post-incident analysis — answer “what changed in the last hour?” and “did this agent touch anything it wasn’t supposed to?”.
Operational visibility — feed the data into a SIEM, a Slack channel, or your own dashboard.
Audit logs are scoped to your customer (the buyer organization). Each row identifies the actor (userId + userEmail for humans, serviceTokenId + serviceTokenName for agents), the resource (resourceType + resourceId + resourceName), the action, and the parameters or field-level changes that drove it.
All endpoints below are mounted under https://api.agentic.scope3.com/api/buyer/. The activity feed is the REST fallback that powers the in-app activity view; agents and external systems can poll it directly.
resourceTypes accepts either a comma-separated value (?resourceTypes=CAMPAIGN,CREATIVE) or repeated query params (?resourceTypes=CAMPAIGN&resourceTypes=CREATIVE). The default is the full set of buyer resource types.
The feed always restricts to meaningful actions — CREATE, UPDATE, DELETE, ARCHIVE, EXECUTE. Read-only operations (GET / list calls) are not surfaced.
Scope to a campaign and inspect the actor on each row. The campaignId filter matches both the campaign itself and its descendants (media buys, etc.) so you see the full activity tree.
Pagination — the endpoint orders by timestamp DESC. Page with skip + take; for large back-fills, iterate by time window (endDate of one page becomes startDate of the next) instead of paging deep into a single window.
Polling cadence — for live tailing, poll once per minute and use startDate set to the most recent timestamp you’ve already ingested. Do not poll faster than once per 30 seconds.
Retention — audit rows are retained for the standard customer retention window. Archive rows you need long-term to your own warehouse.
Pagination ceiling — take is capped at 500. For larger exports, iterate by time window.
Idempotency — id is stable per row, so client-side dedupe on id is safe across overlapping polls.
Don’t rely on actions filtering at the API — the activity feed always restricts to meaningful actions; filter further client-side if you need to (e.g. only DELETE).
List buyer activity, with optional filters and pagination
Query parameters: startDate, endDate, advertiserId, campaignId, resourceTypes, take (default 50, max 500), skip (default 0).Response: { data: { logs: BuyerAuditLog[], total: number }, meta: { pagination: { skip, take, total, returned } } }.See the OpenAPI spec for the full BuyerAuditLog shape: API Reference.
