APIs rarely work in isolation. Real-world usage involves multiple steps, and the outcome of each step determines the journey a particular interaction takes. While testing individual endpoints is necessary, it’s not sufficient. It is equally important to validate how those endpoints work together as part of a real workflow.

Enter the Arazzo Specification, which describes complete workflows including inputs, outputs, step dependencies, and success/failure criteria. In this talk, we’ll demonstrate how you can leverage Arazzo to drive API workflow testing and mocking in a completely no-code manner.

We’ll show how Arazzo + Specmatic enables shift-left testing of entire API journeys, not just individual operations, and how mocking full user flows can unblock frontend teams and accelerate CI pipelines. The session will also walk through the full lifecycle about how we design a multi-step journey, author / generate an Arazzo spec to capture it, and ensure both provider and consumer adhere to the same contract thereby enabling independent, parallel development and deployment of services and components.

AsyncAPI 3.0 introduces many improvements, including support for patterns like request-reply, making it a compelling upgrade. But how can you be sure your migration doesn’t unintentionally alter API behaviour?

In this talk, you’ll learn how to use no-code spec-vs-spec backward compatibility checks to ensure that your upgrade from 2.6 to 3.0 is safe, controlled, and limited to syntax changes alone. We’ll explore how this method catches behavioural mismatches early, enabling teams to adopt AsyncAPI 3.0 confidently—without fear of breaking existing contracts. This talk will involve live demos based on our experience handling migrations in real world projects.

Have you ever needed to add or remove information from your API specification—based on environment, audience, or tool—without duplicating or forking the spec? The Overlay Specification is designed exactly for that. In this talk, I’ll share real-world use cases where we’ve used overlays to customize and enhance both OpenAPI and AsyncAPI specifications for different contexts—ranging from contract testing and conformance testing to API mocking, sandboxes, and gateways. We’ll also explore how overlays can help enrich specs with agent-friendly details—making your APIs more accessible to AI tools and code-generating agents. Through live demos, you’ll see how overlays enable a single source of truth to serve multiple purposes cleanly and effectively.

Building applications that rely on APIs requires seamless coordination between consumers and providers. This is especially true in GraphQL architectures, where front-end applications interact with GraphQL services through queries and mutations. However, challenges arise when the GraphQL service isn’t yet available, or when discrepancies exist between consumer expectations and provider implementations. To address these challenges, executable API contracts based on GraphQL Schema Definition Language (SDL) files emerge as a powerful solution.

In today’s API-driven world, organizations are increasingly adopting both synchronous and asynchronous communication patterns to build scalable and responsive applications. However, managing these APIs often leads to duplicated efforts, especially when defining API specifications separately for RESTful (OpenAPI) and event-driven (AsyncAPI) architectures. This article dives deep into the challenges and best practices of unifying OpenAPI and AsyncAPI specifications by designing reusable JSON schemas and examples, based on insights shared by experts in the API community.

We will explore how to avoid duplication, maintain consistency, and streamline the API lifecycle—from design to implementation and evolution—while providing developers with tools to ensure conformance and sandbox testing. Along the way, practical examples and demonstrations will illustrate how to leverage shared schemas to accelerate development and improve API quality.

We all want to build great APIs—but what exactly makes an API great? Is being RESTful enough? Is it always necessary to achieve Level 3 of the Richardson Maturity Model? What about principles like the Robustness Principle (Postel’s Law) or Hyrum’s Law, which expose the deeper challenges of designing APIs that are both resilient and predictable? How do these principles align with modern practices like the API Design First approach, where good API design is at the core of building adaptable systems? If these questions have been keeping you awake at night, this workshop is for you.

In this session, we’ll explore the principles and values that guide the design and development of great APIs. We’ll tackle the deeper challenges of creating APIs that are resilient and predictable by avoiding key anti-patterns—such as misused HTTP methods and hidden inter-parameter dependencies—that can make APIs harder to use, scale, and maintain. Furthermore, we’ll discuss how to shift-left the identification of breaking changes to the API design phase itself.

Through hands-on exercises and real-world examples, participants will learn to diagnose API design smells and apply practical strategies to fix them.

Are your APIs leaving you worried about data loss, data corruption, security vulnerabilities, or poor user experiences? If so, this talk is exactly what you need to address these issues. Discover how you can leverage your API specifications—like OpenAPI, AsyncAPI, and GraphQL SDLs—to test and enhance the resiliency of your APIs with a completely #NOCODE approach.

In this talk, you’ll gain insights into the importance of API resilience and how to build APIs that can gracefully handle flaky dependencies in real-world scenarios. We’ll explore the role of contract testing in ensuring resilience and demonstrate how to transform API specifications into executable contracts that can be continuously validated. You’ll see how to set up resilience tests, including those for latency, errors, and unexpected disconnections. The session features live demos on configuring tools to simulate these conditions, interpret the results, and iteratively enhance your API designs.

Error handling in software design often devolves into procedural code riddled with nested conditionals and complex workflows, making systems hard to test, maintain, and scale. Railway Oriented Programming (ROP) offers a structured, functional paradigm that clearly separates success and failure paths, enabling developers to simplify workflows and build more maintainable systems. This talk takes a step-by-step approach to refactoring procedural Kotlin code into a declarative, functional style using Kotlin and Arrow KT.

Drawing from my experience with Kotlin in Specmatic, we will explore real-world examples that highlight how Kotlin’s type system, extension functions, and immutability features can simplify error handling and empower developers to build maintainable, predictable systems. A special focus will be placed on the practical application of the Either monad in this context. Attendees will walk away with actionable steps to refactor procedural code into functional pipelines, improving readability, testability, and maintainability.

How confident are you that your APIs can handle spurious inputs? Did you know a significant number of API security issues stem from inadequate input validation? What if I told you that you can test your API’s resilience—without writing any tests by hand —and instead just leverage your OpenAPI specifications to generate tests and run API resiliency tests on the fly? In this session, we’ll dive into how you can leverage your API specifications such as OpenAPI to generate edge-case tests inspired by mutation and property-based testing, validating both expected and unexpected scenarios effortlessly. Let your API spec do the heavy lifting—ensuring your APIs are not just functional, but also robust and secure.

Are you interested in migrating smoothly from AsyncAPI 2.6.0 to AsyncAPI 3.0.0 while getting an in-depth understanding of the request/reply pattern for contract testing and mocking? This is the talk for you. In this session we demonstrate safe migration strategies and highlight the power of leveraging AsyncAPI Spec as executable contracts.

In today's digital landscape, APIs are the backbone of modern software applications, enabling seamless integration and data exchange between various systems and services. However, as the number of APIs continues to grow exponentially, managing their interop and governing their compliance becomes a critical challenge. Traditional API governance approaches are usually relying on manual processes and often lag behind development cycles, leading to release delays, inconsistencies, and increased technical debt.

This real-world experience report will share a set of transformative strategies that helped us elevate our DevEx by an order of magnitude, while simultaneously helping us shorten our cycle times by 50%.

We delve into the principles of "shift-left" API governance, a proactive approach that integrates governance early in the development cycle, ensuring faster, more secure, and compliant API integrations. By starting with a collaborative API Design first approach followed by contract testing in service provider's CI pipeline, teams can identify and mitigate risks sooner, streamline workflows, and foster a culture of collaboration, accountability and innovation. This helps them unlock unprecedented developer productivity and accelerate their release cycles.

Key highlights of the talk include:

• Exponential Improvement in DevEx: Learn how to enhance API development using industry-leading tools and processes that result in a 10x improvement in developer satisfaction and productivity.
• Shift-Left Governance: Discover the mechanics of implementing shift-left practices in API governance, enabling earlier detection of integration issues, reduced rework, and accelerated time-to-market.
• Halving Cycle Time: Uncover the strategic and technical adjustments necessary to reduce cycle times by 50%, transforming the speed at which products reach the market without compromising quality.
• Real-World Applications: Gain insights from successful real world implementations where these principles have been applied, showcasing tangible outcomes and lessons learned.
• Future-Proofing Your API Strategy: Equip yourself with the knowledge to not only improve current processes but also to adapt to future challenges and opportunities in API development.

Join us for an enlightening session that promises not only to inspire but also to equip you with practical tools, practices and insights to revolutionize your API design, development and governance strategy. Whether you're a developer, a technical leader, or a product manager, this talk will provide valuable perspectives on enhancing DevEx, streamlining governance, and achieving remarkable efficiency gains.

Are you having to wait until the integration or workflow testing environment to validate user journeys? What if I told you that you can shift left and test entire workflows right on your local machine and in your CI pipeline, leveraging OpenAPI specifications for stubbing APIs? In this experience report, we will explore how API spec driven HTTP stubbing can revolutionise your testing strategy by enabling comprehensive component workflow testing early in the development cycle. For example, how you can go about testing entire user login journey with OTP, including error scenarios like invalid code, timeouts, etc. right from the comfort of your local machine. And the joy of being able to independently develop and test your Front End without having to wait for Back End. Wait, there is more, and these component workflow tests can be run on Android, iOS and Web, with Teswiz. Join me to learn more about how we were able to achieve this at MyJio.

Unlock the full potential of shift-left testing by liberating your System Under Test (SUT) from real-world dependencies in your component tests using Selenium or Appium. This presentation delves into techniques for stubbing and mocking HTTP services, Kafka streams, and database interactions, enabling developers, SDETs and QAs to run robust and fast tests directly within their local and CI environments. In this demo of service virtualisation and fault injection, attendees will learn how to create high-fidelity simulations that facilitates early defect detection to streamline the development process.

Tired of dealing with seemingly innocuous data type mismatches, missing parameters, etc. in API signature that wreak havoc on MicroServices deployments late in the development cycle?

Join us in this talk where we will share our experience about how we leverage API Specification Standards such as OpenAPI to identify such compatibility issues early in the development cycle and in the process effectively eliminating integration tests. We will also be sharing our journey about how necessity drove us to come up with the “Contract Driven Development” approach and Specmatic, an open source tool that embodies the same to promote collaboration among teams, lower cycle time and deploying services independently.

Today, with the explosion of microservices and a plethora of protocols, ensuring in an automated manner that the API implementations actually adhere to their contracts is almost impossible. And on the other side, the consumers of these APIs have to hand-code the API stubs (poor man's service virtualization), with no guarantee that the stubs actually adhere to their OpenAPI specifications. All of these gaps manifest as integration bugs late in the cycle.

If these problems sound familiar, then this session is for you to understand how to leverage the very same OpenAPI specifications, so that they can be turned into contract tests and stubs without writing a single line of code.
Takeaways
Attendees will learn the following:

As an author of an OpenAPI spec, you would like to ensure that the API developer who will implement this API is adhering to the contract. Learn how to author OpenAPI specs which can verify that the API is implemented correctly.
As a consumer you often need to stub out your API dependencies while developing and testing your component. Learn how to set expectations that actually adhere to the contract, and thereby avoid late integration issues.

Tired of dealing with seemingly innocuous data type mismatches, missing parameters, etc. in API signature that wreak havoc on MicroServices deployments late in the development cycle?

Join us in this talk where we will share our experience about how we leverage API Specification Standards such as OpenAPI to identify such compatibility issues early in the development cycle and in the process effectively eliminating integration tests. We will also be sharing our journey about how necessity drove us to come up with the “Contract Driven Development” approach and Specmatic, an open source tool that embodies the same to promote collaboration among teams, lower cycle time and deploying services independently.

Does your team have to deal with performance issues very late in their development cycle? Does this lead to a lot of unplanned work in your sprints? What if I told you, that your team can validate various performance-related hypotheses right within your sprints? Yes, this is what we have been practising on various teams. Participate in this workshop where I will share our experience and to learn the techniques involved through hands-on exercises.

Problem Statement: Performance Testing has traditionally been an activity that is done in a staging or prod environment (for the brave) by a team of expert performance testers. In my experience, this approach has several issues.

• Typically high cycle time (time taken between code changes and these changes being deployed and tested in Perf Test Env) between test runs. This means Developers cannot experiment quickly.
• The test design may be disconnected from the system design because the people who test it may not have a deep understanding of the application architecture.
• Performance benchmarking and tuning becomes an afterthought, instead of being baked into our design and constantly validated during the development process

Solution: Apply "Shift left" to your Performance Testing

• Enable Developers to run Performance Tests on their machines so that they can get immediate feedback as they make code changes.
• Identify issues early and iterate over solutions quickly.
• Only defer a small subset of special scenarios to the expert team or higher environments.

Talk is cheap, show me code
I will be sharing the learnings that I gained in the process of applying Shift Left principle to "API Performance Testing" and how we codified the approach into a re-usable open-source framework called Perfiz so any team can take advantage of it.

Topics that will be covered

• Challenges running performance tests early in the development cycle
• Few examples to see Shift Left in action
  • Hypothesis Invalidation Strategy. A scientific approach to reducing dependence on higher environments
  • Avoiding premature performance optimisations and moving to data driven architecture decisions with rapid local performance testing
• What makes a good API Performance Testing framework? - In the context of Shift Left
  • It is containerised, runs well on local laptop and in higher environments or in hybrid mode
  • Leverages existing API test instead of duplicate load test scripts
  • Helps Developer express load as a configuration DSL without having to learn yet another tool
  • Not just a load generator, it collects data, has pre-set dashboards with basic metrics
  • It is code and not documentation
• What makes a good performance test report? - In the context of Shift Left
  • To begin with it should be a live monitoring dashboard and not an after the fact report
  • It is visual (graphs and plots) rather than tabulation
  • Merges Load Data and Application performance metrics in a single visual representation over a shared time series based x-axis so that the correlation is clear
• Perfiz Demo - An open source tool that embodies the above thought process
  • API test to Perfomance Test Suite in less than a minute with just YAML Config
  • Pre-built Grafana Dashboards to get you started
  • Containerised setup to get you going without any local setup with Docker
  • Prometheus and other monitoring tool hooks to monitor app performance
  • Perfiz in Higher Environments
  • Perfiz Architecture Overview and how you can extend, adapt and contribute back to the community
• "Shift Left" limitations - Repeatability, My machine vs your machine, etc.

Do your technology and product decisions involve a lot of guesswork? Has this led to anxiety about possible failure? Attend this talk where I share my experience leveraging a hypothesis driven learning oriented approach to de-risk such scenarios. "Continuous Evolution Template" embodies this approach to help achieve better clarity at an individual level and helps keep stakeholders involved in the process.

Problem Statement: As experienced Engineers, we are expected to make decisions with very little upfront information. However jumping from Problem to Solution based on guesswork can lead to

• Poor outcomes (suboptimal or excessive designs)
• In retrospect these instinct based decisions can look quite irresponsible despite best intentions
• High Anxiety levels at team and individual level because guesswork leaves a lot of room for unexpected failures late in the cycle.
• Poor predictability for stakeholders

Solution: We need a way to prevent the guesswork while facilitating a scientific approach to solutioning. Continuous Evolution Template encourages this by providing a lightweight structure around hypothesising and learning to minimise guesswork. It also helps better articulate our thought process in arriving at a solution. I came up with this template as a mechanism to add basic rigour in listing Problem Statements, Hypotheses, Design Experiments etc. and we have been using this on several projects. In this talk I will be sharing my experience with some real world examples where it was immensely helpful.

Topics that will be covered

• Understanding the urge to solution without detailed analysis - How to counter these?
• Hypothesis 101 - Quick recap of your science class and how it relates to Software Architecture and Design Decisions
• Authoring Hypothesis - analysing problem statements without the pressure of solutioning
• Designing Fail / Learn Fast Experiments to validate / invalidate Hypothesis - selecting metrics, success / failure criteria, limiting variables
• Learning from the experiment and feedback into Hypotheses list
• Continuous Evolution Template - Templatizes the above techniques in spreadsheet format. Understanding the columns in the template and how to populate them with examples.
• Applying Continuous Evolution Template to various types of problems - Technology (Tech Debt Management, Database Optimisation, Scaling, etc.) and Product (Feature Progression, Conversion Optimisation)
• Keeping cycle time under control with Hypothesis and Experiments
• Involving all stakeholders in the process to improve visibility on progress while we are narrowing down on a Solution

Does your team have to deal with performance issues very late in their development cycle? Does this lead to a lot of unplanned work in your sprints? What if I told you, that your team can validate various performance-related hypotheses right within your sprints? Yes, this is what we have been practising on various teams. Attend this talk where I will share our experience.

Problem Statement: Performance Testing has traditionally been an activity that is done in a staging or prod environment (for the brave) by a team of expert performance testers. In my experience, this approach has several issues.

• Typically high cycle time (time taken between code changes and these changes being deployed and tested in Perf Test Env) between test runs. This means Developers cannot experiment quickly.
• The test design may be disconnected from the system design because the people who test it may not have a deep understanding of the application architecture.
• Performance benchmarking and tuning becomes an afterthought, instead of being baked into our design and constantly validated during the development process

Solution: Shift left your Performance Testing.

• Enable Developers to run Performance Tests on their machines so that they can get immediate feedback as they make code changes.
• Identify issues early and iterate over solutions quickly.
• Only defer a small subset of special scenarios to the expert team or higher environments.

Talk is cheap, show me code: I will be sharing the learnings that I gained in the process of applying Shift Left principle to "API Performance Testing" and how we codified the approach into a re-usable open-source framework called [Perfiz](https://github.com/znsio/perfiz) so any team can take advantage of it.

Join us for a deep dive into the nuances of breaking a large complex system into smaller independently scalable MicroServices. This will be a hands on workshop that will introduce you to the MicroServices ecosystem.

MicroServices as an architecture pattern does not guarantee characteristics such as composability, maintainability, resiliency and fault tolerance. It only facilitates our thinking around these aspects better. We will be sharing the design principles that we have learned and applied to achieve these characteristics.

In this workshop we will be building a Cloud Native MicroServices application from the ground up. In the process will be introducing below concepts and discuss advantages, disadvantages, alternative approaches etc.

• Gateway/edge services
• Service discovery
• Load balancing
• Inter-service communication and protocols
• Circuit breaker pattern
• Autoscaling

We will be using SpringBoot to build the application and Pivotal Cloud Foundry to deploy the same. However the concepts are platform agnostic.

All code samples will be available on GitHub. Please feel free to bring your laptops and join us for the ride.