Voting board integration pages in this category are usually a wall of logos, most of which turn out to mean somebody once wrote a Zapier template.
This one is a list of what exists, and then a list of what does not, because the second one is what you actually need before you commit. What the board itself does, as opposed to what it connects to, is every feature on one page.
What is there?
A REST API. Twenty one routes, on the PRO plan, with the two that read money behind a second key.
Read the board two ways, once by its address and once from the key alone. List features, read one in full, read its comment thread, read the changelog, read one release.
Mint a voter identity. Suggest a feature, vote, take the vote back, comment, delete your own comment, like a comment. Read the messages a voter should be shown and put one away.
The remaining two return your voters and your per feature revenue. Those are the only ones that need your secret key, and they are the only ones behind a plan.
An embed SDK. Seven widgets and two modals, on any plan, working for signed out visitors. That is the one most people mean when they say integration, because it puts the board inside your own product.
Single sign on for board voters. A signed token that identifies one of your users to your board, so their votes carry their real identity instead of an anonymous one. Four fields and one signature, in the quickstart.
Imports. Stripe, Paddle and CSV for customers and revenue. A public Canny or Featurebase board for requests and votes.
Email alerts on every public changelog. A reader leaves an address on the changelog, confirms from the email, and gets one email per release in your board's name.
A Swift package. Drop in views for iOS and macOS, published on GitHub. The quickstart, the screens and the calls are documented in full.
The demo is open with no account and no email if reading about it is not enough.
What do the imports actually import?
Stripe, Paddle and CSV bring voters and revenue. A board import brings requests.
Stripe, Paddle and CSV bring in people and the money attached to them, never requests. Imported requests come from one place: paste a public Canny or Featurebase board into Settings and its posts, statuses and vote counts come across, finished and closed ones included. Comments and voter names stay behind, so each imported vote carries a weight of one.
The Stripe and Paddle connections also keep marking people after the import, so a cancellation tells the board which requests came from customers who have already left.
So if you are moving from another product and hoping to carry your existing board across, that is not something any of these do today. Your customer list and their revenue, yes. Their three years of requests, no.
If carrying an existing board across matters, check with VoteFirst before you start rather than after.
What is the single sign on, precisely?
The single sign on, precisely, is a signed token that tells your board who a voter is. It does not sign anybody into the VoteFirst dashboard.
That distinction matters because the phrase single sign on usually means the second thing. This is not SAML, it is not an enterprise identity integration, and it will not connect to your directory.
It identifies the people voting on your board, which is what a feedback tool actually needs, and it is on the PRO plan.
Your own team signs in with a password or with Google, and they join by an invitation link that expires after seven days.
What is not there?
No Slack. No Zapier. No Intercom. No Jira or Linear sync. No outgoing webhooks of any kind.
Those names appear only in sample data. If your workflow is that a new request should appear in a Slack channel, that does not exist and you would have to build it against the API.
No Android or Kotlin package. That is a written non goal rather than a backlog item.
No AI features anywhere, which is a deliberate product decision. Several tools in this category will draft comments and release notes for you and VoteFirst is not going to.
What would I build against the API?
The answer is that most people do not need to, because the widgets cover the common case and they need no plan upgrade.
The API earns its place in three situations. When you want the board inside a native mobile application, which is what the Swift package is for.
When you want to read your voters and your per feature revenue into something else, which is what those two secret key routes are for. And when you want a workflow nobody has built, which is where the absence of Slack and webhooks becomes your problem to solve.
14 days, a card at signup, then $9 or $39 a month.
What does the API cost?
The API is the thing you call from your own code with an API key you make on the share page. That is a PRO capability and the Lite plan does not include it.
What Lite does include is the embed key, and the two are not the same thing. The embed key is the string inside the widget script tag on your own page. It is safe to publish, it is meant to be seen, and it is what makes the widgets work on the nine dollar plan. It is not a way to reach the API from a script or a native application.
Above the API key there is a secret key, which reaches your voter list and your per feature revenue and nothing else. That is the only place the money is, so it never leaves a server you control.
Three keys, three jobs, and the one sentence version is that the embed key draws a widget, the API key runs your own integration, and the secret key reads what people pay.
The documentation
The API documents itself with an OpenAPI description and a docs route, and the embed quickstart carries both install shapes with the exact markup. What the package's own screens look like on a phone is five screenshots, taken from the sample app that ships with it.
