# OpenLegislation turns the New York Senate's bill feed into a JSON API > OpenLegislation is the web service the New York State Senate built in house to publish its legislative data. Bills, resolutions and laws arrive from the Legislative Bill Drafting Commission as raw plain text updates, and the service parses them in real time and redistributes them as JSON for anyone with a free key. It is the same service that backs nysenate.gov. **nysenate/OpenLegislation** — OpenLegislation is a web service that delivers legislative information from the New York State Senate and Assembly to the public in near-real time. It is used internally to serve up legislative data for nysenate.gov and the Bluebird-CRM. - Repository: https://github.com/nysenate/OpenLegislation - Website: http://legislation.nysenate.gov/ - Stars: 554 · Forks: 100 - Language: Java - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/nysenate-openlegislation ## A government service, published as an API The repository is called OpenLegislation and the tagline is From the New York State Senate. The service is described as an open source web service developed in-house by the New York State Senate to provide access to NYS legislative data including bills, resolutions, and laws. That word in-house is the one that matters. This is not a hobby project scraping a legislature's website and republishing it. It is the legislature's own software, running as the system of record for the data it publishes. The reason it exists is stated in the next sentence. It is used internally to serve up legislative data for nysenate.gov and the Bluebird-CRM. So the public JSON API and the internal systems are the same service. That is a plainly different thing from a third-party mirror, and it changes what you can expect. The data behind the API is the same data the Senate's own website renders from, which means it is as fresh as the Senate's site and it is complete in the way the Senate's site is complete. Access is by key. Developers can request a free key for the JSON API, and the API is documented with a static HTML documentation page on the same domain. The homepage is legislation.nysenate.gov, and the licence is dual BSD and GPL, with the details on the Senate's open source licensing page. A dual licence of that kind is a deliberate choice to let commercial users pick the BSD terms while keeping the GPL option available. The repository layout is a standard Java web application: a pom.xml at the root, a src/ directory, a bin/ directory, a docs/ directory and a jmeter/ directory, plus an AGENTS.md and an .idea/ directory with the IDE configuration checked in. ## The input is a plain text update feed The most interesting sentence in the documentation describes the data source. Updates to legislative data are distributed by the Legislative Bill drafting Commission, in a raw, plain text format. OpenLegislation parses the updates in real time and redistributes the data through the JSON API for integration with various web applications. That sentence describes the whole architecture. There is no scraping, no HTML parsing and no database of scraped pages. There is a feed, and the service consumes it continuously. The reason this matters is the nature of the source. A legislative drafting commission publishes updates because bills change: they are introduced, amended, referred to committee, passed, signed. Each of those is an update to the document. The raw plain text format is the commission's own, and it is not a format designed for consumers, which means the parsing work is the service's core competence. Real-time parsing also means the service is not a snapshot. If a bill is amended this afternoon, the amendment is in the API this afternoon. For anyone building something that needs to reflect the current state of the legislature rather than a version from a periodic export, that is the property that matters. The document types are the three that the Senate publishes. Bills, resolutions and laws, with laws being the subset that has completed the whole process and been signed into statute. The one structural caveat is the one you would expect of any feed consumer: the input format is owned by the drafting commission and can change when their publishing system changes. The service's job is to keep up with that, and a consumer of the JSON API is insulated from it, which is the value the service provides over reading the feed yourself. ## A conventional Java stack, deliberately The technology list is the one you would pick for this kind of service, and it is worth reading as a set of decisions rather than a list. Java 21 is the language version. Spring 6 Framework is the application framework. PostgreSQL is the database. Elasticsearch 8 is the search engine. React is the front end. Tomcat 11 is the servlet container. The stack is conventional in the way a government service written in house tends to be, and the reason is not aesthetic. It is the stack the organisation's engineers know, the stack they can hire for and maintain across years, and the stack whose support does not depend on a single vendor's continued existence. The two data stores tell you the most. PostgreSQL is where the authoritative structured data lives, since a bill has a number, a sponsor, a status and a list of actions, and that is relational data with relations that matter. Elasticsearch is where the search lives, since the way people look for legislation is by keyword across a very large body of text, and that is a different problem from retrieving a bill by number. Having both is the shape of a public search service. The full text of every bill and amendment is a lot of text to search with SQL, and putting it in a search index is what makes the API usable for the search-shaped questions people actually ask. The React front end is what produces the bill page shown in the documentation, the one served to the public at legislation.nysenate.gov. The service is not only an API, it is a website, and the API and the site are the same application. Tomcat 11 rather than an embedded server is the one detail that dates the stack slightly, and it is the kind of thing a service that has been running for a long time keeps. The tagged release is v1.9.2 from 2015, which is a useful marker for how long this codebase has been in service, and the default branch is dev with the last push on 2026-10-19. ## The jmeter directory and the rest of the repository Two entries in the repository layout say more about the project than the README does. The first is jmeter/. Apache JMeter is a load testing tool, and having a directory for it in the repository means load test scripts are versioned alongside the code. For a public API that has to stay up while the legislature is in session and traffic arrives in bursts around filing deadlines, that is standard practice rather than an extra. The second is the docs/ directory, which for a service whose contract is an API is where the interface documentation lives, alongside the static HTML documentation page published on the domain. Then there is bin/, which in a Java project of this shape holds the helper scripts for running and deploying the application, and src/ holding the application itself. The AGENTS.md file is worth mentioning because it is a fairly recent convention for a repository of this vintage. It is a file written for automated coding agents working in the repository, telling them how the project is laid out and how to work in it. Its presence in a Java service whose last tagged release is from 2015 tells you the project is still actively worked on, even though its version numbers have not moved in a long time. The people section is also part of the picture. The documentation lists the current Senate developers by name and email, with Kevin Caseiras, Ken Zalewski, Anthony Calabrese and Jacob Keegan, and separately lists the past developers, with Nathan Freitas, Jared Williams, Graylin Kim, Ash Islam and Sam Stouffer. Listing past developers explicitly is unusual and it is a good practice. A service that has been in production for a decade accumulates a lot of institutional knowledge, and naming the people who built it is the first step in passing that on rather than losing it. And then there is the .idea/ directory with the IntelliJ project files checked in, which is a small but real choice: it means anyone opening the project in that IDE gets the same configuration the developers use, at the cost of a repository that carries editor-specific files. ## Where this fits against scraping and against commercial data feeds The comparison is with the two alternatives for getting the same data. The first is scraping nysenate.gov yourself. That is what most people would do, and it works until the site's markup changes, at which point your scraper breaks and you find out because your numbers went wrong rather than because it threw an error. The other problem is that a scraped page is the rendering of the data for humans, so the structured facts are embedded in markup designed for display, and every field you want means a selector. The OpenLegislation API removes both problems. The parsing happens once, in a service whose authors work with the source feed, and the JSON is a stable contract with documentation and a version history. The second alternative is a commercial legislative data feed. Those exist and they cover many states, which is their advantage, and they come with support and with the aggregation and normalisation that a commercial service can afford to do. Their disadvantages are the cost and the fact that the data is a snapshot of whatever the vendor's collection process captured. OpenLegislation is the opposite trade on every axis. It is free, it is specific to one state, it is the authoritative source rather than a mirror of it, and it is updated in real time. The scope limit is the important one to state plainly. This service covers New York State only. If you need a multi-state picture, a commercial feed is the only realistic option, and building a scraper or parser for the other forty-nine legislatures is a project in itself, since each state's publishing system is different in the way New York's plain text update format is different. There is also a policy dimension worth thinking about. A government publishing its legislative data through an API that it runs itself is a stronger position for openness than a legislature that publishes PDFs and leaves the interpretation to whoever is willing to scrape them. The API here was built for the Senate's own website and publicised afterwards, which is the way you get a service that will still exist in a decade. ## Conclusion Adopt OpenLegislation if you need New York State legislative data as JSON rather than as scraped pages, since the parsing of the raw legislative update format is the part you would otherwise have to reverse engineer. Skip it if you need data from other states, since the parser is specific to the New York format, and if you need a supported commercial data feed. Verify first which of the three document types you need, whether bill, resolution or law, that you request a key before you build against it, and how current the data needs to be, since the update feed drives everything and its format changes with the drafting process. ## FAQ ### What is OpenLegislation and who runs it? It is an open source web service developed in-house by the New York State Senate to provide access to NYS legislative data including bills, resolutions and laws. It is used internally to serve up legislative data for nysenate.gov and the Bluebird-CRM, and it is published under a dual BSD and GPL licence with developers able to request a free key for the JSON API. ### Where does OpenLegislation get its data and how current is it? Updates to legislative data are distributed by the Legislative Bill drafting Commission in a raw, plain text format. OpenLegislation parses those updates in real time and redistributes the data through the JSON API for integration with web applications, so the API reflects amendments as they happen rather than a periodic snapshot. ### What technology does OpenLegislation use? The service is built with Java 21, Spring 6 Framework, PostgreSQL, Elasticsearch 8, React and Tomcat 11. The repository holds a pom.xml, src/, bin/, docs/ and a jmeter/ directory for load testing, along with an AGENTS.md, and the documentation lists the current and past Senate developers. ## Sources - [Issues](https://github.com/nysenate/OpenLegislation/issues) - [nysenate/OpenLegislation on GitHub](https://github.com/nysenate/OpenLegislation) - [Project website](http://legislation.nysenate.gov/) - [README](https://github.com/nysenate/OpenLegislation/blob/dev/README.md) - [Releases](https://github.com/nysenate/OpenLegislation/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nysenate-openlegislation