Skip to main content
Bills, documents, events, and transcripts are filtered the same way. Each list endpoint accepts the shared filters below, along with a few filters of its own, such as introduced_after for bills or starts_after for events, which are listed on each resource’s page.

​
Combining Filters

You may combine any number of filters. A record must match every filter you pass. Filters marked as accepting a list take comma-separated values, in which case a record must match any one of them. For example, the following request retrieves bills from Texas or Virginia that are still in procedure:
Date ranges, such as published_after and published_before, include the dates you pass. Contradictory or unknown parameters are rejected with a 422 response, as described in Query Parameters.

​
Shared Filters

The /bills, /documents, /events, and /transcripts endpoints all accept the following query parameters:

​
Recommendation Filters

Bills, documents, events, and transcripts all accept the same recommendation filters. They only consider the workspaces your API key can read. A transcript or a document counts as recommended when the whole record, or one of its parts, such as a chapter of a hearing or a section of a gazette, was recommended: Passing min_importance, workspace, or topic implies recommended=true, so you never need to pass both, and combining them with recommended=false is rejected. When you pass several recommendation filters, a single recommendation must match all of them: workspace=A&min_importance=high returns records recommended at high or above to workspace A, not records recommended to A at any level and to another workspace at high. For example, the following request retrieves Texas bills recommended at high importance or above to the “Data centers” workspace:
The same parameters work on /documents, /events, and /transcripts, so the request for upcoming events recommended to that workspace looks just the same:

​
Recommendations on Records

Every bill, document, event, and transcript includes a recommendations attribute, so you can tell at a glance whether a record matters to your team without a second request:
The array holds one entry for each of your key’s workspaces the record, or one of its parts, was recommended to, with the highest importance among them. It is empty when the record was not recommended to any. A record may matter a great deal to one workspace and little to another, which is why the API lists each workspace rather than a single level. To read why a record was recommended, and for which topics, pass its id to the recommendations endpoint, such as GET /recommendations?record_type=bill&record_id=9b3e2c1a-....