City open data portals as a way in

The wall is references, not capability

A municipal solicitation for data or analytics work almost always asks for comparable engagements: three references, similar scope, similar size, ideally in the public sector. A firm that can do the work but has never done it for a city fails that question on paper before anyone reads the technical approach. The usual advice — team with an incumbent, wait for a small purchase, keep bidding — is slow and expensive, and it puts your first credible municipal proof point on someone else's schedule.

There is one exception, and it is structural rather than clever. Cities publish their data on purpose, under a local ordinance or executive order that obligates departments to release it. The publication is machine-readable, the interface is documented, and the record for each dataset carries the name and email of a city employee who is accountable for it. No permission is required to read any of it. That means a firm can do real, specific, verifiable work on a city's actual data before any relationship exists — and can arrive at the first conversation holding a finding rather than a capability claim.

This is not a growth hack. Done badly it produces unsolicited dashboards that annoy busy people. Done well it produces a scoped defect, a fix, and a named person with a reason to answer. The difference is entirely in what gets built and how it is handed over. What follows is the mechanics: what the portals actually expose, what a measurement of six of them shows, how the license question is answered before any code is written, which artifacts read as competence, and how a piece of unpaid proof turns into a purchase order.

What the portals actually expose

Three platform families carry most of the American municipal market, and each one exposes a documented catalog interface. Knowing which family a city is on takes one request and determines everything about how you work with it.

Socrata. Acquired by Tyler Technologies and sold today as Tyler Data & Insights, with developer documentation still published at dev.socrata.com. Each dataset is queryable through the SODA API without downloading it whole, and a cross-portal Discovery API at api.us.socrata.com/api/catalog/v1 returns the inventory of any Socrata domain, including a last-updated timestamp per asset.

CKAN. Open source, currently at release 2.11.5. Its Action API answers at /api/3/action/package_search on any CKAN portal and returns package records with a license identifier, a maintainer, resource counts, and a metadata modification date. Boston runs one at data.boston.gov.

Esri ArcGIS Hub. The default for cities whose data program grew out of the GIS shop. Hub sites publish a harvest feed at /api/feed/dcat-us/1.1.json; the Los Angeles GeoHub returns 1,678 dataset records at that path. OpenDataSoft is a fourth platform with a smaller American footprint.

Underneath all three sits one convention. Catalog files declare conformance to the Project Open Data metadata schema — DCAT-US v1.1 — which is the same schema federal agencies use for the inventories harvested into data.gov. A successor, DCAT-US 3.0, is published at resources.data.gov along with a migration guide, but the city files in circulation today still emit v1.1. Practically, this means one parser reads every city catalog you will encounter, and the fields you get are stable: title, publisher, description, keywords, a contact point, a modification date, and a list of distributions.

Two of those fields do most of the work. The modification date tells you which parts of the catalog have stopped moving. The contact point tells you who to write to. Across the four Socrata catalog files measured for this piece, every single dataset record carried a contact email — 1,122 of 1,122 in Chicago, 2,704 of 2,704 in New York, 707 of 707 in San Francisco, 2,874 of 2,874 in Austin. The addressable surface is published, by the city, at its own request.

What one afternoon of measurement shows

In August 2026 we pulled the published catalog file from six city portals across all three platform families and computed two things per portal: the share of entries carrying a machine-readable license identifier, and the share whose stated modification date was more than a year old. Both are one HTTP request and about twenty lines of code. Neither requires an account.

Two caveats belong with those numbers, and stating them is part of what makes the artifact credible rather than sloppy. First, the modification date in a Socrata catalog file can move on a metadata edit, and CKAN's metadata_modified tracks the record rather than the underlying file, so neither is a clean measure of data freshness. Second, a large share of any city catalog is deliberately static — election results from a past cycle, a one-time capital project extract, a historical boundary file. An old date on those is correct, not broken.

So the table is not a defect count. It is a map of where to look, and it makes one point that matters for anyone approaching a city cold: staleness is the normal condition of a municipal catalog, not a scandal. Every program manager already knows it. Nobody is embarrassed by it. What they lack is capacity, which is a very different conversation from the one where you tell a city its data is bad.

The license question, answered before anything is built

Public does not mean unrestricted, and the machine-readable answer is inconsistent enough that guessing is a real risk. The same six catalogs, sorted by how often a license is actually declared in the record:

Where an identifier is present, it is usually one of a small set. San Francisco publishes 553 of its 707 entries under the Open Data Commons Public Domain Dedication and License. Boston declares 216 of 232 under the same license. New York declares Creative Commons Attribution 4.0 on 57 entries and the Open Database License on one. Chicago declares none at all in the machine-readable record, which means the governing terms are whatever the portal's site-wide terms of use say.

The Los Angeles row deserves its own note, because it is the failure mode most likely to catch out an automated check. The GeoHub license field is populated on two-thirds of its entries — 1,120 of 1,678 — but almost none of it is an identifier. It is free-text use-constraint prose inherited from the underlying ArcGIS item records, frequently including raw HTML markup and font styling, and it says things like "the data herein is for informational purposes." A script that tests whether the field is non-empty scores that portal as well documented. A script that tests whether the field is a resolvable license identifier scores it at 1%. The second script is right, and the difference means every ArcGIS Hub record has to be read by a human before anything derived from it ships.

Three practical rules follow. Record the license string and the retrieval date for every dataset you touch, inside the artifact itself, not in a side note — an evaluator or a city attorney reading your work should never have to ask where the data came from or under what terms. When the catalog is silent, read the portal's posted terms of use and quote them in the write-up rather than assuming public domain. And treat attribution and share-alike licenses as design constraints rather than footnotes: a public-domain dedication is a clean base for anything you intend to commercialize, while the Open Database License carries share-alike consequences that reach a derived database and deserve a lawyer's read before you build a product on it.

One more piece of context, because it is a common misreading. The federal open data statute — the OPEN Government Data Act, enacted as Title II of Public Law 115-435 on January 14, 2019 — makes open and machine-readable the default for federal agencies and requires each to maintain a data inventory. It does not reach cities. Municipal obligations come from local ordinance, so there is no national default license and no national default anything. The schema conventions travel; the legal terms do not.

Four artifacts that read as competence

A catalog freshness audit. Pull the catalog file, compute the age distribution, separate the deliberately static datasets from the ones that were supposed to keep moving, and hand back a ranked list with the responsible department named on each row. This is cheap to produce and immediately useful to a chief data officer who is accountable for an annual publishing plan and has no instrumentation behind it. The caveats above go in the document, prominently. A finding that survives its own caveats is worth more than a bigger one that does not.

A conformance report against a published specification. Some municipal data has a real standard with a real validator, which turns a subjective quality argument into an objective pass or fail. Transit is the strongest case: the General Transit Feed Specification has a canonical open-source validator maintained by MobilityData, at release 8.0.1 as of May 2026, that produces a machine-readable report against the current reference. Service request data has Open311 GeoReport v2, whose specification is frozen and finalized, so conformance is checkable rather than debatable. Not every domain has this — building permit data, for instance, has no comparably maintained national specification in circulation, and the domain that once hosted one is now a parked page. Say so when it is true rather than inventing a standard to measure against.

A pipeline that replaces a manual publish. The most common failure mode in a city data program is a person. Someone runs a query against the permitting or finance system on the first business day of the month, exports a CSV, opens the portal console, and uploads it. When that person changes roles, the dataset stops. Replacing the ritual with a scheduled extract, an explicit schema contract, a validation step, and a push through the portal's own publishing interface is well-bounded work with an objective finish line, and it is the piece a program manager can defend to a finance director.

A re-identification review. Published municipal data is redacted one dataset at a time and joined by the public all at once. A review that takes two or three already-public extracts, joins them the way a reporter would, and shows where the combination narrows to a household is genuinely valuable and genuinely uncomfortable — which is why it must be delivered privately, to the data owner, with the method shown and the result never published.

Two things that do not work, and it is worth being blunt about why. A dashboard nobody asked for duplicates what the portal already renders and maps to no line item in anyone's budget. A chat interface over the catalog raises a security review, a hosting question, and a records-retention question while fixing nothing the city had written down as a problem. Both are demonstrations of enthusiasm. Neither is a demonstration of engineering, and a city that has been pitched twice this quarter can tell the difference in about ten seconds.

The accessibility deadline moved, and that changes the conversation

On April 24, 2024 the Department of Justice published a final rule under Title II of the Americans with Disabilities Act setting a technical standard for state and local government web content and mobile applications: WCAG 2.1, Level AA. That rule set two compliance dates, keyed to population.

Those dates have since moved. On April 20, 2026 the Department published an interim final rule, "Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities" (RIN 1190-AA82), effective the day of publication. The compliance date for entities with a total population of 50,000 or more moved from April 24, 2026 to April 26, 2027. The date for entities under 50,000 and for any special district government moved from April 26, 2027 to April 26, 2028. It was issued as an interim final rule with a request for comments, so the docket is open and the dates are settled for now rather than settled permanently — a distinction worth stating accurately to a client rather than smoothing over.

A data portal is web content. So are the dashboards built on top of it, the map viewers embedded in department pages, and the documents linked from dataset landing pages. The extension did not remove any of that work; it moved which budget year it lands in, and it gave cities that had fallen behind a second planning cycle. For a firm looking for a way in, this is the rare situation where an externally imposed, dated obligation supplies the reason to act, and a specific finding on a specific page supplies the scope. Color-only encodings in a published chart, unlabeled map controls, and untagged legacy documents are all concrete, all demonstrable in a short report, and all attached to a deadline the city did not choose.

From artifact to purchase order

The sequence below is the part most firms get wrong, usually by sending the work to procurement instead of to the person who owns the problem.

Step five is where the thresholds matter, and they are worth getting exactly right because a proposal priced above a city's informal ceiling converts a two-week decision into a six-month one. A city buying with its own money follows its own municipal code, and those ceilings vary widely enough that the only correct move is to read the code for the specific jurisdiction. A city spending federal pass-through money follows the Uniform Guidance at 2 CFR part 200, which is uniform and worth knowing by heart.

Under 2 CFR 200.320, informal procurement methods may be used when the transaction does not exceed the simplified acquisition threshold, and micro-purchases may be awarded without competitive quotations when the price is documented as reasonable. The thresholds are defined by reference to the Federal Acquisition Regulation: as currently published at 48 CFR 2.101, the micro-purchase threshold is $15,000 and the simplified acquisition threshold is $350,000, both with narrower exceptions for construction, service contract labor standards, and contingency operations. On top of that, 2 CFR 200.320(a)(1)(iv) lets a recipient self-certify a micro-purchase threshold of up to $50,000 on an annual basis, with a written justification and supporting documentation; anything above $50,000 requires approval from the cognizant agency for indirect costs.

The practical read for a first engagement: a well-scoped fix priced under the city's micro-purchase ceiling can be bought on a documented price-reasonableness determination, without a solicitation, by someone who already believes you can do the work because you already did a piece of it. That is the whole play. It is also why the artifact must be narrow — a $12,000 fix with a named owner is purchasable, and a $200,000 platform proposal from a firm with no municipal references is not.

What to send, and to whom

The data owner. The contact point on the catalog record, which is a published, working city email address in every Socrata catalog measured above. That person is accountable for the dataset and is the only one who can confirm your finding is real.

The chief data officer or open data program manager. Owns the publishing plan and the portal relationship, and is usually the first person who knows whether money exists. Copy them; do not lead with them.

The CIO's office. Enters the picture the moment anything touches the network or leaves it. They are not the audience for the first email, but a first email that pretends they do not exist ages badly.

The email itself is short: the defect, the evidence, the fix, the license and retrieval date for every input, and one sentence on what it would take to make the fix permanent. Attach the artifact. Do not attach a capability deck, do not ask for a call, and do not describe the finding as an opportunity. A city employee who opens a message and finds a specific problem on their own dataset, already solved, with the provenance documented, is being handed something useful by someone who understood the constraint. That is the impression that survives to the second conversation.

Where the line is

Bottom line

A city open data portal is the only part of a municipal government that is designed to be used by strangers. It publishes its own inventory, declares its own schema, names its own staff, and — as the measurements above show — carries visible, well-understood gaps that its program office already knows about and does not have the capacity to close. A firm that reads that catalog carefully, picks one defect, fixes it properly, documents the provenance, and hands it to the person responsible has done something no capability statement can do: it has demonstrated the work on the customer's own data, before the customer spent anything. Then the first engagement is a small, purchasable, defensible piece of scope rather than a leap of faith, and the reference problem starts solving itself.

Frequently asked questions