← Integrations

The feature request API, and every endpoint it has

Most product pages about a feature request API say it is powerful and flexible. This one lists it, because a list is the only thing that answers the question somebody with an API in mind is actually asking, which is whether the thing they want to build is possible.

There are twenty one endpoints. Three of them need no key at all and describe the API rather than anybody's data. The rest need a key you make on the share page.

What can the API actually do?

Read a board, write a request, cast and remove a vote, read and write comments, read the changelog, read the voters, and read the revenue behind each request.

Method Path What it is for
GET board The board, for the embed
GET docs The documentation, open
GET health Whether the API is up, open
GET openapi.json The machine readable description, open
GET projects/:slug One project
GET projects/:slug/features Every request
POST projects/:slug/features File a new request
GET projects/:slug/features/:id One request
POST projects/:slug/features/:id/vote Cast a vote
DELETE projects/:slug/features/:id/vote Remove one
GET projects/:slug/features/:id/comments The thread on a request
POST projects/:slug/features/:id/comments Add to it
POST projects/:slug/comments/:cid/like Like a comment
DELETE projects/:slug/comments/:cid Remove a comment
GET projects/:slug/changelog Every release
GET projects/:slug/changelog/:id One release
GET projects/:slug/voters The people behind the votes
GET projects/:slug/revenue/features The revenue behind each request
GET projects/:slug/messages In app messages for this viewer
POST projects/:slug/messages/:id/dismiss Dismiss one
POST projects/:slug/identity Sign a viewer in from your own system

That is the whole surface as it ships, and a trial runs 14 days with a card at signup if you would rather call it than read about it.

If something you need is not in that table, it is not in the API.

The API keys panel, one key made, with the date it was created, the note that it has never been used, and one of five keys in use
API keys, five to a project, and one made so far.

Nothing here counts the people who vote, so a busy board costs the same.

What is the identity endpoint for?

The identity endpoint is for telling the board who somebody already is, so they never make a second account.

If your own application knows who the person is, you can sign them into the board from your side rather than asking them to register separately with VoteFirst.

That is what makes an embedded board feel like part of your product instead of a bolted on forum, and it is the reason the anonymous route exists as a fallback rather than as the default.

What does a key not reach?

The money, unless the key is yours rather than an embed's.

The revenue endpoint is the one that reads what customers pay, and an embed key is refused on it outright rather than returning an empty result.

An embed key lives in a public web page by definition, so treating it as equivalent to a server side key would put your customer revenue one view source away.

Every write route is checked separately from every read route, so a key that can read a board is not automatically a key that can post to it.

The public roadmap, four columns reading Suggested, In Review, In Progress and Completed, each card carrying its vote count and a progress bar
The public roadmap, from Suggested through to Completed.

How is a key made?

On the share page of the project, and the value is shown once.

Showing it once is the ordinary discipline for a credential and it means a key you lose is a key you replace rather than a key you look up. The keys list afterwards shows that the key exists and when it was made, not what it says.

Is there documentation?

Yes, and it is served by the API itself rather than written beside it.

GET docs returns the documentation and GET openapi.json returns the machine readable description of every route above. Both are open, so a person evaluating this before signing up can read the whole surface without an account, which is the same argument this page is making in prose.

Where this stops

Four limits worth knowing before you plan around it.

It is a Pro capability. The Lite plan says no API access on the pricing page in those words, and that is the boundary rather than a rate limit.

There is no webhook in this table. Everything above is something you ask for. Nothing above is something that arrives when a board changes.

Writes are narrower than reads. You can file a request, vote, comment and dismiss a message. You cannot move a request between columns, set an effort, publish a release or change a setting.

An older API is still answering. The v2 routes are still served, and everything new should be written against v3. Nothing on this page describes v2.

This suits a team that already runs its own product surface and wants the board's data inside it. A team that only wants the board on a page should use the widgets, which need no key of this kind and no plan above Lite.

What this costs

API access is on Pro, which is $39 a month or $390 a year. Lite does not include it.

The trial runs 14 days with a card at signup, and the API is available during it.

How big the API is

Twenty one endpoints, three open, reads wider than writes, revenue behind a server side key only, and no webhooks. That is a small API.

If what you want is a board inside your own application rather than calls from your own server, the embeddable widgets do that without any of this.

The feedback board is what the endpoints read and write, and the reference carries every field. The first call takes four minutes in the quickstart, and a page that renders its own interface uses the headless client.

14 days, a card at signup, then $9 or $39 a month.

Related reading

A feature request board that needs no account to vote A public roadmap tool your visitors can use without an account A roadmap tool that emails voters when it ships Feature request boards for B2B enterprise customers, 32 checked JWT single sign on, so a vote carries your customer's real name