Integration Inventory and Interface Catalog

This guide explains how to find, document, and maintain a complete list of every external system your application depends on, and why government projects need this documentation before an ATO review or vendor incident. Engineers and technical leads at government agencies who are onboarding to an existing system, preparing an Authority to Operate (ATO) package, or planning for a vendor contract renewal will find it most useful.

TL;DR

An integration inventory is a structured list of every external system, API, data feed, or vendor service your application connects to or receives data from.

Government requires this list for ATO reviews, incident response, and data sharing agreements.

Document each integration with: what it does, what data crosses the boundary (especially PII), who owns the contract, and what happens if it goes down.

Outdated inventories are nearly as dangerous as no inventory at all — build in a quarterly review process.

Some integrations require a Privacy Impact Assessment or a Memorandum of Understanding before they are legally authorized.

Integration Inventory Fundamentals

An integration inventory is a structured record of every external system that your application depends on or sends data to. “External” means anything outside the boundary of the application itself — a third-party API, a state agency database, a vendor-hosted service, a federal identity provider, or even an internal service owned by a different team with its own security boundary.

The inventory answers four questions for each connection:

What is the system, and who operates it?
What data flows between your application and that system?
What controls protect that data in transit and at rest?
What happens to your users if that system is unavailable?

An integration inventory is not the same as a network diagram or an architecture diagram, though it complements both. The inventory is a living operational document. It should be readable by a non-engineer — a contracting officer, a privacy officer, or a security auditor — without a technical decoder ring.

Government Compliance Obligations

Government applications have specific obligations that most commercial applications do not. Each of the scenarios below illustrates why an up-to-date integration inventory is not optional — it is operational infrastructure.

During an Incident

If a vendor API goes down at 2am and users cannot log in or submit applications, your team needs to know immediately: who operates the affected system, what the support contact is, and whether there is a fallback. An integration inventory gives you that information in seconds instead of hours.

During an ATO Review

An Authority to Operate requires security reviewers to assess the full system boundary. That means every external connection must be documented, with a description of what data crosses the boundary and what controls are in place. Security assessors will ask for this list. If you cannot produce it, the ATO is at risk.

During a Vendor Contract Renewal

Contracting officers and program managers need to know what depends on a given vendor before deciding whether to renew, renegotiate, or replace the contract. An integration inventory makes the impact of a vendor change visible to decision-makers.

For FISMA Compliance

FISMA requires agencies to document system boundaries and the information flows that cross them. An integration inventory is a core input to your System Security Plan (SSP) and your data flow diagrams. NIST SP 800-53 CA-3 (System Interconnections) requires formal agreements for connections between systems at different authorization boundaries.

Required Fields per Integration

For each external integration, record the following fields.

Field	Description	Example
Name	Short identifier for the integration	Login.gov SSO
Vendor / Operator	Who runs the system	General Services Administration (GSA)
Purpose	What your application uses it for	Citizen authentication and identity verification
Integration type	How the connection works	SAML 2.0 / OpenID Connect
Data sent to vendor	What your app sends outbound	Session initiation request, no PII
Data received from vendor	What comes back inbound	Verified user identity attributes (name, email, IAL level)
PII / PHI flag	Does PII or PHI cross this boundary?	Yes — identity attributes are PII
Data classification	Sensitivity level of exchanged data	Controlled Unclassified Information (CUI)
Authentication method	How the connection is secured	SAML assertion, signed with GSA’s certificate
Contract / agreement owner	Who owns the relationship	Program Manager, Benefits Division
Agreement type	What legal instrument covers the connection	Interagency Agreement (IAA)
SLA / uptime expectation	What availability is promised	99.9% uptime (per Login.gov SLA)
Fallback if unavailable	What users see if the system is down	Login page shows maintenance message; no access to authenticated features
FedRAMP status	Is the vendor FedRAMP-authorized?	Yes — FedRAMP High authorized
Last reviewed date	When was this entry last verified?	2026-03-15
Notes	Any caveats, known issues, or pending actions	DSA amendment pending legal review

Integration Types and Why They Matter for Resilience

Not all integrations fail the same way. Understanding what type of integration you have helps you plan for failures and set user expectations.

Type	How it works	Typical failure mode	Resilience approach
Synchronous REST API	Your app calls the vendor; waits for a response before continuing	Slow responses block your users; vendor outage blocks your app	Circuit breaker, timeout, fallback message
Asynchronous queue / event	Your app sends a message; the vendor processes it later	Messages pile up; processing is delayed, not blocked	Dead-letter queue, retry policy, monitoring
Batch file transfer	Files are exchanged on a schedule (SFTP, S3)	File is late, malformed, or missing	Validation on receipt, alerting on missing files
Webhook push	The vendor sends events to your app when something happens	Your app is unreachable; vendor retries or drops	Idempotent handlers, signature verification, logging
Database replication	A copy of the vendor’s data is kept in your system	Replication lag; stale data in your system	Replication lag monitoring, staleness alerts
SSO / identity federation	The vendor handles login; your app trusts their assertions	Users cannot log in during vendor outage	Maintenance page, session caching where authorized
Embedded script / SDK	Vendor-provided JavaScript or library runs in your app	Script failure breaks your UI; third-party cookies blocked	Subresource integrity (SRI), graceful degradation

The integration type also determines what security controls apply. A synchronous REST call that sends PII needs TLS 1.2 or higher and request signing. An embedded third-party script raises supply chain risk — if the vendor’s CDN serves a compromised script, it runs in your users’ browsers.

How to Discover Integrations You Did Not Know About

Legacy government systems often have integrations that were never formally documented. Use these discovery methods before finalizing your inventory.

Search the Codebase for Network Calls

# Find all fetch, axios, and HTTP client calls in the codebase
rg --type ts --type js "fetch\(|axios\.|http\.get|https\.get|request\(" src/

# Find hardcoded URLs and domain names
rg --type ts --type js "https?://" src/ | grep -v "localhost"

# Find environment variable names that look like endpoints or API keys
rg "API_URL|API_KEY|ENDPOINT|BASE_URL|SECRET|TOKEN" .env.example

Review Environment Variables

Every .env.example, .env.template, or secrets manager entry is a clue. API keys imply a vendor. Endpoints imply a connection. Walk through every environment variable and ask: what service does this belong to?

Review Network Egress Rules

If your infrastructure has egress firewall rules or security group rules that allow outbound traffic to specific IP ranges or domains, those rules are an inventory of what your system is allowed to talk to. Compare them to your documented integrations — any gap is an undocumented integration.

Interview the Original Deployment Team

The original engineer often has integrations in their head that were never written down. Set up a 30-minute interview and walk through: “What does this system call? What does it receive? What would break first if we shut off internet access for an hour?”

Review Infrastructure-as-Code and CI/CD Configuration

Terraform, Helm charts, and CI/CD pipeline configuration files often contain vendor API keys, webhook URLs, and service account credentials that point to external integrations.

The Vendor Disappears Test

For each integration in your inventory, answer this question:

What happens to your users if this vendor goes down for 24 hours? For one week? Permanently?

This test surfaces your actual dependencies versus your theoretical ones. Some integrations are on the critical path — if they go down, the application is effectively down. Others are nice-to-have — the application degrades gracefully.

Classify each integration:

Critical path: Application cannot serve its core function without this integration. Examples: identity provider (users cannot log in), payment processor (users cannot pay).
Degraded: Application continues to function but with reduced capability. Examples: analytics service (usage data is lost but users are not affected), notification service (emails are delayed).
Non-critical: Application continues normally. Examples: A/B testing service, telemetry SDK.

For critical-path integrations, you need a fallback plan. For permanently unavailable vendors, you need a replacement plan. Document both in your runbook.

ATO Boundary Documentation

Every integration that crosses a system authorization boundary must appear in your ATO package. The relevant NIST SP 800-53 control is CA-3 (System Interconnections). For each cross-boundary connection, you typically need:

An Interconnection Security Agreement (ISA) — a document signed by the authorizing officials of both systems describing the connection, the data, and the controls.
A Memorandum of Understanding (MOU) — a higher-level agreement between the two organizations describing the purpose and terms of the connection.

In practice, GSA and other federal agencies provide standardized template agreements. Check with your agency’s Information System Security Officer (ISSO) for the required templates before starting a new integration.

For integrations with state agencies or local governments, the legal instrument is often a Data Sharing Agreement (DSA). DSAs typically require legal review and can take weeks or months to execute. Plan accordingly — do not build an integration with a state agency database and then discover you need a DSA after the fact.

Integration Inventory Template

Use this table as the starting point for your inventory. Maintain it in a format that non-engineers can read — a shared spreadsheet or a Markdown table in your team wiki is more accessible than a JSON file in your codebase.

Name	Vendor	Purpose	Type	PII?	Auth Method	Contract Owner	Agreement	FedRAMP	Fallback	SLA	Last Reviewed
Login.gov SSO	GSA	Citizen authentication, identity verification	SAML 2.0 / OIDC	Yes — identity attributes	Signed SAML assertions	Jane Smith, PM	Interagency Agreement	High	Maintenance page; no authenticated access	99.9%	2026-03-15
State Eligibility API	VA DMAS	Real-time eligibility lookups for Medicaid	Synchronous REST	Yes — SSN, DOB, Medicaid ID	mTLS + API key	Tom Lee, Contracts	Data Sharing Agreement	Not applicable (state system)	Return cached eligibility status (max 24h stale); queue recheck	99.5% during business hours	2026-02-01
Stripe (Payment Processing)	Stripe, Inc.	Processing benefit repayment transactions	Synchronous REST	Yes — payment card data (PCI-scoped)	API key (restricted mode)	Finance Division	Merchant agreement	Moderate	Show “payment unavailable” message; allow retry	99.99%	2026-04-10

Figure 1 (placeholder) — A system integration map for a government benefits portal. Show the portal application in the center. Draw connections to: Login.gov (SSO/authentication, SAML), a state agency eligibility database (REST API, PII), a document storage service (S3-compatible API, files), a payment processor (REST API, PCI-scoped), a federal reporting system (batch SFTP, aggregate data only, no PII), an email notification service (SMTP/API, minimal PII). Label each connection with the integration type, data classification, and direction of flow. Use color coding: green for FedRAMP-authorized, yellow for needs review, gray for on-premise.

Keeping the Inventory Current

An integration inventory that is out of date is nearly as dangerous as no inventory at all. During an incident, a stale entry sends your team to the wrong vendor contact. During an ATO review, a missing entry means an unauthorized connection.

Trigger events that require an update

A new vendor or external service is added to the system.
An existing integration changes its authentication method, data schema, or endpoint URL.
A vendor announces end-of-life or a pricing change that may trigger a replacement decision.
A security incident involves a vendor or a connection listed in the inventory.
A Data Sharing Agreement or Interagency Agreement is signed, amended, or expires.

Quarterly review process

Assign one engineer as the integration inventory owner. Each quarter, that engineer:

Walks through every entry and confirms it is still accurate.
Runs the discovery methods listed above to check for undocumented integrations.
Confirms that all required agreements are in place and not expired.
Presents the inventory to the ISSO or security team for sign-off.
Updates the last_reviewed date for each entry.

Government-Specific Considerations

Privacy Impact Assessments

Any integration that involves the collection or transmission of PII may require a Privacy Impact Assessment. PIAs are required under the E-Government Act of 2002. Your agency’s privacy officer determines whether a new integration triggers a new PIA or an update to an existing one. Start the conversation early — PIAs take time.

FedRAMP Authorization

If your application is hosted on infrastructure that requires a FedRAMP authorization (or if your application itself is being authorized), every cloud vendor in your inventory needs to be FedRAMP-authorized at the same or higher impact level. An unauthorized vendor in your ATO package is a finding. Check vendor FedRAMP status at marketplace.fedramp.gov.

Data Residency Requirements

Some states and some data types (veteran health data, tribal data, certain education records) have legal requirements about where data can be stored or processed. If your integration sends data to a vendor’s cloud service, confirm that the data does not leave a required geographic boundary.

Legacy System Integrations

Many government systems still exchange data via mainframe batch files, SFTP, or flat-file formats. These are valid integrations and belong in your inventory. They often have unique failure modes — a file that arrives with a different row count than expected, or a file that does not arrive at all — and the monitoring story for batch integrations is different from API monitoring.

In government, legal agreements between agencies or between an agency and a vendor can take weeks or months to execute. If your project plan assumes you can start exchanging PII with a state agency next week without a signed DSA, that plan is wrong. Identify required agreements at the start of the engagement, not at the end.

Next Steps

Async Systems Decision Guide — Once you have catalogued your integrations, use this guide to choose the right integration pattern for each one.
Architecture Diagrams 101 — Turn your integration inventory into a visual system map.
Data Flow Diagrams 101 — Document how PII moves through your system to satisfy Privacy Impact Assessment requirements.