Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The November 2026 changelog says v1 and v2 credit_usage responses currently omit Credit Source while retaining total count and the Model breakdown.
- Read the returned categories list, use count for total credits, and read by_categories.Model only when it is returned; do not map a missing category to zero.
- The Analytics API is for Enterprise organizations and uses a separate, organization-scoped key managed by admins. The toggle may not be enabled for every organization yet.
- Keep UTC windows fixed while paginating with the opaque next_page cursor, and distinguish complete buckets, sync delay, empty data and has_more.
Missing Credit Source does not mean zero total usage
Keep total usage when Credit Source is missing. Perplexity’s November 2026 changelog says dataset=credit_usage responses from /v1/analytics/computer/usage and /v2/analytics/computer/usage currently omit this breakdown while retaining total credit usage and the Model breakdown.
Integrations that expect a fixed set of breakdowns should read the returned categories list. The changelog gives no reason for the omission or restoration date; its month-only entry leaves the exact announcement day, time and time zone unknown.
Read count and Model from the returned categories
A v1 credit_usage request returns one time series. The top-level categories list identifies the breakdown axes present in that response, and by_categories holds the values for each returned axis.
Use each bucket’s count as total credit usage. Read by_categories.Model as the model breakdown when Model appears in categories; do not require Credit Source to exist in a fixed field set.
An omitted Credit Source axis means the response does not provide that dimension. It does not mean total or source-level usage is zero. Perplexity also notes that count can exceed any single breakdown’s sum because unattributed usage remains in the total without appearing in a breakdown.
As a hypothetical arithmetic example, suppose count is 100 and the returned Model entries sum to 80. Retain 100 as the total and 80 as model detail. The remaining 20 is not attributed to a model; do not assign it to one or use it to infer the omitted Credit Source breakdown. These figures are not actual report data.
Confirm Enterprise access and the separate Analytics key
The Analytics API is available to Perplexity Enterprise organizations. An organization admin can enable Analytics API in the Computer settings of the Perplexity web app; if the toggle is absent, Perplexity says the feature may not be enabled for that organization yet, and advises contacting a Perplexity representative.
After enabling it, an admin can generate an organization-scoped Analytics key. Each organization has at most one active key; any organization admin can view or regenerate it. Regeneration revokes the prior key, and disabling the Analytics API toggle permanently revokes the key.
Send the key as a Bearer token using the dedicated PERPLEXITY_ANALYTICS_API_KEY variable. Keep it separate from PERPLEXITY_API_KEY used for other APIs. The key authenticates Analytics endpoints only and has no billing attached; Analytics requests are free and consume no API credits, which does not make underlying Perplexity product usage free.
The documentation establishes Enterprise organization access only. It does not establish eligibility for personal or standard API accounts, or publish Enterprise subscription prices or regional eligibility.
Pull a fixed UTC window with v1
For credit_usage, call GET /v1/analytics/computer/usage with dataset=credit_usage and the required inclusive start_time in Unix seconds (UTC). end_time is optional, exclusive, defaults to now, and future values are capped at the current time.
credit_usage supports bucket_width=1d or 1h, defaulting to 1d. limit is buckets per page: the daily default is 7 with a maximum of 31; the hourly default is 24 with a maximum of 168.
The API returns complete UTC grid buckets only. start_time snaps down to the bucket boundary, so the first bucket may include time before the requested start. The exclusive end is capped and snapped down as well; the in-progress bucket is omitted. A valid window with no complete buckets returns HTTP 200 with empty data.
When has_more is true, pass next_page back as page to continue the same report, keeping every other parameter unchanged. Treat the cursor as opaque. Set explicit start_time and end_time values before paginating; do not recalculate now on each page.
Group by member with v2, then combine daily fragments
GET /v2/analytics/computer/usage uses group_by=user_email for member-level results. It currently supports credit_usage and query_volume at daily granularity. A credit_usage row contains a member’s daily total and available Model breakdown; a query_volume row contains the member’s daily query count and available categories.
v2 limit counts member rows per page, with a default of 50 and a maximum of 100. A page can span multiple days, and rows for one day can be split across pages; collect every page before combining daily fragments.
v2 uses the same Analytics key, organization-level rate limit and 90-day maximum window. Its UTC time semantics match v1 daily buckets, but pagination is over member rows rather than buckets. Keep all other parameters fixed and pass next_page back unchanged. In v1, user_email can filter credit_usage; v1 query_volume is organization-wide, so use v2 for member-level query volume.
Each v2 data entry represents one UTC day, with results listing members who had usage that day. Days with no usage are omitted entirely. An absent day or member row therefore differs from an explicit count: 0 record.
Separate sync delay, empty windows and request errors
The analytics store syncs periodically rather than in real time, so a count of 0 in a recent bucket may reflect delayed syncing. has_more only indicates that more complete buckets remain in the selected window; it does not indicate freshness. Handle empty data, count: 0 and an omitted breakdown as different states.
A request window is limited to 90 days. Rate limits are shared across all keys in an organization; the documentation gives no numerical rate. A 429 means the organization limit was exceeded, so retry with backoff.
A 400 bad_request indicates a parameter with the wrong type or malformed value. A 400 invalid_request indicates a semantic error such as start_time after end_time, a window over 90 days, an invalid cursor, or an unsupported dataset, bucket width or filter. A 401 means the key is missing or invalid; 404 feature_disabled means the Analytics API is not enabled.
Actual organization data, sync timing, Enterprise subscription prices and regional eligibility require organization-specific information or confirmation from Perplexity. These two documents provide no complete organization or regional eligibility list and promise no real-time refresh.
Sources
Frequently Asked Questions
Can I add a parameter to bring back the Credit Source breakdown?
The current changelog only says that this breakdown is omitted from credit_usage responses in v1 and v2. It gives no restoration parameter or date. Parse the axes returned in categories and retain count as the total.
How should I split requests for a six-month historical report?
Each request window is limited to 90 days. If that much history is actually available to your organization, split it into adjacent, non-overlapping fixed UTC windows of no more than 90 days, finish pagination within each window, then combine them. The per-request limit does not guarantee six months of accessible history.