Skip to main content

Activity logs

Activity logs provide a record of actions initiated within your organization, including actions performed through the UI, via the API, or triggered automatically by the system (e.g., automated billing operations).

Activity logs retention

Access to the activity log is limited to paid tiers:
  1. Free users do not have access to activity logs;
  2. Premium users can view activity logs for up to 30 days; and
  3. Enterprise customers with the appropriate paid add-on can access the full activity log history without time limits.

How to access activity logs

Only organization admins can access Activity Logs through the Developers Console. To view the logs:
  1. Click the Developers icon in the navigation sidebar;
  2. Select the Activity Logs tab; and
  3. View paginated activity logs directly in this section.
The Activity logs tab of the Developers Console, with a paginated list of activities

Activity logs in the Developers Console

Activity log details

Each activity log includes a set of properties that provide context about the recorded action:
  • Type: The name of the activity (e.g., plan.updated, customer.created, invoice.drafted);
  • Description: A brief explanation of the activity;
  • Activity ID: A unique identifier for the activity log entry;
  • Resource Type: The type of object affected (e.g., Wallet, Invoice, Customer);
  • Resource ID: The identifier of the impacted resource (e.g., invoice_id, customer_id);
  • Customer External ID: Identifies the customer related to the activity;
  • Subscription External ID: Identifies the subscription related to the activity;
  • Log Date: The timestamp of the activity;
  • User: The organization member who triggered the activity; and
  • Source: Indicates the origin of the action.
    • front – triggered from the UI
    • api – triggered from the API
    • system – triggered automatically by the system (e.g., billing)
In addition to the above, the Activity Payload section provides contextual data:
  • Changes: Details of modified data (available for update actions only); and
  • New Object: The full payload of the newly created object.

Filtering activity logs

You can filter activity logs, either through the UI or via the API, on the log date (from_date and to_date), the activity type (activity_types), the source (activity_sources), the user (user_emails), the customer (external_customer_id), the subscription (external_subscription_id), the resource (resource_ids) and the resource type (resource_types).

Activity logs per object

In the UI, you can view activity logs for a specific object by clicking on the desired object (e.g., a specific customer, plan, invoice, etc.), and access the Activity Logs tab.

API logs

API logs offer a comprehensive record of all API requests and calls made within your organization. They serve as an essential tool for monitoring activity, troubleshooting issues, and auditing system usage.

API logs limitations

  1. Operation scope: Only POST, PUT, PATCH, and DELETE requests are currently recorded in the API logs. All GET requests are excluded at this time.
  2. Excluded endpoints: API calls related to metering and high-throughput ingestion, such as POST /api/v1/events or POST /api/v1/events/batch, are intentionally omitted from logging to ensure performance and scalability.

API logs retention

Access to the API requests logs is limited to paid tiers:
  1. Free users do not have access to API logs;
  2. Premium users can view API logs for up to 30 days; and
  3. Enterprise customers with the appropriate paid add-on can access the full API log history without time limits.

How to access API logs

Only organization admins can access API Logs through the Developers Console. To view the logs:
  1. Click the Developers icon in the navigation sidebar;
  2. Select the API Logs tab; and
  3. View paginated API logs directly in this section.
The API logs tab of the Developers Console, with a paginated list of API requests

API logs in the Developers Console

API log details

Each API log includes a set of properties that provide context about the recorded action:
  • Endpoint: The API endpoint that was called;
  • Request ID: A unique identifier for the request;
  • Request Method: The HTTP method used for the request (e.g., POST, PUT, DELETE);
  • API key: The API key used for the request;
  • API version: The API version used for the request;
  • Origin: The origin URL of the request;
  • Client: The SDK or Client used for the request (e.g., RubySDK, PythonSDK or PostmanRuntime/7.44.1); and
  • HTTP status code: The HTTP status code of the response (e.g., 200, 400, 404).
In addition to the above, the Event Payload section provides contextual data:
  • Request Body: The payload of the request; and
  • Response Body: The payload of the response.

Filtering API logs

You can filter API logs, either through the UI or programmatically via the API, on the log date (from_date and to_date), the request method (http_methods), the HTTP status code (http_statuses), the API version (api_version), the endpoint path (request_paths) and the client (clients). Here are some key filtering behaviors to note: Exact Path Matching: Supplying a full, exact path (e.g., /api/v1/customers) will return only requests made to that specific endpoint. It will not include requests to extended paths like /api/v1/customers/123. Wildcard Path Matching: You can use wildcard patterns (e.g., /api/v1/customers/*) to match all sub-paths related to a resource. This is useful for retrieving all activity tied to specific objects or nested routes.