Why we built APIs and webhooks into Shpd

The moment we understood the problem

The studio's product lead was copying feature request titles into a spreadsheet, cross-referencing voter counts with Amplitude cohorts, then pasting summaries into Slack. Every Friday. By hand. She wasn't unique. Over the next few months, we heard the same story from a dozen other teams: they loved voting inside the app and the push notifications when features shipped, but they needed to pipe that signal back into the tools they already relied on.

Here's what made this real: one studio's founder said to me, 'We're keeping two systems now because Shpd doesn't integrate.' That hurt. Not because he was leaving, but because he shouldn't have needed two systems in the first place.

What APIs and webhooks actually let you do

APIs are boring to write about. Webhooks are boring to read about. But the work they unlock is concrete.

With our API (available on Scale and Portfolio plans), you can query voters, features, comments, and votes programmatically. You can pull that data on a schedule, or on demand, and push it somewhere else. A studio can write a script that runs every night, fetches new feature votes from Shpd, and posts a summary to their Slack channel. Another can build a small webhook listener that triggers an internal notification when a feature request hits a threshold of votes.

Webhooks are the reverse: instead of you pulling data from us, we push an event to your server the moment something happens. A feature ships in Shpd. We POST a webhook to your endpoint. You get the notification instantly, not on the next pull. Your backend can then trigger downstream actions: email the voters, update your tracking system, queue up a notification in your app.

The outcome is what matters. Your feedback system stops being a silo. It becomes part of your product infrastructure.

Why this took us a while to build

Shpd launched in 2024 with iOS and Android SDKs because we believed mobile-first. We're still believers. But the native app experience only matters if the data flows cleanly back into the decisions your team makes. We initially thought webhooks were 'advanced' features. A few months in, we realised they were table stakes for any serious B2B SaaS product.

The technical debt was real. We had to design a webhook payload schema that would survive schema changes. We built retry logic, delivery status tracking, and a dashboard so you could inspect what was being sent. We added request signing so you could verify events actually came from us. None of it is glamorous. All of it is necessary.

We also had to make a choice about which plan it belonged on. We settled on Scale, because webhooks and the API are tools for teams ready to automate their workflows. They're not for a solo founder testing the idea. But they're not premium either. They're infrastructure.

How this actually works in practice

I'll give you a real example. A studio with five apps in our platform wanted to track which features drove the most engagement over time. They set up a webhook listener that fires whenever a feature request receives a vote. The listener logs the feature ID, the voter's app, and the timestamp to their own Postgres instance. Over six months, they've built a dashboard showing which apps generate the most voting activity, and which feature requests correlate with retention. That's data they couldn't have generated without webhooks.

Another example: a team using Attribr overlay data (available on Portfolio) wanted to surface which feature requests came from high-value, high-retention cohorts. They queried the Shpd API nightly, cross-referenced the retention scores, and sorted their backlog by a custom scoring function. Their head of product says it's saved them from shipping features that looked popular but came from low-LTV users.

These aren't contrived use cases. They're things customers actually asked for once they realised the API existed.

What doesn't change

This matters as much: building APIs and webhooks doesn't mean we've become a generic feedback tool. We're still mobile-first. Voters still vote inside your app with the native SDK. They still get a push notification when their feature ships. The public voting board still gets indexed by search engines so your community finds feature requests organically. That's the core.

APIs and webhooks just mean that core signal can now flow into the rest of your product infrastructure without manual work. You don't have to choose between having a beautiful mobile experience and having clean data integration. You get both.