Orbit Finds the API. Context Graph Keeps It Safe.

Adding an API to an application looks simple when you describe it as a coding task. Find the endpoint, write the request, handle the response, and ship it.

The code is usually not the hard part.

The harder part is answering two questions before the agent starts writing:

1. Which external API can actually do the job?
2. What inside our own system will this integration affect?

Those questions require two very different kinds of context.

The first lives outside the company. It is spread across public API documentation, specifications, examples, authentication guides, and provider-specific constraints. The second lives inside the company. It is spread across repositories, Postman Collections, schemas, runtime calls, event consumers, deployments, telemetry, and team ownership.

A coding agent looking at one repository has neither view. It can search the files in front of it, but it cannot reliably discover an API it has never seen. It also cannot find a downstream service in another repository, a consumer registered only at runtime, or a collection that drifted from what the application actually does.

This is where Orbit and the Postman Context Graph fit together.

Orbit helps the agent find and understand the public API it should call. The Context Graph helps it understand the private system that call is about to become part of. The Postman Claude Code plugin gives the agent the skills to turn that context into an actual change: update the collection, validate the contract, test the workflow, and carry those tests into CI.

The problem is bigger than API discovery

Suppose I am working on myhealthcare.dev, a healthcare application that manages patients, appointments, medications, and scheduling.

The application can already book an appointment internally. Now I want to check the clinician’s real calendar before confirming a slot, create an event when the appointment is booked, and send the patient an invitation.

I can ask a coding agent to add calendar integration, but the request immediately creates two separate investigations.

First, the agent needs to find an external API that supports the workflow. Searching for “calendar API” is not enough. We need to know whether an API can check availability, create an event, invite an attendee, and connect those steps correctly. We also need exact request fields, authentication requirements, response shapes, and provider-specific limitations.

Then the agent needs to understand our application. Which service owns appointment booking? Does it call another service synchronously, or publish an appointment.booked event? Who consumes that event? Which API specification and Postman Collection describe the current flow? Which tests and CI jobs will need to change? Could the new calendar check add latency to a route used by another service we do not have checked out locally?

Finding a suitable API does not answer any of those internal questions. Reading the local repository does not answer all of them either.

That is the gap.

Orbit handles the public side

Orbit by Postman searches publicly available APIs, including Postman API Network. Instead of asking the agent to guess a provider or work backward from product names, I can describe the outcome I need in plain language:

Find an API that can check a clinician’s calendar availability, create an appointment event, and invite the patient.

Orbit returns candidate endpoints and evaluates how well each one fits the task. Once I choose the endpoints, its integration step produces a task brief with the details the agent needs to implement them: base URLs, required parameters, response shapes, authentication, execution order, dependencies between calls, and common gotchas.

Orbit itself is unauthenticated. Its search and integration tools do not require an API key because they work from publicly available API information. That does not mean the third-party APIs it recommends are unauthenticated. If the selected calendar provider requires OAuth or an API key, the task brief tells the agent what that provider expects.

That distinction matters. Orbit removes the authentication barrier from discovery, not from the API being integrated.

Context Graph handles the private side

The Postman Context Graph starts from the opposite direction. It maps the APIs, services, schemas, consumers, deployments, owners, telemetry, and runtime relationships inside my organization.

Unlike Orbit, the Context Graph is authenticated. A query runs against my team’s private graph, so the agent must authenticate through Postman before it can ask questions. That is exactly what I want for information such as internal service relationships, ownership, deployments, and production behavior.

Before changing the appointment flow, the agent can ask:

What depends on POST /api/appointments and the appointment.booked event? Include runtime callers, event consumers, collections, specifications, deployments, and owners.

The graph gives the agent a map of the surrounding system, including relationships that may live outside the current checkout. The agent should still verify anything it can against source code. The graph is the map that tells it where to look, not an excuse to stop checking the code.

This is the part a better repository search cannot solve. You cannot search a repository that was never in the checkout. You also cannot infer a runtime relationship from an import graph when no build dependency exists.

What they do together

The cleanest way to think about the two products is this:

Question	Tool	Access model
What public API can perform this task?	Orbit	Unauthenticated
How do I call the selected API correctly?	Orbit	Unauthenticated discovery; the selected provider may require its own credentials
What internal systems could this change affect?	Context Graph	Authenticated to the Postman team
Which contracts, collections, tests, and CI workflows should change?	Postman Claude Code plugin	Works in the repository and uses authenticated Postman context where required

Orbit gives the agent external capability. Context Graph gives it internal context. The plugin turns both into a development workflow.

There is no automatic handoff where Orbit silently calls the Context Graph. They are separate tools with separate scopes. The useful part is that the same agent can call both in one session and reason across their results.

A Claude Code demo

Here is how I would show this with the Postman Claude Code plugin.

1. Set up the repository

Install the plugin, authenticate Postman for access to the private Context Graph, and initialize the repository:

claude plugin install postman@postman
postman login
postman init

Orbit does not need a login. The Context Graph does.

postman init gives the agent the repository-specific Postman context it needs, including where the API specifications and collections live. At this point I have not asked Claude to change any code.

2. Ask for the existing blast radius first

My first prompt is deliberately about the current system:

We are going to add external calendar conflict checking and event creation to the appointment-booking flow. Before changing anything, use the Postman API discovery skill and the Context Graph to find what currently depends on POST /api/appointments and appointment.booked. Include runtime callers, event consumers, API specifications, Postman Collections, deployments, and owners. Treat the graph results as leads and verify anything available in this checkout.

This gives Claude a grounded view of the system before it edits the route. It may discover, for example, that the appointment service publishes an event consumed by the slot service, that a frontend calls the endpoint directly, and that the checked-in collection no longer reflects the deployed behavior.

Without the graph, Claude would be limited to whatever happens to be present in the repository. With it, Claude knows which other systems and teams belong in the plan.

3. Use Orbit to find the external API

Next I ask Claude to solve the public discovery problem:

Use Orbit to find public API endpoints that can check a clinician’s availability, create a calendar event, and invite the patient. Show me the best candidates, including what each one supports and does not support. Do not choose one for me.

That last sentence keeps the endpoint decision visible. Orbit returns callable endpoints with a fit assessment, not just a list of documentation pages. I can compare the candidates and choose the provider that fits the application.

For this demo, I would select the relevant Nylas endpoints and then say:

Use Orbit’s integration step for the Nylas endpoints I selected. Build a task brief for checking availability before an appointment is confirmed, then creating the calendar event and inviting the patient. Call out the authentication requirements, values that must pass between requests, and any constraints we need to handle.

Now Claude has the public implementation details from Orbit and the private dependency map from the Context Graph.

4. Make the change with both views in scope

The implementation prompt can now be specific without forcing the agent to guess:

Implement this integration. Use the Context Graph results to preserve the existing appointment flow and update every in-repo artifact affected by the change. Update the API specification and Postman Collection, add contract and failure-path tests, and show me any off-repository consumers or owners that need a separate change or review. Do not claim those external changes were made.

This is where the combination becomes useful. Orbit tells Claude how to call Nylas. The graph tells Claude where that call fits into the existing architecture. The repository gives Claude the source of truth for the code it can actually edit.

The boundary in the prompt is important. An agent should not pretend it updated another repository or coordinated with another team. It should make the local changes, identify the work that sits outside its current authority, and leave a clear handoff.

5. Validate the contract and put the tests in CI

Finally, I ask Claude to use the plugin’s testing and CI skills:

Use the Postman API testing skill to validate the updated collection against the contract and run the appointment workflow tests. Then use the CI integration skill to add the same checks to the existing CI pipeline. Show me the files changed, the commands run, and any remaining failures.

The result is not just integration code. The contract, collection, tests, and pipeline move with the implementation, and the resulting files stay inspectable in Git.

What about a change the graph has not indexed yet?

This is the subtle part.

The Context Graph reflects the system it has already indexed. It refreshes nightly, so it will not know about a hypothetical local edit that has never been committed or ingested. That does not mean I need to merge the change, wait overnight, and only then discover whether it is safe.

I query the graph before editing to understand the current dependencies around the endpoint, event, schema, or service I plan to change. Claude then combines that existing map with the local diff it is creating. The graph supplies the known callers and consumers; the repository supplies the proposed change.

After the change is committed and the graph refreshes, the new external relationship can become part of the graph for future questions. At that point I can ask whether the collection, deployed behavior, and indexed code agree.

So the pre-merge workflow is not “make the change, wait for indexing, then check what broke.” It is:

1. Query the current graph for the blast radius.
2. Discover the public API with Orbit.
3. Make the local change with both sets of context in scope.
4. Validate the contract, collection, and tests before merging.
5. Let the next graph refresh record the new state for future work.

Why this is a better agentic SDLC workflow

None of the individual actions are new. A developer could search API documentation, inspect several repositories, update a collection, write tests, and edit a CI workflow by hand.

What changes is how much the agent has to guess.

Orbit keeps it from writing a third-party integration from memory. The Context Graph keeps it from treating one checkout as the whole system. The Claude Code plugin gives it concrete ways to update and validate the artifacts that belong with the code.

That also explains the token-efficiency argument. An agent without this context has to search broadly, read large documentation sets, and explore repositories that may or may not contain the answer. Orbit narrows the public API search to the endpoints that fit the task. Context Graph narrows the internal search to the services and relationships that matter. The model can spend its context window on verification and implementation instead of discovery by brute force.

The point is not to replace the coding agent or the tools a team already uses. It is to give the agent the two maps it was missing: one for the public APIs it can add, and one for the private system it must not break.

Orbit helps the agent find the capability. Context Graph shows it the consequences. Used together, they turn “add a calendar integration” from a local coding task into a change the agent can reason about across the full API workflow.

Resources

• Postman Context Graph overview
• Query Context Graph with an MCP client
• Postman Claude Code plugin documentation
• Orbit by Postman
• Postman API Network
• Postman Collections documentation
• Postman API specifications documentation
• Postman CLI overview
• Postman CLI collection commands
• Nylas Calendar and Events API quickstart
• OAuth 2.0 specification (RFC 6749)