# Epicor REST API Paging and Throughput Calculator

> Source: https://netray.co/tools/epicor-rest-api-paging-throughput-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate how long an Epicor REST extract takes for a given page size, latency and concurrency, and find the sweet spot.

## Category

epicor

## Erp

Epicor Kinetic

## Audience

- Epicor developer
- Integration engineer
- Data engineer

## Tool

**Kind:** calculator

**Inputs:**

#### Records to extract

**Key:** records

**Type:** number

**Default:** 120000

**Min:** 1

**Step:** 5000

**Unit:** records

#### Page size ($top)

**Key:** page

**Type:** slider

**Default:** 500

**Min:** 10

**Max:** 5000

**Step:** 10

**Unit:** records

#### Fixed latency per call

**Key:** latency

**Type:** number

**Default:** 450

**Min:** 0

**Step:** 50

**Unit:** ms

**Help:** Network, authentication and query setup for each request.

#### Server and transfer time per record

**Key:** per_rec

**Type:** number

**Default:** 0.8

**Min:** 0

**Step:** 0.1

**Unit:** ms

#### Parallel requests

**Key:** threads

**Type:** number

**Default:** 4

**Min:** 1

**Max:** 32

**Step:** 1

**Unit:** threads

**Help:** Respect your license, server capacity and any API limits.

#### Payload per record

**Key:** kb_rec

**Type:** number

**Default:** 1.5

**Min:** 0.1

**Step:** 0.1

**Unit:** KB

**Outputs:**

#### Requests needed

**Key:** calls

**Expr:** ceil(records / page)

**Format:** integer

#### Time per request

**Key:** call_ms

**Expr:** latency + page * per_rec

**Format:** number

#### Total duration (seconds)

**Key:** total_s

**Expr:** calls * call_ms / 1000 / threads

**Format:** decimal

#### Total duration

**Key:** total_min

**Expr:** total_s / 60

**Format:** minutes

**Primary:** true

#### Throughput (records/second)

**Key:** throughput

**Expr:** records / max(total_s, 0.001)

**Format:** integer

**Primary:** true

#### Data transferred (MB)

**Key:** payload_mb

**Expr:** records * kb_rec / 1024

**Format:** decimal

**Chart:**

#### Total duration vs page size

**Type:** line

**X:** page

**From:** 10

**To:** 2000

**Steps:** 40

**Series:**

- total_min

**Disclaimer:** Model assumes fixed latency plus linear per-record time. Very large pages can time out or strain memory, so test on your own system and keep pages moderate.

## Content

**Intro:** Pulling a large table through Epicor REST with a tiny page size makes thousands of round trips, while a huge page risks timeouts. This calculator shows the duration, request count and throughput for any page size and parallelism so you can choose with numbers.

**Sections:**

#### How to use it

**Body:** Enter the number of records, the page size you plan to request with $top, and your measured fixed latency per call. Add per-record time and the number of parallel requests. The tool returns the request count, time per request, total duration and records per second, and the chart shows duration across page sizes so you can see where larger pages stop helping.

**Bullets:**

- Measure latency by calling a tiny page such as $top=1.
- Page with $top and $skip, or use a stable ordering key for safety.
- Add $select to return only the columns you need.

#### The math

**Body:** Requests equal records divided by page size, rounded up. Each request costs fixed latency plus page size times per-record time. Total time is requests times request time, divided by the number of parallel threads. Throughput is records divided by total seconds. Because latency is paid per call, larger pages remove overhead until per-record time dominates and the curve flattens.

#### Practical guidance

**Body:** The chart typically falls steeply and then flattens, so beyond a few hundred to a couple of thousand records the gain is small while risk grows. Skip-based paging gets slower on deep pages in some queries, so filtering by a date or key range and extracting in slices is often safer. Run extracts off-hours and keep concurrency modest to protect users.

#### Common mistakes

**Body:** Extracting without $select drags every column over the wire. Using one thread for a huge table wastes time, while too many threads can slow the whole server. Failing to handle token expiry on long jobs and not retrying transient errors are common causes of half-finished extracts. Log the last successful page so you can resume.

**Cta:** If you are building a data pipeline out of Epicor, Netray can help design it with proper paging, retries and read-only safeguards. The calculator stands alone.

**Faq:**

#### What page size should I start with?

**Answer:** A few hundred to a thousand records is a sensible start for many tables. Test a couple of sizes against your system and watch response time and server load, then settle on the lowest size that keeps duration acceptable.

#### Should I use BAQ endpoints or table services?

**Answer:** BAQ endpoints let you shape and filter data on the server and return only needed fields, which often suits extracts. Table services suit simple reads and writes. Choose by the shape of the data you need.

#### Are there API rate limits?

**Answer:** Limits depend on your Epicor deployment, licensing and configuration. Check with your administrator or Epicor documentation, and design the job to back off and retry on throttling responses.

#### How do I avoid missing rows while paging?

**Answer:** Order by a stable unique key and, ideally, filter by a time or key range rather than relying on deep skip values, so changes made during the extract do not shift your pages.

## Search terms

epicor rest api pagination, epicor odata top skip, epicor rest v2 extract large data, epicor api performance, epicor integration batch size, epicor api rate, epicor baq rest export

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json