Tired of APIs holding you back? Mock your way forward

Editor’s note: Joana Salgueiro, Senior Developer at OutSystems, is the co-author of this post.

What if your OutSystems development team never had to wait for a backend API again?

Backend APIs are often missing, unstable, or still under development, creating a common bottleneck for OutSystems developers. This leads to missed deadlines, wasted sprint capacity, frustrated teams, and rework that stalls momentum. Idle hours and last-minute fixes drain productivity and morale, leaving developers frustrated and projects at risk.

API mocking solves this problem. By simulating backend behavior with agreed contracts, the Mock Framework allows OutSystems teams to develop features and integrate systems without waiting for the backend. Teams stay productive, projects continue to move forward, and bottlenecks that typically stall development are eliminated.

Seamless integration with OutSystems makes it simple to create, manage, and switch between mock and live endpoints with minimal effort. No external tools, no complex setup, just a faster, smoother, and more confident development experience tailored for OutSystems teams.

Let’s take a closer look at these blockers and how to eliminate them.

Source: Image generated by ChatGPT

The bottleneck blues: Why waiting kills progress

Modern software development is challenged by backend services that are unavailable, incomplete, or unstable during crucial development phases. These issues particularly impact frontend and integration work, often forcing developers to wait. Even when APIs are accessible, they can be unpredictable or rate-limited. These issues make it difficult to test important "edge cases," such as network timeouts or error responses. The problem becomes even more pronounced in non-production environments, where instability and performance issues can undermine reliable testing.

Many teams use "static mocks,” manually crafted responses that mimic backend behavior. While these offer short-term relief, they are fragile and difficult to maintain as APIs evolve. They often get out of sync with the API interfaces, resulting in misleading test outcomes and duplicated efforts. In essence, static mocks are like a painted landscape. They might look good initially, but they won’t adapt to changes in weather or seasons.

At the core of this struggle is the risk of "rewiring." This term refers to the frequent need to revise your mock implementations and testing logic whenever backend contracts change. Simply put, it's similar to rearranging the wiring in your house every time you purchase a new appliance. What may start as a quick fix can quickly become a long-term burden, escalating development efforts and increasing the risk of inconsistencies, especially in collaborative environments. Ultimately, these manual mocks may do more harm than good.

Source: Visual elaborated by the author, includes graphics from unDraw.com

The Mock Framework advantage

The Mock Framework is designed to simplify and enhance API mocking directly in the OutSystems environment. Its primary objective is to maintain development momentum by removing dependencies on real APIs that may be unavailable, unstable, or unusable.

This framework directly addresses the shortcomings of relying solely on real APIs and manual mocks by combining their strengths. It provides a scalable and maintainable solution that aligns with API contracts. To maximize the benefits of this framework, teams should incorporate it into their delivery process. The key to achieving this is to create a single, agreed-upon API contract and establish a standard way of modeling resources that everyone on the team understands.

Adopting this approach early in your workflow will significantly minimize rework and ensure that your teams stay in sync, effectively leveraging the advantages of both real APIs and robust API mocks.

Tangible mock benefits for your team

Adopting the Mock Framework offers several measurable benefits:

• Cost reduction: By automating repetitive setups and minimizing rework caused by unstable APIs, teams can focus more on delivering business value.
• Support for Agile and continuous delivery: The framework enables earlier and more frequent testing, aligning with Agile principles and continuous integration/continuous delivery (CI/CD) practices.
• Enhanced cross-team collaboration: It establishes a common language for developers, testers, and business stakeholders, facilitating seamless communication and limiting misunderstanding.
• Higher quality outcomes: The framework enables the simulation of realistic scenarios, including critical edge cases and error conditions (such as network failures, timeouts, or unauthorized access attempts), resulting in higher-quality software with fewer defects in production.
• Enhanced visibility and risk management: It provides real-time insights into mock coverage, highlighting potential risks and allowing for more informed planning.
• Accelerated time-to-market: By facilitating parallel development and eliminating backend dependencies, the framework significantly reduces the delivery timelines for new features.

Getting started with the Mock Framework in OutSystems

The Mock Framework can be easily installed and integrated into your OutSystems environment. Here’s a simplified overview of its operational workflow:

1. API contract alignment: Teams collaboratively define and agree upon the API contract before development begins. This contract outlines endpoint routes, methods, parameters, and response formats, ensuring a consistent understanding of the requirements. Typically, Swagger (OpenAPI Specification) is used as the source of truth, enabling automatic mock generation and validation.
2. Mock method configuration: In the framework, you create mock API methods that replicate the behavior of the real API.
3. Mock response setup: Define multiple response scenarios for each mock, including successful responses, various error states (for example, 401 Unauthorized, 500 Server Error, 404 Not Found), and network timeouts. This setup enables comprehensive testing without requiring access to an actual API.
4. Transition to real API: Once the backend provides the real API, transitioning from mock to live endpoints is seamless. If both teams respect the agreed contract, the switch will require no code changes.

Source: Template adapted from Slidesgo

Unblocking cross-team dependencies with the Mock Framework

In modern software development, teams often work in parallel on interconnected services. But what happens when one team is ready to deliver features while another team’s API is still in progress? Without a strategy, development stalls, testing is delayed, and delivery timelines suffer.

Let’s look at a real-life scenario. When building a Health Management Services App, Team A needed to deliver doctor-facing features, but was blocked because Team B’s Appointments API was still under construction. Instead of waiting, Team A used the Mock Framework to simulate the missing service. They created realistic mock endpoints aligned with the agreed API contract, allowing development to proceed, the functionality to be validated early, and integration issues to be avoided later.

Source: Visual elaborated by the author, with icons from icon-icons.com

How did “Team A” solve the Blocker? First, the two teams collaborated to define a single, authoritative API contract before any coding began. They agreed on:

• Endpoint route: /GetAppointments
• HTTP method: GET
• Required parameters: DoctorId, Date
• Response structure: JSON payload with standard status codes (200, 404, 500)

This early agreement minimized misunderstandings and ensured smooth integration later.

Secondly, Team A used the Mock Framework’s Configurations screen to create the method entry to represent the unfinished API:

• Name: GetDoctorAppointments
• Path: /GetDoctorAppointments
• HTTP Method: GET
• Method URL: e.g. /Appointment_DRV/rest/Appointment
• Response Structure: JSON matching the agreed contract

Then, it was time to add some response scenarios. To make testing comprehensive, Team A set up multiple mock responses:

• Successful Response: Default JSON with placeholder appointments (200).
• Parameter-Based Responses: Different data sets for DoctorId=123 vs. DoctorId=456.
• Error Simulations:
  • 401 Unauthorized for invalid tokens
  • 404 Not Found for unavailable appointments
  • 500 Internal Server Error and simulated network timeouts

You can see all of these scenarios in action in the demo below.

Each mock explicitly defined payloads and status codes, allowing the team to cover every expected scenario.

After the configurations were done, it was time to add the integration to the OnBeforeRequest event. The application’s API consumption logic was updated to redirect traffic to mocks when needed:

• Called RedirectRequestToMockFramework from MockFrameworkUtils.
• Set IsProduction = False in development and test environments to enable mocks.
• Enabled IsMockingOn=True for the /GetAppointments method.
• When toggled off, requests are automatically routed to the live service.

Logging, enabled via IsToCreateLogs=True in MockFramework_CS, provided visibility into every mock request, with the Logs screen confirming triggered responses. This maintained the accuracy and traceability of mocks throughout the development process.

With mocks in place, Team A continued developing features without waiting for Team B’s API. The ability to simulate real-world responses, including errors, helped testers validate application behavior early, reducing risk before integration.

Once the Appointments API was ready, Team A set IsMockingOn to False. Because both teams had adhered strictly to the contract, the switch to the live service required no code changes, making the transition frictionless. Team A efficiently developed features using mocks, simulating real-world responses and errors, which allowed for early validation of application behavior and reduced integration risks.

By combining API-first design with a configurable Mock Framework, Team A successfully eliminated cross-team blockers, enabled parallel development, reduced integration risks, and accelerated delivery timelines. This approach proves that structured mocking is a powerful enabler of productivity in complex, service-driven systems.

Don't wait, innovate!

Missing or unstable APIs can stall progress, frustrate developers, and lead to missed deadlines. The Mock Framework shows how API mocking can break this cycle, letting OutSystems teams deliver software confidently and at scale.

By empowering your teams to ship faster, collaborate more effectively, and build with confidence, the Mock Framework isn’t just another tool; it’s a mindset shift that turns backend blockers into opportunities for uninterrupted progress.

Adopt the Mock Framework and give your team the freedom to build without waiting, stress, or compromise. Start accelerating your development cycles today:

• Download the Mock Framework from the OutSystems Forge: O11 MockFramework and ODC Mock Framework
• Explore the documentation
• Watch the demo video