The new foundation of software development: graph-based API orchestration

In today's interconnected software world, nearly every feature we build relies on a web of APIs. Whether you're creating a personalized shopping experience, embedding third-party payment systems, or enabling intelligent assistants, your software is only as powerful as the APIs it integrates. But sequencing these APIs—known as API orchestration—is increasingly a bottleneck.

Even as cloud platforms, frontend frameworks, and data tools have gone declarative and composable, the way we wire APIs together remains largely procedural. And that gap is becoming more painful by the day.

In this guide, we explore:

• What API orchestration is and why it matters

• The pain of traditional, procedural orchestration

• A new approach: graph-based orchestration

• How Apollo's Connectors bring this to life on top of your existing REST APIs

• Real-world stories, technical examples, and what this shift means for software teams today

Let’s dive in.

What is API orchestration?

API orchestration is the process of connecting APIs to form a cohesive user experience or workflow. It includes everything that happens between a user's action and the assembled, multi-source response they receive.

Here are just a few examples of where orchestration appears:

• Combining flight information, airline details, and airport weather data for a travel app

• Merging customer data from multiple systems into a single view

• Handling a checkout flow that interacts with inventory, pricing, tax, and payment APIs

• Coordinating multiple third-party services to fulfill an AI-generated action

Behind each of these, orchestration is doing the heavy lifting:

• Chaining: Output of one API becomes the input of another

• Parallelization: Some APIs can be called concurrently to improve performance

• Transformation: API responses are rarely shaped exactly as needed

• Resilience: Handling errors, retries, timeouts, and fallbacks

• Governance: Enforcing auth, usage limits, and logging

Orchestration is an ever-present task that organizations seem to hardly consider; but it accounts for a significant fraction of all the software development work. And it’s only growing. Postman reports that enterprise apps now rely on 25-50 APIs on average. With AI agents and composable architectures entering the mainstream, orchestration is no longer just a backend concern – it's a foundational capability.

The burden of procedural orchestration

Most teams solve this problem the traditional way: writing code.

This could be in backend-for-frontend services (BFFs), cloud functions, service meshes, or directly inside client apps. The tooling varies, but the pattern is the same: procedural logic that describes how to call each API in order, merge the responses, and shape the result.

But this approach breaks down fast:

• It's brittle. Each combination of APIs becomes a unique snowflake.

• It doesn't scale. More APIs = more code, more bugs, more maintenance.

• It slows teams down. Even small features get delayed due to orchestration complexity.

• It’s hard to reuse. Logic gets locked into specific services or endpoints.

• It limits what we build. Some ideas simply take too long to integrate.

Here’s a relatable example: You want to show delivery estimates on a product detail page. That requires knowing:

• Where the product is stocked (inventory API)

• Which fulfillment centers can ship it (logistics API)

• Delivery speed and cost (shipping API)

• User location, loyalty tier, and preferences (customer API)

That’s four or five systems, each with different auth, latency, payloads, and quirks. Stitching that together takes days or weeks, and that’s just for one UI element. Multiply that across dozens of features and hundreds of APIs, and orchestration becomes a serious tax on velocity.

Declarative patterns to the rescue

Across the stack, declarative tools have replaced imperative scripts:

• Terraform for cloud infra

• Kubernetes manifests for workloads

• React for UI

• SQL and dbt for data

In each case, we moved from describing how to do a thing to describing what we want, and letting systems do the heavy lifting.

Now it’s time for APIs to follow.

Apollo has long been a leader in GraphQL, which makes API access declarative: consumers specify their data needs in a query, and the system figures out how to resolve them.

But historically, that required exposing everything through GraphQL – a powerful approach, but one with a high up-front cost.

With Apollo Connectors, that’s no longer the case.

What are Apollo Connectors?

Apollo Connectors let you map existing REST APIs into a graph-based interface without rewriting the services. You define schemas that model your domain, and describe how existing endpoints provide data for those models.

Figure 1: Traditional API orchestration

Figure 1: Multiple REST APIs requiring custom code for integration and complex orchestration logic.

Figure 2: Graph-based API orchestration with Apollo Connectors

Figure 2: REST APIs mapped to a unified graph, enabling declarative queries and simplified integration.

Instead of code, you write a schema and a mapping configuration. The mapping describes how to extract, reshape, and connect data from your REST APIs.

This transforms you existing APIs into a unified graph, which you can compose and query declaratively.

The result? Graph-based orchestration with:

• No code (just declarative configs)

• No rewrites (your APIs stay as-is)

• No lock-in (mix with existing GraphQL services or migrate over time)

It delivers a seamless developer experience while being powered by Apollo Router 2.0 and a new high-performance query planner built specifically for reliability, resilience, and predictable orchestration of your Connectors.

Building the Graph: an aviation example

Let’s make this real, illustrating a common orchestration challenge and how Apollo solves it.

Imagine you’re building an app that shows flight tracking and airport data. You have several REST APIs that need to work together:

• Airport API: Get airport name and location

• Flight API: Get flights departing from an airport

• Airline API: Get airline info by call sign

• Weather API: Get weather for an airport

These are all separate REST endpoints, but they have shared identifiers: airport codes, flight numbers, etc. Traditionally, you'd write custom orchestration code to call these APIs in sequence, handle dependencies between them, transform responses, and combine data. This means complex logic, error handling, and maintenance headaches.

With Apollo Connectors, you don't need to write this orchestration code. Instead, you can build a graph declaratively from the entities that already exist in your APIs. Here's how:

Step 1: Define the graph schema

type Airport @key(fields: "code") {
  code: String!
  name: String
  weather: Weather
  outboundFlights: [Flight]
}

type Flight @key(fields: "id") {
  id: ID!
  origin: Airport
  destination: Airport
  airline: Airline
}

type Airline @key(fields: "callSign") {
  callSign: String!
  name: String
}

type Weather {
  temperature: Float
  windSpeed: Float
}

Step 2: Map REST APIs to the schema

You write connector configs that tell Apollo how to:

• Fetch airport data by code

• Fetch flights by origin

• Fetch weather by airport ID

• Rename fields, flatten structures, and join IDs

You only do this once. Now your graph is live.

Step 3: Write a query

query {
  airport(code: "BOS") {
    name
    weather {
      temperature
    }
    outboundFlights {
      destination {
        name
      }
    }
  }
}

Apollo handles the rest:

• Determines which APIs to call

• Sequences them correctly

• Executes in parallel where possible

• Combines and reshapes the response

You write intent, not logic.

Performance, defer, and reliability built in

Apollo Router 2.0 brings production-grade orchestration to life:

• 10x faster query planning than previous versions

• 2x faster execution of typical queries

• Built-in caching, retries, and error handling

• Defer and stream support to split fast and slow fields

In one example, a query to show weather and outbound flights from an airport used three APIs. Router 2.0 executed them concurrently, delivered the first response quickly, and streamed the rest.

That kind of logic would take hundreds of lines in a backend service. With Apollo, it’s declarative and automatic.

Real-world impact: Cox Automotive

Cox Automotive (parent of AutoTrader® and Kelley Blue Book®) needed to expose a complex REST VIN decoding service. The initial effort was scoped at a year.

With Connectors, they finished in two days.

"Complex vehicle data logic that would have required extensive rewriting – and frankly, was seen as an insurmountable task – is now transformed into a few lines of declarative code." – Mark Meiller, Principal Engineer of Data Services at Cox Automotive

This wasn’t just a time savings – it unlocked functionality that previously seemed out of reach.

Why this matters

Graph-based orchestration isn’t just a more elegant solution. It’s a shift in how we think about building software:

• Faster delivery: New experiences are assembled from existing graph components

• Higher reuse: Teams query shared entities, not invent new services

• Less duplication: Logic moves from imperative code to declarative schema

• Better user experiences: Partial rendering, async queries, and streaming become easy

Even better, connectors work at any scale. You don’t need 500 APIs to see the benefits. A single team can start by composing three or four services and see massive gains.

Final thoughts

API orchestration is everywhere. It’s been hiding in plain sight, eating developer hours and adding drag to every sprint.

Graph-based orchestration flips the script. Instead of code, you declare intent. Instead of one-off services, you compose a living graph. And instead of months of effort, you ship in days.

With Apollo Connectors, it’s not only possible – it’s production-ready.

The rest of the stack went declarative. It’s time our APIs did too.

Explore More:

• Apollo GraphOS

• Apollo Connectors

• Odyssey Tutorial: Connectors

• Apollo Federation

Questions or thoughts? Drop them in the comments below or reach out on Twitter