FPL API - get all FPL-specific information from an endpoint

[mapsam]

Is there any sort of API for calculating Federal Poverty Level? It'd be so awesome if the Gov had a quick end-point that had the actual dollar amount for FPL. Would mean "calculator services" don't have to update their algorithms every year!

i.e. fpl.usa.gov/api/2015 would return a json of {level: "$11,770"} included

Some comments thus far:

@daguar said this might be useful: might be useful: https://www.healthcare.gov/glossary/federal-poverty-level-FPL/

@alanjosephwilliams said also area median income would be good to have

@migurski made comments about headers (unsure of how much sarcasm was included 👋). It could even return a text/plain of 11770 or an application/octet-stream of 0x2DFA

[daguar]

@svmatthews I've seen a few uses for this (particularly eligibility screeners) but did you have a specific use-case motivating it?

[daguar]

CC @ycombinator because he's API Man™.

[mapsam]

Good question. We've been looking at this financial verification project for Richmond, which has potential to incorporate a background eligibility screener to recommend other services (i.e. SNAP or WIC) if people are eligible. We're also likely going to do bare-bones FPL calculations, which would be better suited against an updated source vs. a static file that requires updates every time the FPL numbers change.

[lippytak]

It's just a table, right? Who needs an API?

[mapsam]

I'm just thinking it would be nice to not manually update your application when the FPL levels change, which seems like an annual thing: http://www.ssa.gov/policy/docs/statcomps/supplement/2014/3e.html#table3.e8

[fureigh]

@svmatthews: If the table has a reliable location — which is an if! — would https://www.kimonolabs.com do the trick?

[ycombinator]

Basic, possibly stupid, question to start off: How frequently does this information (FPL dollar amount) change? It seems from the issue description that this might be once a year but I don't want to make that assumption.

[alanjosephwilliams]

I was attracted to this idea because I was thinking about FPL as a proxy
for a set of federally defined, floating figures that influence eligibility
for different federal funding streams—federal poverty level and unadjusted
area median income being two of the most notable.

On Wed, Mar 25, 2015 at 11:59 AM, Shaunak Kashyap [email protected]
wrote:

Basic, possibly stupid, question to start off: How frequently does this
information (FPL dollar amount) change? It seems from the issue
description that this might be once a year but I don't want to make that
assumption.

—
Reply to this email directly or view it on GitHub
#70 (comment)
.

t: @alanjosephwilli
p: 817 713 6264

[ycombinator]

Never mind, I just read the glossary link and learnt that this changes once a year, but also changes depending on the number of people in the family. Based on that, if this is to be an API:

1. It should probably take year and family_size as query parameters. Both parameters could be optional, defaulting to current year and 1, respectively.
2. application/json seems like a good choice of content type for the response representation as it is easily extensible, should you want to add more information to the response later. That being said, you could always allow content negotiation for text/plain per @migurski's suggestion.
3. Depending on the value of the the year, you could set an Expires header on the response. This would allow HTTP clients and intermediaries to cache the response, making frequent reads that much faster.

[mapsam]

Thanks for the feedback, everyone! I've started working on a proof of concept under a personal repo with the intention to move it to a C4A repo eventually. Take a look and let me know what you think. https://github.com/svmatthews/fplapi

I haven't built an API before, so let me know if there is something terribly wrong here. Is using a python dictionary as a data source insane?

[Mr0grog]

Is using a python dictionary as a data source insane?

Nah, for a dataset that is sufficiently small and changes rarely (and critically, where those criteria are unlikely to change), I think storing the data with the source is not unreasonable. It also gives you the nice side benefit of an audit trail with no extra work. Some Open311 tools do this, too ;)

One thing you might consider, though, is putting the data into a standard format (e.g. JSON, YAML, CSV, etc.) and separating it into its own repo, which can then be included as a submodule in your API project—or anybody else’s project (and in any language, since the file is a standard format). @bensheldon and I talked about doing this in 2012 for a list of Open311 servers. We never did it, but it looks like @SantiMunin did: https://github.com/SantiMunin/GeoReportv2-endpoints

[Mr0grog]

Another great example of that practice in wide use is the Mustache templating language specification: https://github.com/mustache/spec

It is written as a series of YAML files from which you can generate tests. Many (almost all?) Mustache ports do in fact include it as a submodule and test against it to make sure they are conforming.

[mapsam]

Hey! This exists in the real world now 💃

http://fplapi.herokuapp.com/api?size=3&income=2000&income_type=monthly