The machine readable data behind the COIVD-19 Vaccine Spotter tool. Very beta.

EspaƱol

API Fields

  • features[].properties.id: Vaccine Spotter's own unique ID for this location.
  • features[].properties.provider: A unique key representing the pharmacy or provider this location belongs to.
  • features[].properties.provider_location_id: The provider's own unique ID to represent this location (eg, store number, or other identifier). Unique in combination with provider.
  • features[].properties.appointments_available: Boolean value as to whether or not appointments are currently available at this location as of last check.
  • features[].properties.appointments: If appointments_available is true, then for some providers, this field contains an array of additional details on the specific appointment timeslots, vaccine types, etc. This more detailed information is not available for all providers, and the amount of detail varies for each provider.
  • features[].properties.appointments_last_fetched: ISO8601 time of when the appointment data was last fetched from the provider's website for this specific location.
  • features[].properties.appointments_last_modified: ISO8601 time of when the appointment data was last modified. In most cases, this will mirror appointments_last_fetched, but for some providers this may reflect an older time if we refresh the provider's website more frequently, but the provider's data indicates it is older.
  • features[].properties.carries_vaccine: This field is mostly for internal processing usage. Locations may carry the vaccine if this field is true or null (null just indicates this field isn't really used for a specific provider).

API Usage

  • License: You're welcome to do whatever you'd like with this data. If you use this data, I would appreciate linking back to Vaccine Spotter (just in the hopes that feedback on the data could help improve the quality of it), but it is not required.
  • Rate Limits: There are no rate limits for accessing the API. Data is updated approximately once a minute, so refreshing more often than that may not have benefits.

Historical Data

If you're interested in historical analysis of the appointments data, I have been collecting raw data of all appointment changes that have been detected since 2021-02-26.

This historical data is based on PostgreSQL table auditing, so it captures any changes detected in the underlying database tables. This may not be the most ideal design for this, but it does capture all of the possible changes (changes in overall appointment availability, changes in the specific appointment slots available, etc).

  • UTC Date Files: The audit records are organized into separate files for each complete UTC date.
  • Gzipped JSON Lines Format: Each file is a gzipped JSON Lines file. This format is simply a file where each line is a JSON object (but it's not technically a JSON array to make it easier to read the sometime large files line-by-line).
  • Exclusions: Some change events were explicitly excluded from the audit records for the sake of space. If only the following fields were being updated on a record, then auditing was skipped: created_at, updated_at, metadata_raw, appointments_raw, appointments_last_fetched.
  • Fields:
    • transaction_timestamp: The time this audit change event occurred in the database.
    • action: Indicates whether a INSERT, UPDATE, or DELETE statement was responsible for the audit change.
    • previous_data: The complete data on this record as it existed just before the current transaction is about to take place and alter the record. Note that because some change events are excluded (see above), this previous data may contain data that wasn't previously in the audit history logs (so this is not necessarily the data that was previously audited for a record).
    • changed_data: The specific fields and data that is being updated on this record as part of this change.
    • data: The final set of data that exists after this transaction takes place.