Tweeting Out Legislative Branch Procurement

We are pleased to announce a new Twitter Bot that tweets procurement notices published by Legislative branch agencies on Sam.gov. These procurements and accompanying documentation can shed light on Legislative branch plans, operations, and priorities. 

The new LegBranchProcurementBot, built by the Lincoln Network with input from Demand Progress Education Fund, was inspired by a previous bot, CongressRFP, that stopped working when the federal government changed procurement platforms. This new bot covers procurements from the following entities: the legislative branch in general, the Senate, the House of Representatives, the Architect of the Capitol, and the Library of Congress. 

For example, two recent include a solicitation to help support the creation of a Capitol Complex Master Plan and notice of an industry day for businesses interested in building a perimeter anti-scale fence. Both of these items have been in the news and the subject of testimony before Congress, but the notices provide significantly more detail about what’s under discussion and afford an opportunity to weigh in on the process.

How it works

The LegBranchProcurementBot use a Sam.gov API to identify procurement notices from a variety of Legislative branch entities. Unfortunately, the API is not as straightforward as one would hope. In fact, we identified three different APIs, the most useful of which is unlisted!

The Sam Public APIs, v1 and v2 are listed on the OpenGSA website, here. However, they don’t appear to be the APIs that serve the Sam website and are missing information. We found a third API at https://sam.gov/api/prod/sgs/v1/search/ that we are using. It was found in the network requests of the results page for a given search on Sam.gov. The API returns additional information published on the Sam website and, thankfully, is not rate limited, which is a problem with the OpenGSA APIs, which are limited to 10 requests. 

The government should consider improving the documentation accompanying APIs v1 and v2. Specifically, it should note the rate limits as well as the postedFrom and postedTo fields (i.e., allowing users to limit the date range of returned results).  In addition, the API information page should contain a basic example on how to use the API to help end-users not waste API requests trying to learn how to work with the rate-limited APIs.