API Dependency Graph
Visualize and manage dependencies between mock simulations, track impact of changes, and identify cascading failures. The dependency graph helps teams understand their mock ecosystem and make safer changes.
Prerequisites
- Multiple mock simulations in your workspace
- Understanding of simulation relationships
- Optional: Knowledge of microservices architecture
Understanding the Dependency Graph
The dependency graph maps how simulations depend on each other:
Components:
- Nodes - Simulations (shown as circles/boxes)
- Edges - Dependencies (arrows showing relationships)
- Manual Dependencies - Explicitly defined by users
- Auto-Discovered Dependencies - Found in response bodies
Dependency Types:
| Type | Direction | Meaning |
|---|---|---|
| Internal | Simulation A → Simulation B | A calls B's API |
| External | Simulation A → External URL | A calls real API |
| Bidirectional | A ↔ B | Both call each other |
Viewing the Dependency Graph
Simulation-Level View
See dependencies for one simulation:
- Open simulation
- Click Dependencies tab
- View all dependencies (manual and auto-discovered)
- See source and target simulation names
- Check dependency confidence scores
Workspace Graph
See all simulations and dependencies:
- Open workspace
- Click Dependency Graph or Architecture
- View visual graph:
- All simulations as nodes
- Dependencies as edges
- Color coding for dependency types
- Force-directed layout for clarity
Company Graph
Enterprise view across entire company:
- Go to analytics/admin area
- Click Company Dependency Graph
- See all simulations from all workspaces
- Identify cross-workspace dependencies
- Spot potential conflicts
Manual Dependencies
Explicitly define relationships between instances.
Add Manual Dependency
- Open source simulation
- Click Add Dependency
- Select target simulation or enter external URL:
{
"target_instance_id": "payment-service-id",
"type": "internal",
"reason": "Calls payment validation endpoint"
}
Or external:
{
"target_url": "https://stripe.com/v1/charges",
"type": "external",
"reason": "Real Stripe API for payment processing"
}
- Click Create
- Dependency appears in graph
Remove Dependency
Delete a dependency:
- Open dependencies list
- Find dependency
- Click Remove or delete icon
- Confirm removal
Removed dependencies are immediately removed from graph.
Auto-Discovery Scanning
Automatically find dependencies from response bodies.
Scan Simulation
Discover dependencies by analyzing responses:
- Open simulation
- Click Dependencies > Scan
- System analyzes all response bodies for URLs
- Found URLs are matched against other instances
- Auto-discovered dependencies are added
Scan Results
View what was discovered:
Scanned 12 responses in simulation "payment-service"
Discovered URLs:
✓ https://internal.surestage.io/user-service/v1/users -> user-service (MATCHED)
✓ https://internal.surestage.io/inventory-service/v1/stock -> inventory-service (MATCHED)
✓ https://external-api.example.com/validate -> (EXTERNAL)
✓ https://stripe.com/v1/charges -> (EXTERNAL)
Added 2 internal, 2 external auto-discovered dependencies
Previous auto-discovered: Removed 3, Updated 0
Review Auto-Discovered
- Go to dependencies
- Filter by "Auto-Discovered"
- Review found dependencies
- Remove false positives if needed
Auto-discovered dependencies are marked with a star or icon.
Impact Analysis
Understand who depends on your simulation.
View Impact
See which simulations would be affected if this simulation changes:
- Open simulation
- Click Impact or Dependents
- View reverse dependency tree
Impact Report:
Simulation: user-service
If this simulation changes, these simulations are affected:
Direct Dependents (1 level):
├─ payment-service (HIGH impact - 3 calls to /users)
├─ notification-service (LOW impact - 1 call)
└─ inventory-service (MEDIUM impact - 2 calls)
Transitive Dependents (2 levels):
├─ checkout-service (via payment-service)
├─ billing-service (via payment-service)
└─ reports-service (via inventory-service)
Depth 3+: 2 additional simulations
Summary:
- Direct: 3 simulations affected
- Transitive: 5 simulations affected
- Total: 8 simulations in dependency chain
Impact Depth
Check cascading failures:
- Depth 1 - Direct dependents only
- Depth 2 - Their dependents
- Depth 3 - And so on
Greater depth = greater blast radius of changes.
Dependency Health
Monitor health of dependencies.
Health Status
Check if dependencies are healthy:
- Open simulation
- Click Dependencies > Health
- See health report:
Dependency Health Check
dependency: user-service
├─ Status: HEALTHY (✓)
├─ Simulation exists: Yes
├─ Simulation active: Yes
├─ Target routes exist: Yes
│ ├─ /api/users (200 OK)
│ └─ /api/users/{id} (200 OK)
└─ Last checked: 2 minutes ago
dependency: payment-service (external)
├─ Status: DEGRADED (!)
├─ Connectivity: WARN - Response times elevated (avg 850ms)
├─ Availability: INFO - Last failure 2 hours ago
└─ Last checked: 5 minutes ago
dependency: old-inventory (removed)
├─ Status: BROKEN (✗)
├─ Simulation exists: No
├─ Action needed: Remove or update dependency
└─ Last checked: 10 minutes ago
Health Statuses:
| Status | Meaning | Action |
|---|---|---|
| Healthy | Working normally | None needed |
| Degraded | Slow/intermittent | Monitor |
| Broken | Not accessible | Fix or remove |
Common Workflows
Understanding Service Architecture
- Open Company Graph
- Review overall structure
- Identify bottlenecks (highly connected simulations)
- Spot single points of failure
- Plan improvements
Planning Safe Changes
- Make change to simulation A
- View Impact analysis
- See all affected simulations
- Test all downstream simulations
- Roll out change safely
Onboarding New Service
- Create new simulation
- Add manual dependencies to integrations
- Trigger auto-discovery to find more
- Visualize in dependency graph
- Verify all connections healthy
Migration Planning
- View dependencies for old service
- Identify all callers
- Update each to point to new service
- Verify health checks pass
- Remove old service
Incident Investigation
- Service goes down
- View impact analysis for that service
- See all affected services
- Prioritize fixes by impact
- Coordinate rollback if needed
Dependency Graph Best Practices
Keep Dependencies Accurate
- Scan regularly for auto-discovery
- Remove dependencies no longer used
- Document reasons for dependencies
- Keep external URLs current
Minimize Blast Radius
- Reduce depth of dependency chains
- Identify bottlenecks (highly connected simulations)
- Consider breaking into independent services
- Add circuit breakers/fallbacks
Monitor Dependency Health
- Regular health checks
- Alert on degraded status
- Remove broken dependencies
- Test dependent simulations after changes
Change Management
- Before changing: Check impact analysis
- During change: Monitor dependents
- After change: Run health checks
- Document changes for team
Visualizing Dependencies
Graph Visualization
The visual graph shows:
- Node size - Number of dependent simulations
- Edge thickness - Strength of dependency
- Color coding - Internal vs. external
- Force layout - Related simulations cluster
Legends:
Node Colors:
● Green - Production/stable
● Yellow - Development/staging
● Red - Deprecated/broken
Edge Types:
→ Solid - Direct dependency
⇢ Dashed - Transitive (2+ hops)
⇢ Dotted - External dependency
Filtering Graph
Focus on specific parts:
-
Click Filter in graph view
-
Show/hide:
- Internal dependencies only
- External dependencies only
- Specific simulations
- Depth N levels
-
Export graph as:
- PNG/SVG image
- JSON for analysis
- DOT format for Graphviz
Troubleshooting
Dependency Not Found
- Verify target simulation exists
- Check simulation name spelling
- Target might be in different workspace
- Use auto-discovery to find URLs in responses
Auto-Discovery Not Finding Dependencies
- Ensure response bodies contain URLs
- URL format must match simulation hostname/path
- Check simulation must exist in workspace
- Re-run scan if simulations were recently added
Health Check Failing
- Verify target simulation is running/active
- Check network connectivity
- Confirm target routes still exist
- Review error messages for details
Impact Analysis Shows Too Much
- Check for circular dependencies (A→B→A)
- Verify dependencies are actually used
- Remove false positive dependencies
- Review depth limit setting
API Reference
Dependency Management
| Method | Path | Description |
|---|---|---|
GET | /instances/:id/dependencies | List dependencies |
POST | /instances/:id/dependencies | Add dependency |
DELETE | /instances/:id/dependencies/:depId | Remove dependency |
POST | /instances/:id/dependencies/scan | Scan for dependencies |
Analysis Endpoints
| Method | Path | Description |
|---|---|---|
GET | /instances/:id/impact | Get impact analysis |
GET | /instances/:id/dependencies/health | Check health status |
Graph Endpoints
| Method | Path | Description |
|---|---|---|
GET | /dependency-graph | Company-wide graph |
GET | /workspaces/:wsId/dependency-graph | Workspace graph |
Next Steps
- Routes and Responses - Manage endpoints
- Analytics - Monitor traffic patterns
- Health Scores - Simulation quality assessment
- Team Workspaces - Organize simulations by team