Pylon Audit Logs

Pylon is a customer support platform for B2B teams, handling support conversations across Slack, Microsoft Teams, email, and in-app chat. Its audit log records who did what across your Pylon organization — authentication, user and team management, API token creation and revocation, issue and account changes, organization settings modifications, and SLA breaches. These logs help security and compliance teams maintain audit trails and build detections on support-tool access.

Setup

Pylon supports API polling to collect audit log events from your organization via the audit log endpoint (GET /audit-logs).

1. Go to Sources in RunReveal
2. Click the Pylon source tile
3. Give it a name
4. Fill in your API Token
5. Click Connect Source

Authentication

RunReveal authenticates to Pylon with a bearer API token.

1. Sign in to Pylon as an admin
2. Go to Settings > Developer > API Tokens
3. Generate a token and copy it into RunReveal

Collected Events

Each entry names the action performed, which RunReveal stores in the eventName field.

Observed action names on a live tenant, most frequent first:

The vocabulary is open-ended and issue/ticket lifecycle events dominate in practice. Pylon also emits authentication, user and team management, API token, account, and organization settings events.

Event Data Structure

Each audit event includes:

• Event ID and Action — Unique identifier (id) and the action performed (action)
• Timestamps — When the action happened (action_happened_at) and when the record was written (created_at), both RFC 3339
• Actor Information — Either actor_user_id (a Pylon teammate) or actor_contact_id (an end customer). System-driven actions carry neither, and are the majority: on a 19.5k-record sample the split was 70% system, 18% teammate, 12% contact.
• Object — The type and ID of what was acted on (object_type, object_id), plus a link to it in Pylon when applicable
• Attributes and Metadata — Key-value attributes and an action-specific metadata object, preserved verbatim in rawLog

Data Collection

• Collection Method: API polling every 5 minutes
• Ordering: Pylon returns audit logs newest-first and its pagination cursor walks backward into history. This is not documented — the API reference specifies no ordering and offers no sort parameter — but it is what a live tenant returns. Only the backfill walk depends on it; incremental collection uses a server-side time filter instead.
• Incremental collection: Each poll asks POST /audit-logs/search for everything after the last timestamp it saw, so new events are always collected regardless of ordering. A persisted cursor is deliberately not used as the resume point: following one marches into the past and never revisits the top, which silently stops collection. The filter is inclusive and timestamps have second granularity, so RunReveal also tracks the IDs seen at the boundary second to avoid redelivering them.
• Backfill: History that pre-dates the connection is drained separately, walking backward in bounded batches across polling cycles until Pylon reports no further pages. A large history takes several cycles to catch up.
• Rate Limits: A 429 response is honored via the X-Retry-After header and retried rather than failing the poll.
• Intermittent slow pages: Requests occasionally take 40-100 seconds before returning a normal 200, against a typical page time of about a second. This is not rate limiting — Pylon reports 299 of 300 requests remaining throughout, and the slow pages appear at the start of a burst rather than after sustained traffic. Nor is it a cold start: bursts after both 100 seconds and 6 minutes of quiet returned in about a second. The cause is unknown and appears to be sporadic on Pylon's side. Pages are individually time-bounded and a cycle that runs long commits what it drained and resumes next poll, so a large backfill catches up over several cycles.
• Event Format: JSON with normalized fields for consistent querying

Verify It's Working

Once added the source logs should begin flowing within a few minutes.

You can validate we are receiving your logs by running the following SQL query.

SELECT * FROM runreveal.logs WHERE sourceType = 'pylon' LIMIT 1

Schema

The following columns are exposed for this source. RunReveal applies schema normalization across all sources, ensuring uniform field names and data types for cross-source queries and reusable detection logic.

Helpful Links

• Pylon Audit Logs API - Reference for the audit log endpoint
• Exporting Audit Logs to a SIEM - Pylon's guidance on pulling audit logs