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. Eighteen routes, and sixteen of them are open to the key you already put in your page.
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.
An Atom feed on every public changelog. Added on 14 September 2026, answered at the changelog's own address and declared in the page head, so a reader's feed application finds it. It is in the code rather than on the servers today and arrives with the next release.
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?
Voters and revenue. Not feedback.
This is the sentence most likely to save you a wasted afternoon. All three import paths bring in people and the money attached to them. None of them brings in features, requests, comments or votes from another tool.
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.
We would rather write that here than have you discover it after signing up. If carrying an existing board across matters, ask us before you start rather than after.
What is the single sign on, precisely?
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.
We checked the codebase rather than relying on memory, and 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 we are not going to.
What would I build against the API?
The honest 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?
Almost nothing, and the earlier version of this page got that wrong in the expensive direction.
Sixteen of the eighteen routes answer to the published embed key, which is the same key the widgets use, and that works on the nine dollar plan.
Reading your board, listing and filtering features, voting, commenting and suggesting are all in that set. If what you want is a native application or a script that talks to your own board, the smaller plan reaches it.
The two that read voters and per feature revenue need the secret key and PRO at thirty nine, because those two are the only place money leaves the account.
The two keys are worth keeping straight. The embed key is safe in a page and is meant to be seen. The secret key is not, and the only thing it reaches is the money.
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.
