Why we built API and webhooks into Shpd, and how they actually work

The moment we realised real syncing mattered

Before Shpd existed, we spent two years talking to app studios. They all said the same thing: feature voting should live inside your app, not on a separate website. We built the native SDKs. We shipped the push notifications. But then real customers started asking us harder questions.

One studio was running Shpd alongside their CRM, their product analytics tool, and their internal roadmap spreadsheet. Every time a feature got enough votes, a founder had to manually log in here, copy data there, update a ticket somewhere else. They weren't complaining, exactly. They were just tired.

We realised we'd built half the solution. We'd solved the problem of getting votes into your app. But we hadn't solved the problem of getting that data back out and into the tools they already trusted. So we built API access and webhooks into the Scale tier. Not because it sounded enterprise. Because it solved a real workflow.

Webhooks fire the moment something happens

A webhook is just an HTTP POST to a URL you own, fired the moment something happens in Shpd. A feature gets a new vote. A comment lands on a request. A feature ships and you want to trigger a push notification or update a ticket. You write down your endpoint URL in the Shpd dashboard, and we send you the data as JSON.

The difference between webhooks and polling the API every five minutes is enormous. Polling is lazy and expensive. Your server wakes up, asks us 'anything new?', we say 'no', and it goes back to sleep. A hundred times a day. Webhooks are efficient. We send you the payload only when it matters. You can forward it to Slack, post it to your CRM, trigger a serverless function, or dump it into a data warehouse.

For the studio with the spreadsheet problem, webhooks meant they could fire a feature vote event straight to their analytics platform. Real-time. No manual step. No founder copying numbers at 9pm.

The API gives you all the data, whenever you want it

Webhooks are event-driven. Good for 'tell me when something happens'. The API is pull-based. It's your chance to ask Shpd any question about your voters, your feature requests, your cross-app Passport identity, or your engagement. Want to see all voters who've voted on more than one app in your portfolio? The API will give you that. Want to export all comments on a specific feature request? It's there. Want to build a custom dashboard that sits inside your own app and shows which features are trending this month? Absolutely possible.

We didn't make the API complicated. You authenticate with a token, you make a REST call, you get JSON back. It's the same shape as the data you see in your founder dashboard. No surprises. No weird pagination rules. Just straightforward data access for teams who need to integrate Shpd into their own stack.

Studios on Scale tier can use both. Webhooks for real-time reactions. API calls for reporting and queries. They work together. One studio uses webhooks to push vote events into their Slack channel, then uses the API once a week to generate a metrics email for their exec team.

Why we only gave this to Scale

Every time you add a feature, you make a choice about who gets it. We built API and webhooks into the Scale tier, not into Studio or Solo. Not because we wanted to gatekeep. Because we thought about the problem it solves.

If you're running a single app with a few thousand voters, you probably don't need to sync Shpd data into five other platforms. The founder dashboard tells you everything you need. But if you're running five apps, ten apps, or thirty apps, and you're managing those votes inside your CRM, your product analytics tool, and your internal systems, then you're hitting the scale problem fast. That's when the API and webhooks become cheaper than paying someone to do it manually.

We also thought about what you'd want to build. API access isn't just for engineers copying data. We've seen studios use it to build custom voting experiences in their own app. To trigger notifications to their team when a specific voter shows up. To overlay vote counts on their internal roadmap. The API is a power tool. It belongs in the hands of teams running multiple apps.

What it doesn't do, and why that matters

The API gives you everything about votes, voters, features, and comments. It doesn't give you Attribr retention data (that's Portfolio tier, and we can't expose other people's private retention metrics via API). It doesn't store your data forever on our servers; if you need a permanent archive, you need to build that yourself. And it doesn't replace your own product analytics tool. The API hands you raw vote data. What you do with it is your job.

That line matters. We could have built more into the API. A built-in analytics engine. Feature prediction. Voter segmentation. But Shpd is a voting and roadmap tool, not a BI platform. You already have tools for that. We just wanted to get out of your way and let you use them.

The real story

Going back to that PM with the spreadsheet. We shipped API and webhooks, and they wired a webhook to their CRM. Now when a feature gets five votes, their CRM creates a task. When a feature ships, our push notification fires inside the app, and their webhook fires too. Their analytics platform gets the event. Their team sees the update. No manual work.

That's what API and webhooks are really for. Not for impressing engineers at conferences. For giving you back the hours you'd lose copying data between systems. For letting your mobile-first voting tool talk to your backend without you having to be the translator.