What does the Denver CO 311 data include?

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

Do I need an account with Denver CO 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.

Denver CO 311

Public data

Ready to useNo account needed

Service requests reported to Denver, Colorado's 311 line over roughly the last year, as the city publishes them. 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.

397,116service requests as of September 2026
About 7,500new service requests a week
1 tableone row per service request

What people use it for

Compare council and police districtsBreak requests down by council district or police district.
Track how long requests take to closeCompare when each request opens and closes.
Map where requests come fromPlot requests using their coordinates to see where they cluster.

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 Denver CO 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 Denver CO 311 data include?: One table, service requests, with one row per service request.
Do I need an account with Denver CO 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Denver CO 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 denver_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://services1.arcgis.com/zdB7qR0BtYrg0Xpl/arcgis/rest/services/ODC_service_requests_311/FeatureServer/66

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` All Denver 311 service requests exposed by the publisher's rolling 12-month feed (measured 397,116 rows via returnCountOnly, 96,495 created in the last 90 days). The official publisher scopes this layer to a rolling 12 months, so older records drop off as newer ones are added; this is a current-layer snapshot, NOT full historical coverage. OBJECTID is the layer's native, system-maintained object identifier and is unique within the currently published layer, but the publisher exposes no business request number or general modified field, so identity across a layer republish is not guaranteed to be stable. Every run re-fetches the whole collection (199 pages of 2,000 at the effective page cap, verified against the 500,000-record scan limit) and replaces the destination snapshot, so later edits and closures (e.g. Case_Closed_Date) are captured. Case_Created_Date and Case_Closed_Date are ArcGIS native Date values delivered as Unix epoch MILLISECONDS (preserved as bigint; 24,897 rows have a NULL Case_Closed_Date, which is retained, not dropped). The separate Case_Created_dttm / Case_Closed_dttm string columns carry the publisher's own human-readable renderings; both original values are preserved and are NOT assumed to encode the same instant as the millisecond dates (the *_dttm strings are not timezone-qualified and may carry a different time of day).	beta	full	replace	`OBJECTID`	-