Billing and request counting

Billing and request counting

EcartAPI bills by request. Understanding what counts helps you estimate costs accurately and avoid surprises.

Billing cycle

Usage is counted per calendar month in UTC. Counters reset on the first day of each month at 00:00 UTC.

What counts as a billable request

Every successful API call counts as 1 request — including calls that return errors from the underlying platform.

ScenarioBillable?
Successful API call (2xx response)Yes
Platform rejected the request (4xx/5xx from the store)Yes — ecartapiError: false
EcartAPI internal error (our infrastructure)No — ecartapiError: true
Webhook delivery (POST to your URL)No — always free
Webhook CRUD (create / update / delete / list)Yes — 1 request each

The ecartapiError field

When a request fails, the error response includes an ecartapiError boolean and the HTTP status code:

{
  "statusCode": 400,
  "error": "...",
  "ecartapiError": false
}
ValueMeaning
falseThe ecommerce platform rejected the request (invalid payload, auth error, etc.)
trueEcartAPI had an internal error (infrastructure, proxy, etc.)

Current behavior: No errors are currently billed — failed requests are not counted toward your quota regardless of the ecartapiError value.

Important: A future update (planned for next year) will make requests where ecartapiError: false billable, since those represent real calls that reached the platform. We recommend implementing ecartapiError checks in your error handling from the start, so you already distinguish between platform errors and EcartAPI errors before this change takes effect.

Pagination

Each page of a paginated response counts as 1 billable request — not the entire result set.

If you retrieve 500 orders using a page size of 100, that is 5 billable requests.

GET /api/v2/orders?page=1&limit=100  → 1 request
GET /api/v2/orders?page=2&limit=100  → 1 request
GET /api/v2/orders?page=3&limit=100  → 1 request
...

Minimize page fetches by using filters (createdAt[from], updatedAt[from], status) to narrow results before paginating.

Estimating your usage

A simple fulfillment workflow — receive orders and post tracking — typically uses 2–3 requests per order:

OperationRequests
Get new orders (1 page)1
Post fulfillment per order1
Total per batch2

For 50 orders/day that is approximately 3,000 requests/month. For 2,000 orders/month, approximately 4,000–6,000 requests/month depending on how many pages you fetch and how often you poll.

Webhook-driven workflows are more efficient: instead of polling for orders, you receive one delivery per event at no charge, and only call the API when you need the full order details.

Free tier

Every EcartAPI account includes 1,000 free requests per calendar month. Webhook deliveries are unlimited and free — they do not consume this quota.

The free tier is a production quota, not a sandbox. You can use it to connect real stores and build your integration before committing to a paid tier.

Dashboard visibility

Request history is tracked per connected store in the EcartAPI dashboard. The count shown is a cumulative historical total since each store was first integrated — not a current-month snapshot.

Pricing tiers

See the full pricing page at ecartapi.com/prices. All plans include technical support, multiple applications, unlimited stores, and webhooks.

TierPrice per requestRequest rangeMinimum monthly
FreeFree1 – 1,000$0
Starter$0.011,001 – 10,000$10 USD
Growth$0.00310,001 – 100,000$100 USD
Scale$0.001100,001 – 1,000,000$300 USD
Enterprise$0.00051,000,001+$1,000 USD

The minimum monthly amount applies from the first request in each tier. When you exceed your current tier, EcartAPI automatically moves you to the next tier for the remainder of that billing month.

Next

→ Testing without a sandbox — How to use the free tier and production environment for development.
→ Webhooks — How webhook deliveries are free and how to use them to reduce polling.
→ Limits — Platform-level rate limits (distinct from billing quotas).


Did this page help you?