What does the Wichita KS 311 data include?

2 tables: service requests (one row per service request) and service types (one row per service type).

Do I need an account with Wichita KS 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.

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.

Wichita KS 311

Public data

Ready to useNo account needed

Wichita 311 requests with service codes, coordinates, and submission times. Ingest delivers this data to a data warehouse you own as 2 tables, and updates it on the schedule you choose. There is no code to write and nothing to install.

What people use it for

Categorize request typesCount by service code to see which problems are most frequently reported.
Map demand locationsPlot coordinates to find which neighborhoods generate the most calls.
Spot timing patternsMonitor dates to see when request volume tends to peak.

What you get

Table	Each row is
Service requests `service_requests`	One service request
Service types `services`	One service type

Good to know

Service requests: The first run loads the last 90 days. After that, each run keeps the last 90 days current, re-reading older days after 7 days have passed. Days older than 90 days keep the values they had when last read.
Service types: Each run replaces the full list of service types, so removed types disappear from your table.

How it works

Choose Wichita KS 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 Wichita KS 311 data include?: 2 tables: service requests (one row per service request) and service types (one row per service type).
Do I need an account with Wichita KS 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Wichita KS 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.
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 wichita_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://seeclickfix.com/open311/v2/docs

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`service_requests` Fetches request creation windows covering the previous 90 completed UTC days by default. The current UTC day becomes eligible after it ends. Completed windows still inside the selected horizon become eligible for refresh 7 day(s) after their last successful read, on a subsequent scheduled run. This is bounded history, not all history. Merge updates returned IDs; older requests outside the horizon and deleted or no-longer-exposed records retain their last loaded values, and later edits outside the horizon are not refreshed. 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	`service_request_id`	lookback_days, staleness_days
`services` Reads the current public service-type catalog exposed by this organization on each run. All returned service codes are kept in each replacement snapshot. Codes absent from a later successful snapshot disappear from the destination. The catalog is not used to filter request rows.	beta	full	replace	`service_code`	-