What does the San Gabriel CA 311 data include?

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

Do I need an account with San Gabriel CA 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 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.

San Gabriel CA 311

Public data

Ready to useNo account needed

Problems residents report to the City of San Gabriel, California, with when each was reported and how it was resolved. 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.

4,886service requests as of September 2026
About 10new service requests a week
1 tableone row per service request

What people use it for

Spot duplicate reportsUse the duplicate flag to find related requests and consolidate efforts.
Track staff workloadSee who is assigned to requests to balance work across the team.
Measure work speedCompare resolution dates to see how long problems take to fix.

What you get

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

Good to know

Each run replaces the table with the currently published requests, so resolution changes and status updates show up on the next run. Requests the city removes from the layer disappear on the next run.

How it works

Choose San Gabriel CA 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 San Gabriel CA 311 data include?: One table, service requests, with one row per service request.
Do I need an account with San Gabriel CA 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can San Gabriel CA 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 the currently published requests, so resolution changes and status updates show up on the next run. Requests the city removes from the layer disappear on 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 sangabriel_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://services8.arcgis.com/00P6VbLtS94ANPBW/arcgis/rest/services/CitizenProblems/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` All public 311 service-request records currently published in the City of San Gabriel's "Citizen Problems" layer — 4,886 records counted on the live service on 2026-09-13 (returnCountOnly) — including reporter contact fields, multiple email columns, narrative details and resolution status. This is a full snapshot of the current published collection as it exists on each run: every run re-reads the whole layer and REPLACES the destination table, so a record the city removes from the layer disappears from the destination on the next run. The city publishes no retention or rolling-window guarantee for this layer, so this connector claims the current public collection only, not lifetime history. Rows are keyed by the layer's native OBJECTID (the vendor-declared OID field, backed by a unique clustered index); probid / New_Problem_ID is a nullable business label and is not used as the key. Date fields (CreationDate, EditDate, resolutiondt, Submitted_On) arrive as Unix epoch MILLISECONDS and are preserved as bigint integers — no date conversion is applied.	beta	full	replace	`OBJECTID`	-