Avoiding satisfiability errors with entities - The Weekly Wisdom - Edition #10

:graduation_cap: Welcome to The Weekly Wisdom

:spiral_calendar: Edition #10 - 10 Jul 2025
:label: Topic tags - connectors odyssey
:bell: Stay in the loop: Subscribe to the “The Weekly Wisdom” category to get notified when new posts drop—no FOMO here.


Hey all! :waving_hand: @Michelle_Mabuyo here from the Apollo Education team. I’m a Developer Educator and I build courses for Odyssey, our official learning platform.

I’m back for the next edition of a multi-part series to teach you the basics of Apollo Connectors: a powerful way to bring existing REST APIs into your graph, all through configuration in the schema.

:light_bulb:This week’s learning: Avoiding satisfiability errors with entities

In many APIs, different endpoints can return different subsets of the same object. A list endpoint may return just IDs and titles, while a detailed endpoint includes descriptions, coordinates, images, and more.

In the example below, featuredListings returns a list of listings, whereas listing returns detailed information about a specific listing.

So when a client requests everything through a list query, the router can’t figure out where to get those extra fields, resulting in the dreaded SATISFIABILITY_ERROR.

Enter: entities.

By marking a type with @key and assigning a Connector to that type, you give the router a roadmap. It knows how to fetch additional data to complete a query, even if the original endpoint couldn’t satisfy everything. That’s orchestration in action!

No more satisfiability errors. Just satisfied queries. :sparkles:


:magnifying_glass_tilted_right: Want to go deeper?

You’ll see this in action in the Odyssey tutorial “GraphQL meets REST with Apollo Connectors (Lesson 9)”, where we use entities to enrich listing data and avoid schema build failures.

Take the course


:speech_balloon: Share your thoughts in the thread below :down_arrow:

Have you encountered satisfiability errors before? How did you debug them?