Marketplace Integrations: Live Data From Your Tools, On Your Architecture
Last month I watched a team debug a production incident across seven browser tabs. Datadog for metrics. GitHub for the deploy history. SonarQube for the quality gate that someone might have overridden. ArgoCD to confirm the pod was actually running the version they thought it was. And somewhere in the background, their architecture diagram sitting in another tab, perfectly accurate, perfectly static, perfectly useless for the problem at hand.
The diagram told them what the system was. It couldn't tell them how it was doing.
This isn't a tooling failure. Each of those tools is excellent at what it does. The problem is the gap between them — the constant context-switching, the mental model you have to rebuild every time you jump from one dashboard to another, the implicit question that nobody asks out loud: "Which of these seven tools is showing me the thing I actually need to see right now?"
We built Marketplace Integrations to close that gap.
The Idea
The premise is simple: your architecture diagram is already the map of your system. It's where you go to understand what exists, how things connect, what protocols they speak. Why shouldn't it also be the place where you see how things are running?
Archyl's Marketplace lets you connect external services — Datadog, GitHub, GitLab, Prometheus, SonarQube, ArgoCD, PagerDuty — and display their data as live widgets on your project dashboards. Not screenshots. Not links. Actual live data, refreshed every 30 seconds, sitting right next to your C4 diagrams.
A deployment status badge next to the container it deploys. A code coverage counter linked to the service it measures. An alert list that shows what's on fire, in the context of the architecture that's burning.
What You Can Connect
We launched with seven products, chosen because they cover the toolchain most teams already use:
Datadog — Monitor health, metric queries, active alerts, embedded dashboards. If you're already using Datadog to watch your infrastructure, you can surface that same data on your architecture workspace without duplicating a single query.
GitHub — Workflow status, open pull requests, repository stats, Dependabot alerts, secret scanning, code scanning. The security widgets alone are worth the setup — instead of checking each repo's security tab individually, you see the findings contextualized against the architecture.
GitLab — Pipeline status, merge requests, project stats, and the full security scanner suite: vulnerability analysis, SAST, secret detection, DAST. Same idea as GitHub, native to GitLab's ecosystem.
Prometheus — Instant queries for current metric values, range queries rendered as time series charts, and target health monitoring. If you already have PromQL queries for your key metrics, you can display them directly on your architecture workspace.
SonarQube — Quality gate status, project measures (coverage, bugs, vulnerabilities, tech debt), issues by severity, security hotspots, and security ratings. The quality gate widget is particularly useful: one green or red badge per service tells you instantly whether the code meets your standards.
ArgoCD — Application health and sync status, application inventories, Kubernetes resource lists, and application counts with filtering. For teams running on Kubernetes, this turns your C4 diagram into a deployment dashboard.
PagerDuty — Incident status, active incident lists, on-call schedules, service health, and incident counts. For teams managing incident response, this puts your operational alerts in the context of the architecture they affect — no more jumping between PagerDuty and your system diagram to figure out which service is actually on fire.
Each product supports multiple widget types — counters, status badges, lists, time series graphs, and embedded iframes — so you choose the right visualization for the data.
How It Works
The system has three layers:
Connections live at the organization level. An admin creates a connection by providing credentials (an API key, a token, a server URL). One connection can power widgets across every project in the organization. You can create multiple connections to the same product — say, one for your production Datadog account and another for staging.
Widgets live at the project level (or element level, or organization level). You add a widget by picking a connection, choosing a widget type, and configuring the query. A GitHub "Open Pull Requests" widget needs an owner and repo name. A Prometheus "Range Query" widget needs a PromQL expression and a timeframe. A SonarQube "Quality Gate" widget needs a project key.
The grid is where widgets live visually. It's a 12-column drag-and-drop layout with named sections. You can create sections like "Monitoring", "Security", "CI/CD", collapse them, reorder them, and resize individual widgets. Everything auto-saves.
The setup for a typical widget takes about 30 seconds. Choose connection, choose type, paste in the config, done. The widget starts fetching data immediately.
Why Widgets, Not Dashboards
We could have built a traditional dashboard product. Rows of charts, a sidebar of filters, the usual.
We didn't, because that already exists. Datadog has dashboards. Grafana has dashboards. You don't need another dashboard tool. What you need is a way to see the right data in the right context — and the context is your architecture.
A Grafana dashboard showing CPU metrics for ten services is useful. But it doesn't tell you which of those services is the API gateway, which is the payment processor, and which is the notification system. Your architecture diagram does. Putting the CPU metric on the architecture, next to the container it belongs to, means you never have to make that mental mapping yourself.
This is the same principle behind everything we build at Archyl: architecture documentation should be the single place where you go to understand a system. Not just its structure — its decisions (ADRs), its specifications (API Contracts), its deployment history (Releases), and now its operational reality (Marketplace Integrations).
Sections and Organization
We knew from the start that a flat wall of widgets wouldn't scale. When you have fifteen widgets on a project — some for monitoring, some for security, some for CI/CD — you need structure.
Widgets are organized into named sections. You create them, name them, reorder them by dragging their headers, and collapse the ones you don't need right now. Each section acts like a panel that you can open or close.
In edit mode, you can:
- Drag widgets to reposition them within a section
- Move widgets between sections
- Resize widgets from a compact badge to a full-width chart
- Drag section headers to reorder entire groups
- Create, rename, and delete sections
The grid compacts vertically, so there are no gaps. When you're done arranging, click "Done" and the layout locks in place.
Scoping: Organization, Project, Element
Not all data belongs at the same level.
Organization-wide widgets are visible across all projects. Use these for metrics that matter globally — total deployment count, company-wide SonarQube quality gate status, organization-level GitHub security findings.
Project-scoped widgets appear only in a specific project's Integrations tab. These are the most common — monitoring dashboards, CI/CD status, code quality metrics for the services in that project.
Element-scoped widgets attach directly to a C4 element. Open a container's detail panel and you see its widgets alongside its relationships, ADRs, and API contracts. This is the most powerful scope: operational data contextualized at the architectural element it belongs to.
What This Changes
Before Marketplace Integrations, understanding the operational state of a system meant opening multiple tools, cross-referencing data, and holding the mapping between "monitoring dashboard" and "architecture diagram" in your head.
After: you open one workspace. The architecture tells you what exists. The widgets tell you how it's doing. The releases tell you what shipped. The ADRs tell you why it was built that way. The API contracts tell you what the interfaces look like.
One place. One context. No tab-switching.
That's the vision we've been building toward since day one. Architecture documentation that answers real questions — not just "what is this system?" but "is this system healthy?", "is this service secure?", "when was the last deploy?", and "what's the quality gate status of this code?"
Marketplace Integrations is a big step toward that vision. And we're just getting started — more products are coming.
Getting Started
- Go to Organization Settings > Marketplace
- Connect a product (you'll need an API key or token)
- Open any project's Integrations tab
- Click Customize, then Add Widget
- Pick a connection, choose a widget type, configure, done
The whole setup takes under five minutes. Your architecture diagrams will never feel the same.
Want to see how other features bring your architecture to life? Check out Release Management for deployment tracking, or API Contracts for linking your API specs to the diagram.