Billing FAQs

This typically happens because we meter usage at the API hit level, while many client systems count usage at the business request or request body level. Every authenticated API call that reaches our gateway is logged and metered individually. If a single business workflow triggers multiple API calls, retries, or downstream calls, each of those is counted as a separate transaction on our side.

Your system may treat the request as a single logical operation, but technically it can result in:

Our billing is based on actual API hits processed, not how the request is logically grouped in your application.

Yes. Any request that reaches our gateway and is processed is logged, regardless of whether it succeeds or fails. This includes retries, timeouts, and non-200 responses. The status code is always available in the transaction logs for full transparency.

Client side logs vary significantly across implementations and often:

As a vendor, we can only guarantee accuracy and auditability based on our gateway logs, which are immutable, timestamped, and consistent across all customers.

The API transaction logs generated at our gateway are the source of truth for billing. These logs capture every request with timestamp, product ID, API name, status code, response time, correlation ID, and client IP.

Use the x-client-unique-id header in every API request. We echo the same ID back in the response and store it in our logs. This creates a shared reference point so both teams can trace the exact same transaction without ambiguity.

If the header is not provided, our system generates an internal trace ID. While the transaction is still fully logged, reconciliation becomes slower because there is no client-side reference ID to match against your systems.

Without a shared correlation ID:

Correlation IDs shift the discussion from “counts” to specific transactions, which eliminates confusion.

No. Billing cannot be aligned to client-specific counting logic because it would break consistency, auditability, and fairness across customers. However, we provide full transparency so you can independently verify every billed transaction using logs and correlation IDs.

This model avoids ambiguity, prevents revenue leakage, and significantly reduces back-and-forth between engineering, finance, and operations teams.

All API transactions are logged at the gateway and NGINX layer. Logging happens when a request successfully reaches our infrastructure and is processed by the gateway. This ensures:

This is why gateway logs are treated as authoritative.

We log request and response headers only, along with gateway metadata. This includes:

We do not log request bodies or response payloads.

Request and response bodies often contain:

Storing payloads would introduce privacy, security, and regulatory risks. For this reason, we intentionally restrict logging to headers and metadata only. This approach is aligned with data minimization and privacy best practices.

Headers provide:

From a billing and audit perspective, headers give all required evidence without creating compliance risk.

Common reasons include:

These are often invisible in application level logs but clearly visible at the gateway.

We recommend logging the following fields for every outbound API call:

This creates a clean one to one mapping with our gateway logs.

For manual reconciliation, clients can share:

No request or response payloads are required or expected.

At minimum:

With these fields, we can deterministically match transactions across systems.

Yes, but it is significantly slower and more error prone. Without correlation IDs, reconciliation relies on timestamp windows and heuristic matching, which increases ambiguity. Correlation IDs remove interpretation entirely.

Because:

Client side counts are valuable for internal monitoring but cannot be used as a billing authority.

This process avoids prolonged disputes and reduces engineering effort on both sides. Following this document ensures predictable billing, faster dispute resolution, and complete transparency between both teams.