Skip to Main Content | Font Size | Web Accessibility | Video Transcript

Developer FAQs

Q: I appreciate SFpark’s extensive API document, but can I just roll up my sleeves and dive in?

A: Sure.
Pricing info:
Want more data? Increase the radius:

Q: I heard that the data is no longer going to flow after the first of the 2014 year. Is this true?

A: Parking space availability sensors are going to be decommissioned on January 1, 2014. However, pilot area pricing data and garage availability will remain available through the existing API.

Q: OK, I understand that there are going to be changes to the data at the first of the year in 2014, but what are the exact changes to the returned data?

A: The only changes to the existing data are going to be the omission of the two availability-related data “OCC” and “OPER” attributes. If you are running code that depends upon receiving values in these two attributes, please revisit the code to ensure it will run in the absence of the “OCC” and “OPER.”

Q: Why is the count of occupied spaces higher than the count of operational spaces sometimes in off street parking?

A: When the count of occupied spaces (OCC) number is larger than the count of operational spaces (OPER) number, please interpret that as a signal that there isn’t valid availability information for the garage yet.

Q: I’ve done the math and in some places on your maps the availability percentages don’t fall into the proper coloration scheme. What’s going on?

A: Instead of providing raw percentages all the time, there are exceptions in areas where providing the actual percentage of available parking would skew the map’s coloration.

Q: How can I find out how many spaces were occupied on a specific block yesterday, or the day before that?

A: You can’t with the current API. However, you are welcome to save queries for future reference and build retrospective queries off that data.

Q: Sometimes my handling of the returned data set breaks. Why?

A: The JSON data stream is valid. When there’s a single item, it is represented directly as a dictionary rather than an array of dictionaries. This behavior shows up in the Operational Hours (OPHRS) component and rate’s Rate Structure (RS) component.

Q: When I’m trying to calculate the timespan of a particular pricing bucket, all I have to work with is English text descriptions of the time, like “7:00AM.” Why can’t this be represented in a format from which I can directly create a time object? Can’t I decide how I want to display the time on my own?

A: The choice was made to send beginning and ending times as text to ease the display logic.

Q: When I look at the start and end times of pricing buckets, I keep seeing the END time listed as 12:00AM. Since 12:00AM is the first minute of any particular day, not that last, why does this happen?

A: Indeed, the time 12:00AM is the first minute of the day. However, please interpret END times with a value of 12:00AM as the last minute of a day, and BEG values with 12:00AM as the first minute of the day.

Q: How often can I call the API?

A: There are currently no limits on the use of the API service. However, please be mindful that it is a shared resource and throttling may occur if usage is at unacceptable levels. We recommend that you call the service no more than once per minute.

Q: I’ve found an error in the data. How do I report it?
A: Email