List My Followed Bills
list_my_followed_billsThe bills the logged-in user follows in the Dapper platform, newest follow first. This is their own watchlist, not a search: use it for «¿qué proyectos estoy siguiendo?», «¿alguno de los que sigo se movió esta semana?», or to ground a briefing in what this person already cares about.
Rows are the same shape list_bills returns — title, authors, latest_state, dapper_url — plus followed_at and notify, so you can report movement without a second call per bill. meta.total is how many they follow in all.
This reads the watchlist; follow_bill and unfollow_bill change it, when this server lists them. A follow made there can take a few seconds to show up here.
Requires a signed-in session; an API key issued without a client_email has no watchlist to report and says so.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per page (1-100, default 20). The response's `meta.has_more` and `meta.next_cursor` tell you whether there are more. `meta.total`, when it is not null, is the full count without paging; some lists return null rather than pay for a count. Raise the limit when you genuinely need a whole list in one call rather than the most relevant few. | |
| cursor | No | Opaque pagination cursor from a previous response's `meta.next_cursor`. Pass every other filter unchanged when paging. Only ever use a cursor this API handed you — never build one. With `q`, a cursor continues the keyword listing (`meta.mode: "keyword_fallback"`): relevance-ranked results are a single page of at most 20 rows and report `has_more: false`, so if you got one there is no next page to ask for, and a `limit` above 20 adds nothing to it. Narrow `q` instead of paging. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||