MapnosticsDOCS
← Back to Main Site
Docsβ€ΊIntegrationsβ€ΊAPI Flow
πŸ”€

API Flow

Every integration crossing your repository's boundary, on one diagram. The Code Map's Routes panel lists your endpoints; the Data Flow panel on the Dashboard knows input arrives. Neither shows the outbound half, and neither shows the data on either side of a call β€” that is what API Flow is for.

How it works

The scan reads your source for HTTP calls in both directions and draws four kinds of node:

  • Inbound from β€” a client or an external service calling into your application.
  • Our endpoint β€” a route your application exposes.
  • Our module β€” internal code between an endpoint and an outbound call.
  • Outbound to β€” a service your code calls out to.
NOTE
An arrow means one component calls another. It does not mean one runs before the other, and a call to one of your own endpoints is drawn as an arrow into that endpoint β€” never as a separate service.

The tab

mapnostics.com/repo/mapnostics-app/api-flow
API Flow

Inbound and outbound integrations, and the data crossing each boundary

An arrow means one component calls another. It does not mean one runs first.

All integrations
Rescan
Inbound from
API clients
12 callsopen β†’
Inbound from
Stripe
3 callsopen β†’
Our endpoint
/api/tickets
2 endpointsopen β†’
app/api/tickets/route.ts
Our endpoint
/api/webhooks/stripe
1 endpointopen β†’
app/api/webhooks/stripe/route.ts
Our module
tickets/repository.ts
9 callsopen β†’
lib/tickets/repository.ts
Outbound to
api.stripe.com
6 callsopen β†’
Outbound Β· URL not static
Runtime-built URL
2 callsopen β†’
Inbound fromOur endpointOur moduleOutbound toURL not static

Reading the legend

The rule across the top of each card carries the meaning, and the legend at the bottom of the canvas names all five states:

  • Grey β€” inbound from a client the scan cannot further classify.
  • #0079B6 β€” one of our own endpoints.
  • Dark β€” an internal module sitting between an endpoint and an outbound call.
  • #008446 β€” an outbound call to an external service.
  • Dashed red β€” the call target is built at runtime rather than a literal URL, so the scan could not resolve which service it reaches.

The call inspector

Click any node to open its detail panel. For each call it lists the payload out and the payload back β€” never the file path or line number, so the payloads stay above the fold even on a component with several calls. Wording follows the direction from your repository's point of view: on your own endpoint, a request is received and a response is sent; on an outbound call, a request is sent and a response is received.

Each payload block is a field tree with its type, marked optional where relevant. A response payload the scan could not observe directly is marked assumed β€” Mapnostics's own belief about what the other side returns, not a captured fact.

NOTE
A call with no body says so β€” β€œNo body β€” a GET carries none” β€” rather than showing an empty payload block that reads as missing data.

What it cannot see

  • A call built from a runtime value has no literal URL to resolve, so it is drawn as an unproven edge rather than guessed at.
  • The diagram is static analysis. It shows what your code can call, not what actually ran in production.
  • Middleware order and execution timing are not shown β€” an arrow is a call, not a sequence.
TIP
Run this after connecting a new external service. It is usually the fastest way to see whether a webhook handler actually validates its caller.