How to Mock APIs with Pagination: A Comprehensive Guide

Pagination splits large datasets into smaller parts so the UI can load them page by page. During development, the backend is often not ready or reliable enough to test against. Mocking lets you simulate paginated responses and test how the UI handles them.

This article explains what mock API with pagination means, why it’s important, and the best tools for the same.

What Is a Mock API?

A mock API is a fake version of a real API that mimics its structure and behavior without connecting to a backend or database. It returns predefined or dynamically generated responses when called, just like a real API would.

API mocking is especially useful when the backend is not yet built, is under active development, or is unavailable in certain environments. Mock APIs help frontend teams start building early, test against various data scenarios, and simulate errors or edge cases that are harder to trigger in a live system.

What Is API Pagination?

API pagination is a way to return large sets of data in smaller parts or “pages” instead of sending everything in one response. It helps avoid performance issues on both the client and server side, especially when dealing with large datasets.

Different APIs implement pagination using different styles. The most common patterns are:

• Page-Based Pagination: The client sends a page and pageSize parameter, and the API returns only that slice of data along with metadata like total pages and current page.
• Offset-Based Pagination: The client sends a limit and an offset value. The API returns data starting from that offset, limited to the specified size.
• Cursor-Based Pagination: The client uses a unique identifier (often called a cursor or token) to fetch the next set of results. This method is commonly used in real-time data systems where the dataset may change between requests.

Why Use Mock APIs with Pagination?

Mocking APIs is common during development, especially when the backend is not available. But with paginated endpoints, mocking it requires more than just returning sample data. You need to simulate real behavior by slicing data based on input parameters and including metadata like total items, page count, and navigation flags used by the frontend.

Here’s why mocking paginated APIs can be especially valuable:

• Test Pagination Logic: It helps verify if the client is correctly requesting the right pages, calculating offsets, or rendering “next” and “previous” controls based on metadata.
• UI Testing: Mocked paginated responses let developers build and test table views, infinite scrolls, and page navigation without needing a live backend.
• Handle Edge Cases: You can simulate scenarios like empty pages, last page with fewer items, or invalid pagination inputs to check how the app responds.
• Backend Not Ready: Frontend teams can continue working even when the real paginated API is incomplete or being refactored.
• Faster Iteration: You can quickly change page sizes, dataset lengths, or metadata formats in a mock setup without waiting on API changes.

Tools for Mocking APIs with Pagination

There are several tools available that help you mock APIs with pagination support. Some are browser-based, while others let you run local servers or define mocks within your project. Below is a breakdown of five widely used tools, including when to use each one.

1. Requestly by BrowserStack

Requestly is a browser-based tool that allows developers to intercept, modify, and mock network requests without setting up a local server. You can define mock endpoints, adjust request and response data, and apply logic based on query parameters like page or limit.

Key Features of Requestly: 

• Create Mock Endpoints: Define custom URLs that return mock JSON responses, useful for simulating paginated APIs like /products?page=2.
• Modify API Responses: Override the data returned from real endpoints to simulate different pages or dataset variations without backend changes.
• Modify Query Param: Adjust values like page, limit, or offset in incoming requests to test how the UI handles pagination changes.
• Modify HTTP Status Code: Simulate errors like 400 or 404 to test how your app responds to invalid or out-of-range pages.
• Insert Custom Scripts: Add logic to return different mock data based on query inputs, which helps simulate realistic pagination behavior.
• HTTP Interceptor: Intercept and modify live HTTP requests and responses, allowing you to test pagination in real time without touching backend code.

Why Choose Requestly? 

Requestly is well-suited for mocking paginated APIs when you want full control without setting up a separate server. It lets you modify both requests and responses in real time, which helps test how the frontend handles pagination inputs, sliced data, and metadata.

You can also simulate both typical and edge cases by adjusting query parameters, HTTP status codes, or response content. It is also helpful when the backend is not yet ready or when you need to unblock frontend work by simulating realistic paginated behavior.

Requestly Pricing:

• Free: $0
• Lite: $8/month
• Basic: $15/month
• Professional: $23/month

Talk to an Expert

2. Mockoon

Mockoon is a desktop application for building and running mock servers locally. It lets you define endpoints, handle pagination logic with query parameters, and return dynamic responses using templating or scripting.

Key Features of Mockoon: 

• Multi-server support: Run multiple mock servers locally for different environments or APIs.
• Pagination control: Handle page, limit, or offset parameters using templated routes.
• Response templating: Use variables to return dynamic data per request.
• Easy export/import: Save and share mock setups through exported environment files.

Pros and Cons of Mockoon: 

3. Postman

Postman is an API workspace tool that supports designing, testing, and mocking APIs in one environment. It allows you to set up mock servers by attaching predefined responses to specific request patterns. For paginated APIs, you can create examples that reflect different pages, each with its own data and metadata.

Key Features of Postman: 

• Multiple examples per route: Create different responses based on query inputs like page or offset.
• Pre-request scripting: Add logic to manipulate responses before they’re sent.
• Integrated collections: Group mock endpoints with documentation and tests.
• Mock URL hosting: Host mocks on Postman’s cloud servers.

Pros and Cons of Postman: 

4. Mocky

Mocky is a lightweight, no-signup tool for creating static mock endpoints. You define a JSON response, get a URL, and use that as your API. While it doesn’t support logic-based routing directly, it works for simple paginated examples if you create separate URLs per page.

Key Features of Mocky: 

• Custom Response Builder: Paste custom JSON to reflect paginated data structures, including fields like totalItems, currentPage, and hasNextPage.
• Version Locking: Lock a mock response to a fixed version so you can test against consistent data throughout development.
• Public Sharing: Generate a shareable URL for each response, which can be used by frontend developers or testers without any login.

Pros and Cons of Mocky: 

5. Beeceptor

Beeceptor offers a mock server that can inspect, log, and mock HTTP requests. It supports conditional mocking based on query parameters and is useful for testing pagination behavior with dynamic responses.

Key Features of Beeceptor: 

• Conditional mocking: Return different responses based on query parameters like page.
• Request inspection: View complete logs of incoming requests for debugging.
• Endpoint simulation: Create RESTful URLs for any endpoint or method.
• Custom rules engine: Define response behavior based on request headers or body.

Pros and Cons of Beeceptor: 

Advanced Techniques in Mocking Paginated APIs

Once you’ve covered the basics like returning paged data and aligning metadata, you may need to simulate behaviors that resemble real-world API complexity. These techniques are useful in high-coverage UI testing, integration environments, and shared mocks for teams.

• Stateful Pagination Mocks: Maintain state across requests to simulate user interactions like “load more” or “scroll to continue.” For example, track cursor values or simulate session-linked paging where the server behaves differently depending on previous requests.
• Data-Dependent Pagination: Instead of returning hardcoded pages, generate mock data based on search filters, sort parameters, or dynamic data conditions. This allows testing for combinations like “page 3 of search results with filters applied.”
• Cursor-Based Simulation: Mimic APIs that use cursor-based pagination (e.g., nextCursor, prevCursor) instead of page numbers. This requires mock logic that uses encoded or token-based values and validates them across calls.
• Mixed Pagination Models: Simulate APIs that switch between page-based and cursor-based modes depending on context. For example, a product listing may use pages, but a notifications feed may use cursors.
• Error Injection Framework: Programmatically trigger different error states at specific pages or based on frequency (e.g., fail every 5th page). This helps test retry logic, fallback UIs, and error boundaries under paginated flows.
• Mock Pagination at Scale: Generate mocks that simulate large datasets (hundreds or thousands of pages) to test memory usage, lazy loading performance, and pagination UI under heavy load. This includes dynamic mock servers that can stream or chunk data.

Challenges in Mocking APIs with Pagination

Mocking paginated APIs is more complex than mocking static endpoints. Below are common challenges that arise when trying to replicate real pagination behavior.

• Maintaining Consistency: It’s easy to create mismatches between metadata and the returned data. For example, saying there are 5 pages but only providing data for 3.
• Query-Aware Responses: Returning the same mock response regardless of page or limit can break UI logic. But adding proper conditional logic takes more setup.
• Simulating Data Variation: Static mocks often repeat the same items on every page. This does not reflect how actual APIs deliver unique items per page.
• Testing Empty States: Simulating empty pages, no results, or the last page with fewer items requires more than just a sample JSON file.
• Handling Combined Parameters: Some APIs support filters, sorts, or search along with pagination. It’s difficult to mock those combinations without writing custom scripts.
• Mock Tool Limitations: Not all tools support query-based routing, custom scripts, or dynamic responses, which limits how realistic the pagination mock can be.

Best Practices for Mocking Paginated APIs

To make the most of your mock setup, these best practices help improve test accuracy and reduce frontend-backend mismatches.

• Keep Metadata Aligned with Data: Always ensure fields like totalItems, currentPage, and hasNextPage reflect the actual data being returned.
• Use Page-Specific Mock Data: Avoid static mocks that return the same result for every page. Generate distinct content for each page, even if it’s simple variations.
• Mock Edge Pages Deliberately: Create mocks for the first, middle, and last pages so you can test navigation, button states, and scroll handling.
• Simulate Error Conditions: Include scenarios like invalid page numbers, missing parameters, or rate-limit errors to test robustness of pagination logic.
• Automate Dynamic Mocks if Possible: Use scripting or templating to reduce the need for manually creating multiple page responses.
• Document Mock Behavior Clearly: Make sure your team knows how the pagination mock works, what inputs it accepts, and what edge cases it covers.

Conclusion

Mocking APIs with pagination helps replicate real API behavior. This includes handling input parameters, slicing data correctly, adding metadata like total pages and current page, and covering edge cases. A structured mock setup helps teams validate pagination logic early in development without relying on a backend.

Requestly provides the tools needed to build these mocks directly in the browser. It lets you intercept requests, adjust query parameters, return paginated responses, and apply custom logic without even running a server. This makes it easier for frontend teams to test real-world scenarios and move forward without backend delays.

Try Requestly for Free