Mock APIs with Pagination: Types, Steps, and Best Practices

Mock APIs with pagination let developers and testers work with realistic, segmented data before the backend is ready. Instead of returning all records in one response, they simulate how production APIs deliver results in smaller chunks with navigation details like page numbers or cursors.

A well-designed mock API with pagination returns limited results per request, along with metadata such as total items and current position. This helps replicate real-world API behavior and ensures the client-side logic for page navigation is properly tested.

This article covers how pagination works in mock APIs, the main types used, steps to create one, and best practices to make it behave like a live API.

What is a Mock API with Pagination?

A mock API with pagination is a simulated API that returns data in separate pages instead of sending all results in one response. It behaves like a real API that implements pagination, including parameters to request specific pages and metadata to guide navigation.

The purpose is to help developers and testers work with realistic API responses before the actual backend exists. This ensures that client-side logic for loading, displaying, and navigating through paged data can be developed and tested early in the project lifecycle.

In most setups, a mock API with pagination will:

• Accept page-related parameters: The API should allow clients to specify parameters such as page, limit, offset, or cursor to request a specific portion of the data.
• Return a subset of results: Each response should contain only a fixed number of records, such as 10 or 20 items, instead of the full dataset.
• Include navigation metadata: The response should provide details like the total number of items, total pages, and the current position within the dataset so the client knows how to fetch the next or previous set of results.

Why is Pagination Important in Mock APIs?

Pagination in mock APIs is not just about mimicking how production APIs handle large datasets. It plays a practical role in testing application behavior, optimizing performance, and ensuring UI consistency. Without pagination in mock APIs, tests may pass in controlled environments but fail in production when dealing with large amounts of data.

Here are the main reasons it matters:

• Performance simulation: Helps test how the application behaves when loading data in chunks, which is closer to real usage than loading everything at once.
• UI and navigation logic testing: Allows validation of components like “Next” and “Previous” buttons, infinite scrolling, or numbered page selectors.
• Edge case coverage: Enables checking how the application responds when reaching the first or last page, or when no results match a filter.
• Data consistency testing: Ensures that sorting, filtering, and pagination interact correctly, especially in dynamic datasets.

How Does Pagination Work in Mock APIs?

Pagination in mock APIs works by splitting a dataset into smaller groups of records and serving only the requested group when a client makes a call. This setup is controlled through request parameters that indicate which portion of the data is needed. The mock API then constructs a response that contains both the requested records and metadata for navigating the dataset.

The process typically involves:

• Requesting a specific data slice: The client includes parameters such as page and limit or offset and count in the API request to define which items should be returned.
• Fetching matching records: The mock API looks up the relevant range in its predefined dataset and prepares that subset for the response.
• Adding navigation details: Metadata, such as totalItems, totalPages, and currentPage, is added so the client knows what other data can be requested next.

Types of Pagination in Mock APIs

Different pagination methods can be implemented in a mock API to simulate how various production APIs work. The choice of method affects performance, complexity, and how easily the client can fetch specific data.

Below are the main types used in both real and mock APIs:

• Page-based pagination: Uses a page parameter to request a specific numbered page. For example, page=2&limit=20 returns the second set of 20 items.
• Offset-based pagination: Uses an offset parameter to skip a set number of items before returning results, often combined with a limit value.
• Cursor-based pagination: Uses a pointer, or “cursor,” to indicate where in the dataset to start returning results. Often used for large or frequently changing datasets.
• Keyset or seek pagination: Relies on a unique column value, such as an ID or timestamp, to fetch records after a certain point.
• Time-based pagination: Fetches results that fall within a specific time range, useful for chronological data.

Below is a detailed description of the types of pagination in mock APIs.

1. Page-Based Pagination

Page-based pagination is one of the simplest and most widely used methods in both real and mock APIs. It organizes data into fixed-size pages and allows clients to request a specific page number. This approach is easy to implement and works well when the dataset size is moderate and changes infrequently.

In a mock API, page-based pagination typically works as follows:

• Request a specific page: The client sends parameters such as page=3&limit=20 to indicate it needs the third set of 20 items.
• Calculate the data range: The API determines which items correspond to that page by using the formula (page – 1) * limit as the starting index.
• Return data and metadata: The response contains the requested items along with details like totalPages, totalItems, and currentPage.

Example request:

GET /products?page=2&limit=5

Example response:

{  
"currentPage": 2,  
"totalPages": 10,  
"totalItems": 50,  
"limit": 5,  
"data": [    
{ "id": 6, "name": "Product F" },    
{ "id": 7, "name": "Product G" },   
 { "id": 8, "name": "Product H" },    
{ "id": 9, "name": "Product I" },    
{ "id": 10, "name": "Product J" }  
]
}

This example shows both the paged dataset and the metadata needed for navigation. In a mock API, these values are generated from a static dataset or a pre-defined JSON file, making it easy to simulate realistic API behavior.

2. Offset-Based Pagination

Offset-based pagination returns results starting from a specific position in the dataset, skipping over a defined number of records. It is useful when the client needs more control over the starting point, such as resuming from a known position. However, it can become slower with very large datasets because the system still counts through skipped records.

In a mock API, offset-based pagination works as follows:

• Specify the starting point: The client sends an offset parameter along with a limit, for example, offset=40&limit=20. This means “skip the first 40 records and return the next 20.”
• Fetch the relevant items: The mock API reads the dataset starting from the offset position and returns up to the limit count.
• Provide navigation details: Metadata such as offset, limit, and totalItems is included so the client can calculate the next offset if needed.

Example request:

GET /products?offset=10&limit=5

Example response:

{ 
 "offset": 10,  
"limit": 5, 
 "totalItems": 50,  
"data": [    
{ "id": 11, "name": "Product K" },    
{ "id": 12, "name": "Product L" },   
 { "id": 13, "name": "Product M" },    
{ "id": 14, "name": "Product N" },    
{ "id": 15, "name": "Product O" }  
]
}

3. Cursor-Based Pagination

Cursor-based pagination uses a pointer (cursor) to indicate where in the dataset the next set of results should start. The cursor is often an encoded value based on a unique field, such as an ID or timestamp, from the last item in the current page. This method is efficient for large or frequently changing datasets because it does not rely on fixed page numbers or offsets.

In a mock API, cursor-based pagination works as follows:

• Identify a starting point: The client sends a cursor parameter, which represents the position after which results should be returned.
• Retrieve the next set: The API looks up items after the cursor and returns them, up to the specified limit.
• Provide the next cursor: The response includes a new cursor to be used for the next request.

Example request:

GET /products?cursor=10&limit=5

Example response:

{  
"nextCursor": 15,  
"limit": 5,  
"data": [    
{ "id": 11, "name": "Product K" },    
{ "id": 12, "name": "Product L" },    
{ "id": 13, "name": "Product M" },    
{ "id": 14, "name": "Product N" },    
{ "id": 15, "name": "Product O" }  
]
}

4. Keyset or Seek Pagination

Keyset pagination fetches records based on a unique column value, such as an ID or timestamp, instead of counting through rows. This approach is fast and consistent for ordered datasets because it avoids performance issues caused by large offsets. It works best when the dataset has a stable, indexed column to use for ordering.

In a mock API, keyset pagination works as follows:

• Send the last known key: The client provides a lastId or similar parameter that indicates where the next set should start.
• Retrieve the next items: The API returns records where the key is greater than the provided value, limited to the requested count.
• Include the next key: The response provides the key of the last record so the client can use it in the next request.

Example request:

GET /products?lastId=10&limit=5

Example response:

{  
"lastId": 15,  
"limit": 5,  
"data": [   
 { "id": 11, "name": "Product K" },   
 { "id": 12, "name": "Product L" },    
{ "id": 13, "name": "Product M" },    
{ "id": 14, "name": "Product N" },    
{ "id": 15, "name": "Product O" }  
]
}

5. Time-Based Pagination

Time-based pagination uses a date or timestamp to retrieve records within a specific range. It is especially useful for datasets where records are sorted chronologically, such as logs, messages, or transactions. This approach is more flexible when users want to fetch data from a certain point in time.

In a mock API, time-based pagination works as follows:

• Specify a time marker: The client sends a parameter such as after=2025-08-01T00:00:00Z to request all items created after that date.
• Return the next time window: The API returns records within the specified range and up to the limit.
• Provide the next time marker: The response includes a timestamp from the last record, which can be used for the next request.

Example request:

GET /products?after=2025-08-01T00:00:00Z&limit=5

Example response:

{  
"nextAfter": "2025-08-01T12:15:00Z",  
"limit": 5,  
"data": [    
{ "id": 101, "name": "Product A1", "createdAt": "2025-08-01T09:00:00Z" },    
{ "id": 102, "name": "Product A2", "createdAt": "2025-08-01T09:30:00Z" },    
{ "id": 103, "name": "Product A3", "createdAt": "2025-08-01T10:00:00Z" },    
{ "id": 104, "name": "Product A4", "createdAt": "2025-08-01T11:00:00Z" },    
{ "id": 105, "name": "Product A5", "createdAt": "2025-08-01T12:15:00Z" }  
]
}

How to Create a Mock API with Pagination (Step-by-Step Guide)

You can create a mock API with pagination entirely in your browser using Requestly, without setting up a backend server. The process involves creating a mock API endpoint, adding paginated data, and configuring it to respond dynamically based on query parameters.

Step 1: Create a new mock API in Requestly

1. Open Requestly and sign in.
2. From the dashboard, click Create Rule > Mock API.
3. Give your mock API a name, such as Products API with Pagination.

Step 2: Add your dataset

1. Prepare a JSON dataset with enough records to span multiple pages (for example, 50–100 items).
2. Paste the JSON into the mock API editor. This will serve as your “full” dataset.

Step 3: Enable query parameter handling

1. In the Requestly mock API editor, check the option to Make response dynamic.
2. Access query parameters in the mock editor using params.page or params.limit.
3. Write a small JavaScript snippet to slice your dataset:

const page = parseInt(params.page || 1, 10);
const limit = parseInt(params.limit || 10, 10);
const start = (page - 1) * limit;
const end = start + limit;
const paginatedData = data.slice(start, end);
return {  
currentPage: page,  
totalPages: Math.ceil(data.length / limit),  
totalItems: data.length,  
limit: limit,  
data: paginatedData
};

Step 4: Save and test the endpoint

1. Click Save to publish your mock API.
2. Copy the auto-generated Requestly mock API URL.
3. Test in your browser or API client:

GET https://mock.requestly.io/api/products?page=2&limit=5

Step 5: Integrate with your frontend

1. Point your application’s API calls to the mock API URL.
2. Test navigation, sorting, and filtering while adjusting the page and limit in requests.

With this setup, you can switch between different pagination strategies by changing the JavaScript logic in Requestly. For example, to use cursor-based pagination, replace pages and limit calculations with cursor lookups.

Best Practices for Implementing Pagination in Mock APIs

When designing a mock API with pagination, follow these best practices to ensure that your simulated responses behave like real-world APIs.

• Mirror real API behavior: Match the pagination structure, parameters, and response format of the actual API you will integrate with, so there is no mismatch during production handover.
• Use realistic dataset sizes: Populate your mock API with data volumes that mimic real usage scenarios, rather than minimal test data, to validate performance and UI handling.
• Include navigation metadata: Always return fields like totalItems, totalPages, and currentPage so clients can correctly handle navigation and display page counts.
• Support multiple pagination types if needed: If the real API supports both offset-based and cursor-based pagination, ensure your mock API can simulate both for testing flexibility.
• Validate edge cases: Test with scenarios like the first page, last page, empty pages, and requests beyond the available data to ensure error handling is accurate.
• Optimize for speed in mocks: While realism matters, your mock API should respond quickly to avoid slowing down development and testing cycles.
• Document parameter behavior clearly: Define how parameters like page, limit, or cursor work in your mock so testers and developers know what to expect.

Conclusion

Pagination in mock APIs helps simulate real-world data delivery, improve performance, and catch issues early. Using types like page-based, offset-based, cursor-based, or time-based ensures realistic and scalable testing.

With Requestly, you can set up mock APIs with custom pagination in minutes, no backend needed. Its no-code interface and flexible rules make development and testing faster and more accurate.