> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/settings/observability/api-usage.md). # API Usage **Settings → API Usage** shows how much of your tenant's API capacity you're using — both the calls coming *into* PeakCommerce and the calls PeakCommerce makes *out* to your connected systems — measured against **your own limits**, so you can spot pressure before it becomes a problem. ## What's on the page | Section | What it shows | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Filters** | An **API key** selector (**All API keys**, or one key) and a time window: **Last hour**, **Last 24 hours**, or **Last 7 days**. | | **Rate limit warning** | A banner appears when any limit passes **70%** of its ceiling (warning) or **90%** (critical). You can dismiss it; it comes back if the situation gets worse. | | **Rate Limits** | Your tenant's governance tier, with a usage bar and a 24-hour trend for every rate and concurrency limit (see below). | | **Summary cards** | **Total requests**, **Errors**, **Rate limited**, and **Avg latency** for the window. They combine inbound API requests and outbound integration calls. | | **Inbound request volume & error rate** | A chart of inbound requests and errors over the window. | | **Inbound route breakdown** | Per route: method, requests, errors, rate-limited count, and average latency. | | **Outbound calls** | Per connected system: calls, errors, error rate, and average latency. | The page refreshes itself every 30 seconds. ## One set of limits, both directions PeakCommerce governs **your tenant's own** capacity — not your connected systems' limits. Every call is counted, whether it's **inbound** (a person or an API key calling PeakCommerce) or **outbound** (PeakCommerce calling your billing system, your CRM, your identity provider, a fraud check, and so on). The limit figures on this page are the **combined total** — inbound and outbound together. You never manage them as two separate budgets. > **PeakCommerce reacts to your providers' real signals.** If a connected system is busy, it tells us — an HTTP `429` with `Retry-After` — and PeakCommerce backs off and retries. The limits on this page are **yours**, set on your tenant. ## Rate — UI, API, and Auth Traffic is grouped into three **categories**, each shown as requests per minute, hour, and day (RPM / RPH / RPD), and each measured against your tenant's limit: * **API** — programmatic and integration traffic: inbound API-key calls **and** PeakCommerce's outbound calls to systems like Zuora and Salesforce. * **Auth** — sign-in and identity traffic: inbound authentication **and** PeakCommerce's outbound calls to your identity provider (Auth0, Okta). * **UI** — traffic from people using the portals in a browser. ## Concurrency — Default, Query, and High-volume Alongside rate, PeakCommerce limits how many calls run **at the same time**, in three buckets — again combining inbound and outbound, each shown against your tenant's limit: * **High-volume** — commerce and money-path work: placing orders, changing subscriptions, taking payments and refunds. * **Query** — large-result reads: lists, searches, and data queries. * **Default** — single-record reads, metadata, sign-in, and everything else. Splitting concurrency into buckets keeps a burst of one kind of work — say a large catalog sync — from starving another, like a customer trying to check out. ## Your limits are yours — and adjustable These limits come from your tenant's governance tier, shown as a badge on the **Rate Limits** card, and can be **raised or tuned per tenant** by your account team. If a legitimate workload keeps pushing a limit — a nightly sync, a burst of checkouts — that's a signal to right-size the limit, not a wall you can't move. ## Reading the trends * Establish a baseline for normal traffic and treat departures from it as worth investigating. * Read a sustained climb as capacity planning — or a runaway integration. * Read a sudden drop as a possibly broken or disconnected integration. For exact per-endpoint outbound detail — call counts, latency, and errors for each provider — pair this page with [API Call Stats](/product/settings/observability/api-call-stats.md). ## Gotchas * **The limit bars are combined (inbound + outbound).** A spike in **API** could be inbound API-key traffic, outbound billing or CRM calls, or both — the route breakdown and the outbound table on this page, or [API Call Stats](/product/settings/observability/api-call-stats.md), show which. * **Auth includes outbound.** Calls out to your identity provider count as Auth, not just inbound sign-ins. * **A provider's own limit is separate.** If your billing system or card processor throttles one of our calls, that surfaces as *their* error in API Call Stats — it isn't governed by the numbers on this page. * History is retained for a bounded window, so very old periods may not be available. ## Related * [API Call Stats](/product/settings/observability/api-call-stats.md) — per-endpoint counts, latency, errors, and per-provider outbound volume. * [Rate limits for API keys](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/developers/api-reference/rate-limits.md) * [Audit Trail & Logs](/product/reporting-and-analytics/audit-trail-and-logs.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.peakcommerce.com/product/settings/observability/api-usage.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.