What does the Detroit MI 311 data include?

One table, service requests, with one row per service request.

Do I need an account with Detroit MI 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. Each run replaces the table with a fresh copy, so edits and removals at the source show up after the next run.

Will running it again create duplicate rows?

No. Each run replaces the table, so it never holds two copies of the same row.

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.

Detroit MI 311

Public data

Ready to useNo account needed

Service requests reported to Detroit, Michigan's 311 line, as the city publishes them through its Improve Detroit service. Ingest delivers this data to a data warehouse you own as one table, and updates it on the schedule you choose. There is no code to write and nothing to install.

749,388service requests as of September 2026
About 2,300new service requests a week
1 tableone row per service request

What people use it for

Compare requests by council districtBreak requests down by council district to see where demand concentrates.
Track how long requests take to closeSee how many days or hours a request takes to close.
Watch which requests get reopenedSee how often a closed request is reopened later.

What you get

Table	Each row is
Service requests `featureserver`	One service request

Good to know

Each run replaces the table with a fresh copy, so edits and removals at the source show up after the next run.

How it works

Choose Detroit MI 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 Detroit MI 311 data include?: One table, service requests, with one row per service request.
Do I need an account with Detroit MI 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Detroit MI 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. Each run replaces the table with a fresh copy, so edits and removals at the source show up after the next run.
Will running it again create duplicate rows?: No. Each run replaces the table, so it never holds two copies of the same row.
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 detroit_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://services2.arcgis.com/qvkbeam7Wirps6zC/arcgis/rest/services/improve_detroit/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` Snapshot of every row currently published in the Improve Detroit Issues layer (City of Detroit 311). Each run re-fetches the entire current layer and replaces the destination table, so the snapshot reflects the source's latest published state; later edits, status changes and closures the city publishes are picked up on the next run. An independent returnCountOnly measurement at authoring time counted 749,388 rows, so the offset caps here (max_offset_depth 800,000 = 800 pages x 1,000) are explicitly sized above the engine's 500,000-row default; the layer needs 750 data pages, under both the 800-page and 800,000-row ceilings. Pages are ordered by ObjectId, the layer's system-maintained unique field, which makes offset paging deterministic for the current layer while its contents are unchanged between requests (it does not isolate a republished or edited layer mid-scan). A short final page (388 rows at offset 749,000) and an empty features array past the end were both confirmed live, so the scan stops at true end-of-data; deep pages measured ~3s against a 120s timeout. ArcGIS native Date fields (created_at, acknowledged_at, updated_at, closed_at, reopened_at) arrive as epoch MILLISECONDS and are preserved as bigint with that unit - they are not Unix seconds and must not be cast to timestamp. Geometry is omitted (returnGeometry=false). Per the source's own documentation, street addresses are intentionally withheld for some request categories. 2014-07-14 is the oldest creation date observed during authoring; it is an observed minimum, not a guarantee that the layer retains its full history, and this connector warrants only the rows currently published. Completion of all 750 pages inside one run's byte/deadline/normalization budgets has not been verified by bounded samples; the catalog byte figure is an estimate, not a certified cap.	beta	full	replace	`issue_id`	-