Account activity history: 5 rules for renewal research

The five rules governing availability, processing, and generation of activity records across four tools define the boundaries for renewal research.

• Verify ticket update timing and confirm the export is an incremental ticket export before you treat a missing ticket as inactivity.
• For events older than 5 days, use the import endpoint, and give a newly imported or changed event older than 30 days 12 hours before you call it missing from a cohort.
• If a listed billing event is older than 90 days, treat that gap as the archive boundary.
• For a selection-required event, confirm a listener is set for that event type rather than for every event.
• Record the tool, the history window, and the limit that applies before you judge the renewal.

These rules prevent missing records from being misinterpreted as customer inactivity. Each tool operates under distinct technical constraints that dictate when data becomes visible and how it must be retrieved.

Paddle’s List events API returns a paginated list of events that have occurred in the last 90 days, according to Paddle. This window defines the maximum historical depth available through standard event listing. Events older than 90 days aren't retained in this specific archive, according to Paddle. Consequently, any renewal investigation requiring activity data older than this ninety-day boundary cannot rely on Paddle’s standard event listing endpoint.

Zendesk defines specific availability windows for ticket updates and restricts cursor-based incremental exports to ticket data. Mixpanel enforces validation windows for recent events and directs older historical data to a separate import process with delayed cohort processing. Stripe renders event data based on the API version at event creation and requires specific listener configurations for selection-required event types.

These five rules collectively establish the technical limits for retrieving account activity history. They clarify that data absence often reflects system architecture rather than user behavior. Understanding these constraints allows customer success managers to verify data integrity before drawing conclusions about account health. Related steps sit in Customer data sync: 4 steps for account activity feeds.

When checking ticket activity for a renewal, the timing of data availability depends on the specific volume and export method used within the Tickets API. Most ticket updates are available within 30 seconds and the vast majority will be available within 90 seconds, according to Zendesk. If the count exceeds 100,000, it is updated every 24 hours, according to Zendesk. This distinction matters when a high-volume account shows a stale count; the 24-hour refresh cycle applies specifically when the count exceeds that threshold.

For retrieving historical data, the export mechanism follows a specific parameter sequence. The start_time parameter is used once to fetch the initial page of the initial export, then cursor is used for subsequent pages and exports, according to Zendesk. This two-step process ensures that the initial fetch establishes a baseline, while subsequent requests use the cursor to continue from that point. However, this mechanism has a strict scope limitation. The cursor parameter is only supported for incremental ticket exports, according to Zendesk.

If you are investigating missing records in a non-ticket export, do not assume the cursor mechanism applies. For other data types, you must rely on different retrieval methods or accept that the cursor-based pagination described here is not available. When preparing a renewal investigation, note whether your data source is a ticket export or another type. If it is a ticket export, you can use the start_time and cursor sequence. If it is not, the cursor parameter will not function as described.

Record the specific export type and the parameters used in your investigation notes. If you used start_time for the initial fetch and cursor for subsequent pages, document that sequence. If you attempted to use cursor on a non-ticket export and failed, note that the parameter is only supported for incremental ticket exports. This documentation helps distinguish between a data gap and a methodological error in your retrieval process.

Mixpanel SDKs: Javascript validates recent events through the /track API endpoint. Calling the .track() method triggers a request that validates for events with a timestamp within the last 5 days of the request, according to Mixpanel. Events falling outside this five-day window cannot be processed through the standard tracking method. For bulk import of historical events older than 5 days, the documentation specifies using the /import API endpoint, which is optimized for scripting and supports ingesting historical data, according to Mixpanel.

When you import or change historical events, processing delays affect cohort analysis. Newly imported or changed historical events timestamped more than 30 days ago might be part of your existing cohort analysis only after 12 hours from their import or change, according to Mixpanel. If you are investigating missing activity records for a renewal, check whether the missing events fall into the older-than-30-days category.

To verify if this delay affects your investigation, record the timestamp of the missing events. Compare that timestamp to the current date. If the events are more than 30 days old and were recently imported or changed, wait 12 hours before concluding they are missing, according to Mixpanel. If the events are within the last 5 days, use the /track endpoint validation rules, according to Mixpanel. If they are older than 5 days but not older than 30 days, verify the import status directly.

Do not assume that missing records in cohort analysis mean the customer stopped using the product. Use Account inactivity: 5 checks to choose your next task only after the cohort timing above is checked. Check the import logs to confirm when the historical data was processed. If the import occurred less than 12 hours ago, the records may simply be pending processing, according to Mixpanel. If the import occurred more than 12 hours ago and the records are still missing, investigate the import method. Ensure you used the /import endpoint for events older than 5 days, as the /track endpoint only validates timestamps within the last 5 days, according to Mixpanel.

Paddle’s List events endpoint returns a paginated list of events that have occurred in the last 90 days, according to Paddle. This 90-day boundary defines the maximum window for retrieving event history through this specific API method. If your renewal investigation requires activity data older than this period, the List events endpoint will not provide it.

When querying large datasets, the count returned by the endpoint depends on the number of matches. For datasets with 100,000 or fewer matches, the endpoint returns the exact count, according to Paddle. For datasets with more than 100,000 matches, it returns 100001 to indicate that more than 100,000 entities match, according to Paddle. A returned count of 100001 signals that the total volume exceeds the exact counting threshold, requiring you to acknowledge the data set is larger than 100,000 items without providing the precise figure.

Stripe handles event data rendering differently, focusing on version consistency. Each event data is rendered according to Stripe API version at its creation time, specified in event object api_version attribute (not according to your current Stripe API version or Stripe-Version header), according to Stripe. This means the structure of the data you retrieve reflects the API version active when the event was originally created, not the version you are currently using or specifying in your request headers.

Event generation in Stripe also follows specific listener rules. Stripe creates event types marked as Selection required only when at least one webhook is listening for it, according to Stripe. A webhook set to listen to all events doesn’t satisfy this requirement and won’t generate Selection required event types, according to Stripe. If you rely on a catch-all webhook to capture specific event types designated as Selection required, those events will not be generated. You must configure a webhook explicitly listening for those specific event types to ensure they are created and available for retrieval.

When investigating missing records, verify if the event type in question is marked as Selection required. If it is, confirm that a specific webhook listener exists for that event type, rather than relying on a general listener. For Paddle, check if the required activity falls within the 90-day retention window. These specific generation and retention rules explain why certain records may be absent or structured differently than expected during a renewal review.

The table below lists the documented retrieval, timing, and generation limits for each tool. Use it to match the specific constraint to the source you are investigating.

Check the source page linked in the table to verify the specific limitation applicable to your current investigation.

Suppose a renewal review asks whether one account was active. The reviewer splits the question into 4 checks and uses only round cutoffs already described above. Activity sought from day 95 sits past a 90-day list window, so the empty result matches that boundary. An event timestamped 40 days ago that was imported today is still inside a 12-hour wait, so the reviewer does not call it missing yet. A ticket update checked after 90 seconds can be read under the usual timing rule. A required event with no listener set for that event is treated as not generated. The reviewer logs which of the 4 checks applied and what the record showed.

When investigating missing activity for a renewal account, record the specific source tool used for each data point. Note the requested history window and the retrieval method applied. Identify the applicable documented limitation for that specific source. Keep the claim tied to this named source. Do not treat one publisher's rule as every firm's rule.

Also walk through Customer usage discrepancies: 4 steps before renewal.

Record the ticket count threshold observed during the investigation. Note the refresh interval associated with that threshold. Capture the specific URL where the rule is documented. List the retrieval method used to access the data. State the exact limitation that applies to the requested window.

Today, pick one missing record, name the tool you checked, and write the matching limit from the table before you decide the account is inactive.

What limits apply to account activity history?

Account activity history is governed by specific retrieval, timing, and event-generation rules rather than a single universal retention period. These limits include ticket update availability windows, incremental export cursor restrictions, historical event processing delays, event archive retention boundaries, and snapshot event generation exceptions. Each tool applies its own documented constraints to how records are stored, processed, and made available for review.

Does the cursor rule apply to every Zendesk incremental export?

No, the cursor parameter is only supported for incremental ticket exports, not all incremental exports. According to Zendesk, this restriction limits the use of cursor-based pagination to specific ticket export operations. Other incremental export types do not support this parameter.

How do I import Mixpanel events older than five days?

Use the /import API endpoint for bulk import of historical events older than five days. According to Mixpanel, this endpoint is optimized for scripting and supports ingesting historical data that falls outside the standard tracking window.

When does Paddle return an exact event count?

Paddle returns the exact count for datasets with 100,000 or fewer matches.

Does a Stripe webhook listening to all events generate Selection required events?

No, a webhook set to listen to all events does not satisfy the requirement and will not generate Selection required event types. According to Stripe, you must configure a specific listener for each Selection required event type to ensure those events are generated.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.