[Outreach] Ask Comptroller to expose Late-Contracts Dashboard data via public API + confirm no fields dropped in Checkbook 2.0

[noneck]

This is a non-code, outreach / relationship task — not an MCP code change. (This repo has no outreach label; tagging documentation as the closest existing label and flagging the nature here in the body.)

Background

On 2026-07-08 the NYC Comptroller launched a Late-Contracts Dashboard (press release). Its two headline concepts — "average days late" and a non-profit vendor status filter — are not exposed in the public CheckbookNYC API, and our audit found no documented public API behind the dashboard at all (the page is JS-rendered and WAF-fronted; the press release and API docs describe no late-contracts domain, feed, or Open Data dataset).

Two specific things are missing from the public API today:

1. "Days late" derivation inputs — most directly, the prime-expense registration_date field our MCP would need to reproduce the metric (see the registration_date issue).
2. Non-profit vendor classification — the dashboard's non-profit filter is backed by a vendor-type classification that is absent from the documented Contracts API. We cannot reproduce it without a source the Comptroller has not published.

The ask (this is the "ensure dropped/missing data is brought back / made available" task)

Reach out to the Comptroller's office to:

(a) Confirm the "Checkbook 2.0" migration did not drop or remove any previously documented API fields or domains. (Our audit found the API surface unchanged, but a direct confirmation from the office closes the loop.)

(b) Request that the data powering the new Late-Contracts Dashboard be exposed through the public API so civic-tech tools can reproduce the analysis — specifically:

• the fields needed to reproduce "days late" (e.g. the prime-expense registration_date derivation), and
• the non-profit vendor classification used by the dashboard's non-profit filter.

Why it matters

If the dashboard's underlying data stays dashboard-internal, third-party accountability tools (including this MCP) cannot independently reproduce or extend the Comptroller's own late-contracts analysis. Exposing it through the documented public API is what makes the accountability data actually reusable.

Reference

See the API audit: team/engineering/2026-07-09-checkbook-2.0-api-audit.md (§3 "Explicitly NOT available" and Blockers 2 & 3).

[noneck]

Folded into a single letter to the Comptroller's office, drafted 2026-07-21. Not yet sent.

A separate problem surfaced on 2026-07-21: the documented XML API at POST /api began returning HTTP 403 from Imperva Incapsula, so BetaNYC currently cannot reach the Checkbook API at all (details in #21). That required its own letter to the same office.

Sending two approaches to one office in the same window is worse than one letter carrying both, so this issue's asks are now part of that letter rather than a separate outreach. Draft lives at people/noel/work/2026-07-21-comptroller-checkbook-api-access-letter.md in the workspace repo.

Both asks from this issue are carried verbatim in substance:

• (a) Direct confirmation that the Checkbook 2.0 migration dropped no previously documented API fields or domains. Framed as asking them to confirm what our own audit already found, so we can state it rather than infer it.
• (b) Exposing the Late-Contracts Dashboard data through the public API, naming both specifics from this issue: the prime-expense registration_date needed to reproduce "average days late," and the non-profit vendor classification behind the dashboard's filter.

One framing choice worth recording. The letter says that if those fields do not exist as data, knowing that is equally useful — because it would tell us the dashboard's numbers are not independently checkable, and we would stop trying to reproduce them. That is a real answer rather than a brush-off, and offering it makes the ask harder to ignore than a request that only accepts yes.

Access comes first in the letter because it is the blocker; these questions come second because they are the substantive ones. The recommended subject line names the Late-Contracts data specifically, since a policy staffer will care about that and not about our 403.

Leave this issue open when the letter sends. The ask will have been made, not answered. It closes when the office responds, or when we decide to stop pursuing it.

Sourced from this issue and from team/engineering/2026-07-09-checkbook-2.0-api-audit.md.

[noneck]

Answered by the Comptroller's office (2026-07-24). Outcomes:

1. Did Checkbook 2.0 drop any documented fields or domains? No. The migration retained the full documented API surface, and external applications can continue using the API without going through the web interface. We can now state this rather than infer it from our own testing.

2. Late-Contracts data via the public API: Prime Registration Date is available as a response field (see Contracts: expose registration_date filter + response column (enables 'days late' analysis) #6). The non-profit vendor classification is not exposed, and they will consider it for future platform enhancements.

3. Open Data catalog drift: both entries are being corrected. kpnf-sajf refresh frequency is moving to Historical (the linked publication series has moved to the newsroom newsletter), and mxwn-eh3b has already been updated to replace the http:// link with https://.

4. Accessibility audit: routed to their web team for review.

5. API access: not yet restored. Retested 2026-07-24 from two independent networks, both still returning HTTP 403. Fresh timestamps and incident IDs sent back to them. Root cause on their side was automated blocking triggered by retry-without-backoff, which we have confirmed exists in our own client — see Client follows HTTP redirects by default: one logical API call can reach the origin as ~40 requests #23, fetchWithRetry retries immediately with no backoff #24, Remove or hard-gate /smart_search: the data owner has confirmed it is not part of the supported API surface #25.

They have offered a call with their technology team. Outreach objective is met; leaving open until access is actually restored.