What does the Lexington KY 311 data include?

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

Do I need an account with Lexington KY 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.

Lexington KY 311

Public data

Ready to useNo account needed

Public citizen requests from Lexington-Fayette, Kentucky and surrounding referral areas. 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.

9,121service requests as of September 2026
About 710new service requests a week
1 tableone row per service request

What people use it for

See active requestsReview the current 30-day window to focus on recently submitted problems.
Spot problem clustersPlot requests to see which neighborhoods report most frequently.

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

Vendor documentation: https://services1.arcgis.com/Mg7DLdfYcSWIaDnu/arcgis/rest/services/CitizenRequests_public/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` The CitizenRequests_public layer's public view exposes only requests whose CreatedDate falls in the trailing 30 days (viewDefinitionQuery: CreatedDate BETWEEN CURRENT_TIMESTAMP - 30 AND CURRENT_TIMESTAMP) — a rolling window measured at 9,121 records on 2026-09-14 14:54–14:56 UTC, whose full raw API responses totaled 3,749,972 bytes, so the entire window fits one full run of five 2,000-row pages — far below the paginator's 500,000-row offset-depth cap and the 1 GiB response budget. Every run re-reads the whole window and loads with replace, so the destination mirrors the window at read time and requests that age out of it are dropped; the public view simply does not expose requests outside that creation-date window — whether the underlying source deletes or otherwise retains older records is not established. The 14-field layer carries no status, closure-date, or generic edited timestamp: CreatedDate, the only date field, is an ArcGIS native Date whose wire value is Unix epoch MILLISECONDS (13-digit integers) and is preserved as bigint, never cast to a timestamp. Because the paginated multi-request read of a live layer is not atomic, no self-consistent point-in-time snapshot and no complete closure/update capture is guaranteed; a still-windowed request that was edited before the current read is picked up only by re-reading the whole window next run. OBJECTID is the layer's system-maintained, unique, non-null row identity (isSystemMaintained: true, backed by the layer's unique OID index) and is the primary key; CaseNumber is nullable display text, not a reliable key. Source field names appear as the layer publishes them, including Salesforce-derived names such as Address__c, Problem_Code__c and LOCATION__LATITUDE__S; destination column naming follows the destination's own normalization.	beta	full	replace	`OBJECTID`	-