What does the Boston MA 311 data include?

2 tables: service requests (one row per service request) and request types (one row per request type the city accepts).

Do I need an account with Boston MA 311?

No. The data is public, so there is nothing to sign up for and nothing to paste in.

How fresh is the data?

As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan.

Will running it again create duplicate rows?

No. Each row is stored once, by its key: when a run reads a row that is already there, it replaces that copy instead of adding a second one.

Do I need to write code?

No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

Boston MA 311

Civic data

Ready to useNo account needed

Service requests reported to the City of Boston's 311 line over roughly the past year, as the city publishes them. Ingest delivers this data to a data warehouse you own as 2 tables, and updates it on the schedule you choose. There is no code to write and nothing to install.

What people use it for

See which problems are growingCount requests by type, week by week, to spot what is rising.
Map where requests come fromPlot requests using their coordinates to see where they cluster.
Look up what a request type meansMatch each request's code to the city's current list of service types.

What you get

Table	Each row is
Service requests `service_requests`	One service request
Request types `services`	One request type the city accepts

Good to know

Service requests: The first run loads the last 365 days. After that, each run keeps the last 365 days current, re-reading a day once its copy is at least a day old. Older requests keep the values they had when last read.
Request types: Re-read in full at most once a day. Rows that changed are updated, and rows the source removes stay in your table.

How it works

Choose Boston MA 311. The data is public, so there is nothing to sign in to.
Pick where it goes. BigQuery, Snowflake, Databricks, Redshift and 10 more, in an account you own.
Pick a schedule. Daily is the default, and weekly and monthly are there too.
Ingest runs it from then on. If a run fails, your dashboard shows which table and why.

Questions

What does the Boston MA 311 data include?: 2 tables: service requests (one row per service request) and request types (one row per request type the city accepts).
Do I need an account with Boston MA 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Boston MA 311 data go to?: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, Ingest Managed Lakehouse, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL and Snowflake, in an account you own.
How fresh is the data?: As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan.
Will running it again create duplicate rows?: No. Each row is stored once, by its key: when a run reads a row that is already there, it replaces that copy instead of adding a second one.
Do I need to write code?: No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

For your data team: technical reference

Connector boston_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://wiki.open311.org/GeoReport_v2/

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`service_requests` City of Boston public 311 service requests, read in creation-day windows of requested_datetime. By default the previous 365 completed UTC days are in scope; the current UTC day becomes eligible once it completes. Each day is read as a completed UTC day through 23:59:59: the end bound is inclusive, and the next midnight (00:00:00 of the following day) is excluded, so a request created at the stroke of midnight belongs only to that following day's window. Each day is paged at up to 300 requests and paging stops on the first short page, because asking for a page past the end of a day's data can come back as a server error rather than an empty page (an otherwise empty day window returns an empty list). A completed day inside the horizon is re-read once its last successful read is at least one day old and at least a tenth as old as the day was at that read: a day read within ten days of its date is re-read daily and one read at 100 days old waits 10 days, so an edit to a request reaches the table within about a tenth of the request's age, and at least a day. Edits to requests older than the horizon are not revisited, and requests deleted from the feed are not propagated as deletions. Records are keyed by service_request_id (UUIDs or numeric strings, hence text).	beta	window	merge	`service_request_id`	lookback_days
`services` Current public service-type catalog for the City of Boston 311 feed. It is a live reference, not a complete historical dimension: request rows carry service codes, including retired types this catalog no longer lists, so it is never used to filter request rows. Re-read when its last successful read is more than one day old, so codes added or changed by the city appear; codes that leave the catalog keep their last loaded values.	beta	staleness	merge	`service_code`	-

Setting up the destination is its own short guide, one per warehouse or lake: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, Ingest Managed Lakehouse, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL, Snowflake.

Get Boston MA 311 data into your warehouse

Last updated 2026-10-16.