← Integrations

The 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, and this page would rather say so than leave you to discover it in an afternoon.

The API keys list on the share page, with one key made and its prefix shown
API keys and webhook targets. The key is shown once.

What is the identity endpoint 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 with us.

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.

The voter list, one row per person, showing where each arrived from and how many requests and comments they have left
Everyone who voted, one row each, no account required.

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 roadmap widget embedded in an ordinary web page, drawing the board's columns as a grid of cards
The roadmap widget running inside an ordinary web page.

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.

The honest summary

Twenty one endpoints, three open, reads wider than writes, revenue behind a server side key only, and no webhooks. That is a small API and it is described here at its real size rather than at a size that would make the page read better.

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 Public roadmap, and what belongs on one A changelog that emails the people who asked for it