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.
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.
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.
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.