> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Activity Logs
> Activity logs record every API-driven change in TWICE Commerce — what was changed, by which user, API key or system, and when.
## Definition
The **Activity Log** is the immutable record of every authenticated API request that touched your account. Each row corresponds to a single request — its actor, the endpoint that was hit, the resource it affected, and the response that came back.
Because every action in the admin ultimately calls the same API your integrations use, the Activity Log captures human work, API-key calls, and system jobs in the same stream.
**Audit logs** are available on the **Standard** plan (3 months of history) and the **Enterprise** plan (36 months). See [plans](/docs/twice-commerce-overview#pricing).
## Where Activity Logs appear
| Surface | What it shows |
| :-------------------------------- | :------------------------------------------------------------------------- |
| **Account-level Activity Log** | Every request across the whole account, accessible from the top navigation |
| **Stock Item > Activity log tab** | Requests whose `affectedRecords` include that Stock Item |
| **SKU > Activity log tab** | Requests scoped to that SKU |
| **Listing > Activity log tab** | Requests against that Listing (catalog item) |
| **Customer > Activity log tab** | Requests against that Customer |
| **Order > Activity log tab** | Requests against that Order |
The per-entity tabs are the same table component as the account-level view, pre-filtered to the entity ID.
**Why an API-shaped log?** Every admin action is also an API call. Logging at the request boundary catches anything that mutates state — keyboard, API integration, scheduled job — in one place, with no gaps to bridge.
## What gets logged
A log entry is written for every authenticated request that hits the server. Each entry records both the inbound request and the response that came back.
| Column | Source | Description |
| :---------------- | :----------------- | :--------------------------------------------------------------------------------- |
| **Timestamp** | Server | Exact time the request was received |
| **Action** | HTTP method | `GET` -> Read, `POST` -> Create, `PUT` / `PATCH` -> Update, `DELETE` -> Delete |
| **Resource type** | Route metadata | The kind of resource being touched (Article, Order, Customer, etc.) |
| **Record ID** | Request / response | The ID of the affected record (linked to its detail page where one exists) |
| **Actor** | Auth credential | The user (email), API key (label), or system (name) that authenticated the request |
| **Endpoint** | Request URL | The API path that was called, with query string stripped |
| **Status** | Response | HTTP status code, color-coded — success vs. error |
### Actor types
Three actor types appear in the log:
| Actor | Renders as | Notes |
| :-------- | :--------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- |
| User | `jordan@yourstore.com` | Authenticated via user JWT — a human action through the admin |
| API key | `API: Mobile app` | Authenticated via an [API key](/docs/concepts/integrations/overview#api-keys) — the label is the one set when the key was created |
| System | `System: scheduler:daily-pricing-update` | An internal job acting on the tenant's behalf |
| Untracked | `Untracked` | Request hit the server with no recognised credential — investigate, don't ignore |
### Recognised resource types
The Resource type column shows a friendly label per resource. The current set includes:
Article (Stock Item), Article ledger, Audit log, Auth, Catalog, Change history, Checkout link, Collection, Customer, Event, File, Inventory report, Order, Payment, Payment account, Pricing table, Report, Saved table view, Search, Service location, SKU, Storefront customization, Tag, Tax, Taxonomy, Tenant, Unavailability, Upload URL, User, Variant.
When a request affects a resource type with a detail page (Article, Catalog, Collection, Customer, Order, SKU), the Record ID column renders as a link.
## Filters and search
The table can be filtered server-side on:
| Field | Supported operators |
| :------------ | :----------------------------------------------------- |
| Timestamp | `is`, `after`, `on or after`, `before`, `on or before` |
| Action | `is`, `is any of` |
| Resource type | `equals`, `is any of` |
| Actor | `equals`, `is any of` (matches the user's email) |
| Endpoint | `contains` (substring match) |
Filtering by Record ID isn't a direct column filter — the per-entity Activity Log tabs handle that by pre-applying the affected-record filter.
The filter operators that surface in the UI match what the audit-logs backend can answer efficiently — additional operators are intentionally hidden rather than silently ignored.
## Immutability
Once written, log entries cannot be modified or deleted from the admin. The Activity Log is append-only by design — that's what makes it usable for after-the-fact audit and incident review.
## Retention
Activity Log entries are stored in BigQuery and surfaced through the API. Retention scales with your pricing plan:
| Plan | Retention |
| :--------- | :--------------------------- |
| Discover | 7 days |
| Build | 30 days |
| Advance | 1 year |
| Enterprise | Custom — typically unlimited |
For longer-term archival, export the log to CSV from the table (the export honors the current filter set) and keep the file in your own storage.
Read more: [TWICE pricing](https://www.twicecommerce.com/pricing)
## Rate limits
Reading the Activity Log issues a BigQuery query per page. The endpoint is rate-limited per IP, per tenant, and globally to keep cost and noisy clients in check. In practice this means:
* \~1 request per second sustained per IP, with a small burst
* \~2 requests per second sustained per tenant
* Exceeding the limit blocks the caller for 5 minutes
This rarely matters in the UI but is worth knowing if you script against the audit-logs endpoint.
## API access
The same data the UI shows is available over the API.
Pagination is cursor-based. Combine `resourceTypes`, `affectedRecords`, `methods`, `userEmails`, `urls`, and `statusCodes` to scope the query — operators map 1:1 to the UI filters described above.
## Activity Log vs. Events
Activity Log and [Events](/docs/concepts/inventory/events) sit next to each other and are easy to confuse:
| | Activity Log | Events |
| :------- | :---------------------------------------- | :------------------------------------------------------------------------- |
| What | API requests on the account | Order milestones (reservations, pickups, returns, notes) tied to inventory |
| When | Always historical — records what happened | Can be in the past or scheduled in the future |
| Source | Server-side request log | Inventory and order lifecycle |
| Mutable? | No | Some attributes editable until the event fires |
| Use | Audit, debugging, attribution | Operational planning and timelines |
Use the Activity Log when you need to answer "who changed this and when". Use Events when you need to plan or display "what's happening to this Stock Item across time".
## Developer Reference
Activity logs are exposed as `audit-logs` in the API.
Open the endpoint in the API reference.
## Related
Inventory-side timeline of reservations, pickups, returns and notes
API keys and webhook subscriptions — both appear as actors in the Activity Log
Push events from TWICE to your systems
Who can see the Activity Log and which scopes they can filter on