I’ve been having a great time exploring the API! One question has came to mind as I’ve transitioned over from downloading data manually via the web interface and doing so programmatically via the API: why split the ACS 5-year downloads into an “_E” and “_M” via the API but not via the web download?
Hi Drew, thanks for writing! We’re glad you are having fun working with our API!
The NHGIS website allows you to choose whether you want the two data types (estimates and margins of error) separate or combined. It’s a choice on the Review and Submit page under the Breakdown/Data Type Layout heading, which gives you the option to either “Combine different breakdowns/data types into a single data file” or “Separate different breakdowns/data types into distinct data files”. Sounds like you’ve been opting to combine the data types when using the website.
In the interest of simplifying the API while we’re still in beta, we elected to default to separate files for now. Our intent is to allow the API to do all the same things users can do on the website, so look for that choice to be added to the API eventually as well.
Hope that helps! Let us know if you have any other questions, and stay tuned for more features to be added to the beta NHGIS Data Extract API any day now. 
Ahh, I see. Thanks for writing back, excited about the new features to hit! One more question for you. When I grab data in CSV format from the 5-yr ACS via the API, the data has a second row of detailed labels for each field, but this isn’t the case when I grab it via the website. Any reason why this is the case?
It’s for a similar reason. In the spirit of simplifying the beta, the API enables the “Include additional descriptive header row” option for CSV files by default; the website does not.
To correct Fran’s last message, I believe the API does already allow you to opt not to include a descriptive header row…
In a “post” call, if you prefer a CSV with no extra description row, use “data_format”: “csv_no_header” (instead of “data_format”: “csv_header”, as listed in the example code).
To my knowledge, this option isn’t documented anywhere yet (except here in my message, I guess!), which is a known issue we plan to address.
(I’m also noticing now that “csv_no_header” is a misnomer, as such a file will still include a header, just not a descriptive header, so we might eventually change this to be “csv_no_description_row” or something like that.)
@JonathanSchroeder @fran: thanks so much for the info! I appreciate all of the help you all have given me already. I’ll definitely test out the "data_format":"csv_no_header" option and see what happens!