What does the Charlotte NC 311 data include?

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

Do I need an account with Charlotte NC 311?

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

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.

Charlotte NC 311

Public data

Ready to useNo account needed

Service requests made to Charlotte, North Carolina's 311 line, as the city publishes them, with when each was made and where. 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.

3.4 millionservice requests as of September 2026
About 8,000new service requests a week
1 tableone row per service request

What people use it for

Watch demand week by weekCount requests by the day they were made to see weekly and seasonal patterns.
Map where requests come fromPlot requests using their coordinates to see which parts of the city report the most.

What you get

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

Good to know

The first run loads the last 30 days. After that, each run keeps the last 30 days current, re-reading a day once its copy is at least 7 days old. Older requests keep the values they had when last read.

How it works

Choose Charlotte NC 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 Charlotte NC 311 data include?: One table, service requests, with one row per service request.
Do I need an account with Charlotte NC 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Charlotte NC 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. The first run loads the last 30 days. After that, each run keeps the last 30 days current, re-reading a day once its copy is at least 7 days old. Older requests keep the values they had when last read.
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 charlottenc_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://gis.charlottenc.gov/arcgis/rest/services/ODP/ServiceRequests311/MapServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`mapserver` Public 311 service requests from Charlotte's ArcGIS Service Request Data layer. The full exposed source currently holds 3,403,537 records (count checked 2026-09-13); the publisher does not state that this is a complete retained archive, so no full-history claim is made. This sync reads RECEIVED_DATE in per-day creation windows, defaulting to the last 30 completed days; completed windows still inside the horizon are re-read after staleness_days to capture later edits such as closures. The current UTC day becomes eligible only after it ends, and every window is bounded at CURRENT_TIMESTAMP so a future-dated outlier (a request timestamped 2027-08-24) is excluded. RECEIVED_DATE is the only date field this layer exposes (there is no general updated or closed date), so edits are captured only when their creation window is read again; creation days outside the horizon keep their last synced values and their later edits are not re-fetched. This is bounded recent history unless lookback_days is raised, not the whole 3.4-million-row layer. RECEIVED_DATE is a native ArcGIS Date carried as Unix epoch milliseconds and is stored as bigint, preserving the raw millisecond values and their dates. Each row is merged by OBJECTID, the layer's native object-id field, so re-read windows update in place and never duplicate. OBJECTID is the layer's current object id; its persistence across a future layer republish is not guaranteed by the publisher and is not promised here. Older completed days wait longer between reads, becoming eligible again only after the longer of the refresh interval and a twentieth of their age at their last read (with the default interval, a day read at 280 days old waits 14 days).	beta	window	merge	`OBJECTID`	lookback_days, staleness_days