Do I need an account with Houston TX 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.

Houston TX 311

Public data

Ready to useNo account needed

Houston TX 311 data, published as Houston TX 311 publishes it. 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.

50,844rows as of September 2026
About 2,000new rows a week
1 tablein your warehouse

What you get

Table Each row is

Table	Each row is
service_requests `service_requests`	All 311 case types from the CITY OF HOUSTON 311 ArcGIS layer SERVICE_REQUESTS (33 attribute fields). The layer holds a moving subset of Houston's cases - 50,839 rows with CREATED_ON from 2021-07-06 to 2026-09-16 on 2026-09-16 - and cases leave it after they close, so this is not a full-history archive and the row count shrinks over time. The whole layer is re-read at most once a day, about as often as the city regenerates it, and merged by CASE_NUMBER, so status/notes on re-opened cases refresh; a run less than a day after the last complete read reads nothing. OBJECTID and UID are row positions the city reassigns on every layer rebuild (they ran exactly 1..50,839 on 2026-09-16), so they are NOT stable case identifiers; CASE_NUMBER is the business key. A few case numbers appear twice in the layer (3 on 2026-09-16, including 2600266747, the same case exported once as 'Service Completed' and once as 'Routed'; 2 on 2026-09-24), so a read merges each pair into one row (the default _ingest_ingested_at dedup_sort keeps the newest) and the destination holds that many fewer rows than were yielded. CREATED_ON, RESOLVE_BY and CLOSED_ON are ArcGIS epoch-MILLISECOND integers and are stored as bigint with that unit documented.

service_requests

service_requests

All 311 case types from the CITY OF HOUSTON 311 ArcGIS layer SERVICE_REQUESTS (33 attribute fields). The layer holds a moving subset of Houston's cases - 50,839 rows with CREATED_ON from 2021-07-06 to 2026-09-16 on 2026-09-16 - and cases leave it after they close, so this is not a full-history archive and the row count shrinks over time. The whole layer is re-read at most once a day, about as often as the city regenerates it, and merged by CASE_NUMBER, so status/notes on re-opened cases refresh; a run less than a day after the last complete read reads nothing. OBJECTID and UID are row positions the city reassigns on every layer rebuild (they ran exactly 1..50,839 on 2026-09-16), so they are NOT stable case identifiers; CASE_NUMBER is the business key. A few case numbers appear twice in the layer (3 on 2026-09-16, including 2600266747, the same case exported once as 'Service Completed' and once as 'Routed'; 2 on 2026-09-24), so a read merges each pair into one row (the default _ingest_ingested_at dedup_sort keeps the newest) and the destination holds that many fewer rows than were yielded. CREATED_ON, RESOLVE_BY and CLOSED_ON are ArcGIS epoch-MILLISECOND integers and are stored as bigint with that unit documented.

How it works

Choose Houston TX 311. The data is public, so there is nothing to sign in to.
Pick where it goes. BigQuery, Snowflake, Databricks, Redshift and 9 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

Do I need an account with Houston TX 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Houston TX 311 data go to?: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, 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 houston_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://mycity2.houstontx.gov/gisweb01/rest/services/311/HOUSTON311_RECENT_SR_SNOW/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`service_requests` All 311 case types from the CITY OF HOUSTON 311 ArcGIS layer SERVICE_REQUESTS (33 attribute fields). The layer holds a moving subset of Houston's cases - 50,839 rows with CREATED_ON from 2021-07-06 to 2026-09-16 on 2026-09-16 - and cases leave it after they close, so this is not a full-history archive and the row count shrinks over time. The whole layer is re-read at most once a day, about as often as the city regenerates it, and merged by CASE_NUMBER, so status/notes on re-opened cases refresh; a run less than a day after the last complete read reads nothing. OBJECTID and UID are row positions the city reassigns on every layer rebuild (they ran exactly 1..50,839 on 2026-09-16), so they are NOT stable case identifiers; CASE_NUMBER is the business key. A few case numbers appear twice in the layer (3 on 2026-09-16, including 2600266747, the same case exported once as 'Service Completed' and once as 'Routed'; 2 on 2026-09-24), so a read merges each pair into one row (the default _ingest_ingested_at dedup_sort keeps the newest) and the destination holds that many fewer rows than were yielded. CREATED_ON, RESOLVE_BY and CLOSED_ON are ArcGIS epoch-MILLISECOND integers and are stored as bigint with that unit documented.	beta	staleness	merge	`CASE_NUMBER`	-

Setting up the destination is its own short guide, one per warehouse or lake: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL, Snowflake.

Other sources Ingest connects for government teams: Abilene TX 311, Albany NY 311, Ann Arbor MI 311, Anne Arundel County MD 311, Austin TX 311, Baltimore MD 311.

Get Houston TX 311 data into your warehouse

Last updated 2026-09-24.