What does the Everett WA 311 data include?

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

Do I need an account with Everett WA 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.

Everett WA 311

Public data

Ready to useNo account needed

Service requests reported to Everett, Washington's 311 line, as the city publishes them. 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

See which request types are most commonCount requests by type to see what residents report most.
Track when requests were last updatedSee when each request was created and most recently changed.
Map where requests happenPlot requests using their coordinates to see where they cluster.

What you get

Table	Each row is
Service requests `service_requests`	One service request
Request types `services`	One request type the city accepts

Good to know

Service requests: Each run re-reads everything and updates rows that changed. Rows the source removes stay in your table.
Request types: 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 Everett WA 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 Everett WA 311 data include?: 2 tables: service requests (one row per service request) and request types (one row per request type the city accepts).
Do I need an account with Everett WA 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Everett WA 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 everettwa_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` Each sync scans the public request collection using page-number pagination, without a creation-date horizon. Later edits are captured when the request is returned in a subsequent full scan. Returned request IDs are merged into the destination; previously synced requests remain if removed or no longer exposed by the source. Requests are not filtered by membership in the current service-type catalog. No claim is made about private requests or complete municipal history.	beta	full	merge	`service_request_id`	-
`services` Each sync reads the public service-type catalog and replaces the destination table; removed or no-longer-exposed service codes disappear. This catalog does not filter the requests collection.	beta	full	replace	`service_code`	-