What does the Indianapolis IN 311 data include?

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

Do I need an account with Indianapolis IN 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.

Indianapolis IN 311

Public data

Ready to useNo account needed

Service requests reported to Indianapolis, Indiana's 311 line, 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.

What people use it for

See which service handles whatBreak requests down by service type and the department responsible.
Compare districts and townshipsSee which council district or township reports the most requests.
See how residents report issuesCompare requests submitted by phone, app or other channels.
Map requests by zip codeSee where requests cluster by zip code or location.

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

Vendor documentation: https://gis.indy.gov/server/rest/services/OpenData/ODP_RIMACServiceRequests/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` All 311 service-request records currently published in the public layer (726,942 counted independently on 2026-09-14). This is a full snapshot of the current published collection as it exists on this run: it captures each record's current fields and current status (open/closed) as published by the city, and rows absent from a later full scan are replaced. The city does not publish a retention or rolling-window guarantee for this layer, so this connector does not claim lifetime history — it describes the current public collection only. The layer is keyed by the city's native OBJECTID; SERVICEREQUESTID is also unique across the source. REQUESTEDDATETIME is NULL for most records (572,394 of 726,942), so a creation-date plan could never be complete; the snapshot reads the whole layer with resultType=standard, paging 32,000 records per request at measured depth (23 requests at depth 726,942). Date fields are returned as Unix epoch milliseconds and are preserved as bigint.	beta	full	replace	`OBJECTID`	-