Integrating with Other Services

Integrating with a service another team owns is usually a waiting game. Their documentation is out of date or missing, the only person who knows the edge cases is busy, and you end up discovering the real behavior by hitting it in staging. ProdE removes the dependency: the other team's code is already indexed, so you can ask exactly how their service behaves and get an answer grounded in their implementation, not in a wiki page someone forgot to update.

This guide is for when you are writing a client or consumer for a service you do not control.

Why This Works

ProdE indexes every connected repository in the organization, not just yours. That means the service you are calling is just as queryable as your own code. You are reading the source of truth (their implementation) instead of a secondhand description of it, and you can do it without scheduling time with the owning team.

Step 1: Get the Exact Contract

Before you write a single line of the client, pin down the request and response shapes precisely. Ask ProdE Chat about the specific endpoint:

• "What is the exact request body and response shape for the POST /v2/payments endpoint in the payments service? Include field names, types, and which fields are optional."
• "What does the orders service return for a successful GET /orders/{id}? Show the full response structure."
• "Which fields in the user profile response are nullable?"

Because the answer comes from the actual code, you get the real field names and types, including the ones the documentation left out.

Step 2: Map Every Error and Failure Mode

The happy path is the easy part. The integration breaks on the errors you did not plan for, so ask about them directly:

• "What status codes and error responses can POST /v2/payments return, and what triggers each one?"
• "What does the service do when the downstream provider times out? Does it retry, and how many times?"
• "Are there rate limits on this endpoint? What is returned when a caller exceeds them?"
• "What validation does this endpoint apply, and what error shape comes back on a validation failure?"

Now you can build error handling against the failures that actually happen, rather than discovering them in production.

Step 3: Confirm the Real Behavior, Not the Documented Behavior

Documented behavior and implemented behavior drift apart over time. When the distinction matters, ask ProdE what the code does:

• "Is the idempotency-key header actually honored by the payments endpoint, or only accepted?"
• "Does this endpoint return immediately, or does it process asynchronously and notify via webhook?"
• "When I send a currency the service does not support, does it reject the request or silently default to USD?"

Step 4: Let Your Coding Agent Check While It Builds

Your coding agent can query the same understanding through ProdE's MCP server, so it can verify the other service's contract as it writes the client. This keeps the integration code honest, because the agent is generating against the real interface rather than guessing.

• "Look up the orders service's GET /orders/{id} response shape and generate a typed client for it."
• "Check what error codes the payments endpoint returns and add handling for each one."
• "Confirm the field names on the auth service's token response before you write the deserializer."

If ProdE's MCP server is not connected yet, set it up for Cursor, GitHub Copilot (VS Code), Windsurf, or Claude Code.

Step 5: Copy an Existing Consumer

You are rarely the first team to call a given service. Find an existing caller and follow the established pattern instead of inventing your own:

• "Which services already call the payments endpoint, and how do they construct the request?"
• "Show me an existing consumer of the notifications service so I can follow the same retry and auth pattern."

In your editor, the find_symbol_usages tool surfaces every place a function or client is used across a repository, which makes a working example easy to find.

---

Related: For getting oriented in a service before integrating, see Onboarding a Codebase. For answering behavior questions without writing code, see Answering Product Questions.