Written by
Sarah Nguyen
Published on
Sep 15, 2025
Share
Why integrations became essential
At first, most people used the platform exactly as we built it. They logged in, created projects, checked metrics, and exported reports. But as adoption spread, something shifted. Teams started asking not just what the platform could do, but how it could connect. They didn’t want another isolated tool; they wanted something that fit seamlessly into Slack channels, Notion dashboards, or internal BI systems.
The variety of requests made one thing clear: we could never build every connector ourselves. New tools emerge constantly, and each organization has its own ecosystem. Instead of trying to predict every use case, we chose a different strategy—give developers the keys. By exposing the right endpoints and making the API approachable, we turned the product from a closed box into an open foundation.
That decision has already transformed how the platform is used. Agencies now pull live stats into Notion for client reports. Startups set up daily performance digests in Slack. Analysts fetch project data straight into visualization tools. None of these workflows were in our roadmap, and that’s the point—the community built them.
One early adopter put it best:
“We didn’t need another dashboard. We needed your data where we already work.”
A practical example
To show how simple integration can be, here’s a TypeScript snippet that fetches performance metrics for a project:
In less than ten lines, a developer can access structured metrics. From there, the data can be pushed into Slack with a bot, displayed in a Notion widget, or synced with a spreadsheet. The flexibility comes not from the code itself—it’s just a simple fetch—but from what happens after the data arrives.
What we’ve learned so far
Watching developers extend the platform has been eye-opening. Some integrations were expected, like Slack notifications or automated reporting. Others surprised us. One team linked metrics to a physical dashboard in their office, with LED lights changing color based on performance. Another used the API to feed data into a machine learning model that predicts project outcomes.
These experiments highlight the difference between providing features and providing access. Features solve specific problems. Access lets people solve problems we couldn’t have imagined. By offering endpoints like /metrics and /projects, we stopped dictating workflows and started enabling them.
To make this concrete, here’s how we frame the value internally:
Use case | Before API | With API |
|---|---|---|
Reporting | Manual CSV | Automated |
Alerts | Not possible | Slack bot |
Client view | Email PDFs | Live stats |
The table isn’t exhaustive, but it shows the shift—from manual, delayed, and rigid processes to automated, instant, and flexible ones.
Looking forward
The API is still young, but it’s already changing expectations. Developers now ask not if something is possible, but which endpoint to call. That shift in mindset is powerful. It means the platform is no longer a fixed tool but a flexible piece of infrastructure.
Future plans include richer analytics endpoints, notification hooks, and expanded support for collaboration data. Security remains central, with strict Authorization headers and granular access controls. Documentation will keep growing with more examples, starter kits, and even community-contributed snippets.
The broader vision is simple: integrations aren’t an add-on, they’re the future. By giving developers access, we extend the platform’s reach far beyond what we could build ourselves. And each new integration—whether it’s a Slack bot, a Notion widget, or something we’ve never imagined—makes the ecosystem stronger.
Get this template!