Five Socrata registries, two working filters: 'active only' quietly no-ops in three states

A write-up published on dev.to documents a childcare-license scraper that reads five state registries through Socrata's SODA API and exposes a single `activeOnly` toggle to callers [s1c1]. According to the author, that toggle only actually filters two of the five states, so the other three keep returning closed and revoked facilities to someone who believes the filter applied [s1c2].

The five registries are New York, Connecticut, Colorado, Delaware and Texas, and all five accept the same `$where` query syntax [s1c1]. That is where the resemblance ends. New York filters on `facility_status='Active'`; Connecticut on `status='ACTIVE'` [s1c3]. Colorado and Delaware have no status column in the dataset at all, so there is nothing to filter on [s1c4]. Texas does publish a status column, `operation_status`, but it is not wired into the active-only filter, so toggling `activeOnly` changes nothing for Texas rows in either direction [s1c5].

The mechanism is one line: `if active_only and config.active_where`, and only then is a `$where` parameter added to the request [s1c6]. If a state's config carries no `active_where` fragment, the toggle is a no-op for that state [s1c7]. The author frames this as deliberate, on the grounds that forcing a fake filter onto data that does not support one is worse than being honest that it is not filterable [s1c7]. That is a defensible engineering position and a terrible default for a downstream consumer, because the API contract is identical in both cases: same parameter, same response shape, silently different meaning. Three of five states, or 60 percent of the coverage, return unfiltered results while the request looks successful [s1c8].

Note also that the two filters that do work are not the same filter. Different column names, and different literal casing for the value: `'Active'` in New York against `'ACTIVE'` in Connecticut [s1c9]. A single hardcoded `$where` fragment would fail against one of the only two states where filtering is possible at all.

The same divergence shows up in every other field. Licensed capacity is not reliably numeric across the five datasets, so the parser attempts `int()` and falls back to the raw string rather than failing the row; the author's illustration is a run that dies partway through because one state shipped something like `"N/A"` or a range string in a capacity column [s1c10]. Texas is the only one of the five that publishes `email_address` and `website_address` in the open dataset, so the row model carries email and website as nullable fields populated for one state and `None` everywhere else, with no cross-state equivalent to fall back to [s1c11]. New York splits the address into `street_number` and `street_name` rather than a single column, which makes address assembly state-specific [s1c12]. The author's explanation is that each state government designed its own schema independently, decades apart, with no shared spec [s1c12]. Records with a null or empty facility name are dropped rather than emitted as blank rows [s1c13].

What to watch: whether Texas gets wired into the filter, since the status value is already present per row and can be filtered downstream today [s1c5][s1c14], and whether Colorado and Delaware ever add a status column, because until they do no API-level toggle can honestly claim to return active licenses only [s1c4].