DDDailyDog/ API docs

Reference

Changelog

v1.1.11 · August 7, 2026

Erasure keeps its promise — and an audit copy

  • DELETE /v1/profile behaves exactly as before: 204, idempotent, the username freed instantly, and everything gone from every public surface and your own history. Internally the erased rows are now retained with a deletion stamp for fraud prevention, moderation integrity, and legal compliance — they are never served anywhere.

v1.1.10 · August 7, 2026

Erase your profile

  • DELETE /v1/profile removes the device's profile, reviews, and photos — permanently. The username is freed, hidden and disputed reports are erased too, and the call is idempotent. Requires X-Device-Id.

v1.1.9 · August 5, 2026

Report caps ride the device

  • Recast: an establishment is never capped — a busy listing can receive any number of reports a day from distinct devices. The limits are per-device: at most 3 reports per establishment per UTC day, and 25 per day citywide, per device. Hidden reports count toward neither cap.
  • The 429 error body still carries scope: "establishment" means you personally hit the 3-per-spot limit; "device" means you hit your citywide 25. Messages updated to match.

v1.1.8 · August 4, 2026

Community reports and per-download profiles

  • New Community reports surface: POST/GET /v1/restaurants/{camis}/reports let a device file and read user-submitted issue reports (pests, food poisoning, other sanitation) and praise (taste, cleanliness). Device-keyed via the X-Device-Id header; the server stores only a salted hash and never exposes it. Photos ride as base64 (JPEG/PNG, ≤4MB, max 3) and are re-encoded server-side to strip EXIF; serve them from GET /v1/reports/photos/{photoId}.
  • Restaurant profiles (GET /v1/restaurants/{camis} and POST /v1/restaurants/batch) gain a community block: { counts by kind, lastReportAt, scoreAdjustment }. scoreAdjustment is a capped, decaying dock in [-8, 0] — unverified negative reports move the score a little, never past -8, fading over 90 days; praise never adds points; hidden reports count for nothing.
  • Per-download profiles: GET/PATCH /v1/profile (claim or rename a username — 409 taken, 429 on the 14-day rename throttle), POST /v1/profile/avatar, GET /v1/profiles/avatars/{id}, GET /v1/profile/username-check, and GET /v1/profile/reports (your own history, INCLUDING hidden reports marked honestly). Unclaimed devices render a stable, friendly generated name.
  • Rate limits: 3 non-hidden reports per establishment per UTC day, and 5 per device per day citywide — either returns 429 with honest copy.
  • Strictly additive: no existing field or behavior changed. dd_test_ keys serve a seeded fixture establishment (90000005) so you can build the whole flow before going live.

v1.1.7 · August 4, 2026

Recency-weighted sanitary story

  • The vermin and sanitary blocks gain additive weighted variants: every finding is weighted 0.5^(ageDays/365) — a 12-month half-life — so a citation from three weeks ago counts ~1.0 and one from three years ago ~0.125.
  • vermin.weighted carries per-species weighted citation counts (same 3-year window). sanitary.weighted carries criticalFood (24-month window), closures (36-month window), and worstScoreWeight — the 0–1 recency weight of the inspection behind worstScore36mo, so the worst-score story can age honestly.
  • The flat counts are unchanged and stay forever — strictly additive. Consumers wanting a 'how bad is it NOW' number should prefer the weighted fields.

v1.1.6 · August 4, 2026

Search that forgives typos and knows where you are

  • GET /v1/restaurants/search is now typo-tolerant: slight misspellings (chipotel, chiptole, dos torros) still find the establishment. Exact matches always outrank fuzzy ones, and the closest spelling wins among fuzzy candidates.
  • Optional lat + lng (NYC coordinates, together) enable proximity ranking: equally-good matches sort nearest first, and every result gains an additive distanceMeters. Distance breaks ties — it never beats a better name match.
  • Location words, punctuation-insensitivity, partial-place typeahead, and the trailing-token retry all behave exactly as before.
  • Strictly additive: no existing field or behavior changed.

v1.1.5 · July 31, 2026

The owner-response signal

  • Restaurant profiles (GET /v1/restaurants/{camis} and POST /v1/restaurants/batch) gain a remediation object — { openViolations, documentedOpenViolations, categories, lastDocumentedAt } — present when the operator has uploaded proof of correcting a currently-open violation, and null otherwise.
  • The sanitary block gains ownerResponseSignal: "documented_fixes" | null, set whenever documentedOpenViolations ≥ 1.
  • This is a transparent response indicator: the uploads are owner-submitted and unverified, pending re-inspection, so it NEVER changes the grade, score, or risk — those stay anchored to official city records. Render it as information, e.g. “Owner has documented fixes for 3 of 5 open items — pending re-inspection”.
  • The fixture city carries a documented example: CAMIS 90000003 (dd_test_ keys) returns a populated remediation block and signal.
  • Strictly additive: existing fields are unchanged, so current consumers are unaffected.

v1.1.4 · July 23, 2026

Violations on the map

  • GET /v1/violations entries now carry latitude, longitude (both null when the record lacks coordinates), and zip — enough to pin every citation.
  • Geo filtering: lat + lng (NYC coordinates) with an optional radius in meters (default 1,000, max 5,000) pulls the citations inside a circle — built for map viewports, and it combines with category, critical, since, until, and the rest.
  • Strictly additive: existing queries and response consumers are unaffected.

v1.1.3 · July 22, 2026

Search keeps up with your typing

  • Partial place names match as you type: “joes willia” already scopes to Williamsburg — mid-typed neighborhoods and boroughs (≥3 characters) prefix-match the known places, unioning zip sets while a prefix is still ambiguous (“green” covers Greenpoint and Greenwich Village until more letters arrive).
  • A query whose trailing token matches nothing is retried once without it, so typeahead suggestions never vanish between keystrokes of a query that will succeed.
  • Response shape unchanged; applies to GET /v1/restaurants/search.

v1.1.2 · July 22, 2026

Search that understands places and punctuation

  • GET /v1/restaurants/search is location-aware: “dos toros williamsburg” searches the name in the neighborhood. ~180 NYC neighborhoods and abbreviations (LES, UWS, LIC, FiDi…), boroughs and their slang (bk), and bare zips are recognized at the end of the query — with automatic citywide fallback, so a place word never makes results worse.
  • Name matching is punctuation-insensitive on both sides: “joes” finds JOE'S PIZZA, “lindustrie” finds L'INDUSTRIE PIZZERIA.
  • Results rank exact-name-prefix matches first. Response shape unchanged.

v1.1.1 · July 22, 2026

The sanitary block: food safety, separated from paperwork

  • Restaurant profiles (GET /v1/restaurants/{camis} and POST /v1/restaurants/batch) gain a sanitary object — the food-safety story computed from health-inspection records only; enforcement and administrative records are excluded.
  • Fields: latestCycleScore, latestInitialScore (the steady-state signal — re-inspections score flatteringly), worstScore36mo, criticalFood24mo, openFoodViolations, closures36mo.
  • The fixture city carries deterministic sanitary blocks on all eight establishments.

v1.1 · July 21, 2026

The depth release: browse, feeds, batch, deadlines, test mode

  • City-wide browse & filters: GET /v1/restaurants (borough/zip/cuisine/grade/score/risk/vermin filters) and GET /v1/contractors.
  • City-wide feeds: GET /v1/violations (every citation, filterable by code/category/borough/date) and GET /v1/inspections (what closed this week).
  • Batch endpoints: POST /v1/restaurants/batch (50), /v1/properties/batch (25), /v1/contractors/batch (25) — with meta.notFound for misses.
  • The compliance calendar as an API: GET /v1/properties/{bbl}/deadlines — facade/benchmarking/emissions/elevator/boiler/registration obligations with due dates, statuses, and what to do.
  • Itemized dockets: /v1/properties/{bbl}/violations + /permits, /v1/contractors/{slug}/tickets with reopenableOnly (live 75-day windows) and hearingAfter.
  • Meta & stats: /v1/meta/cuisines, /v1/meta/boroughs, /v1/meta/violation-codes, /v1/stats/restaurants.
  • Cursor pagination, multi-value filters, since/until, sorting, and strict unknown-param rejection on all new list surfaces.
  • Test mode: dd_test_ keys answer every endpoint from a deterministic fixture city; every commissioned key ships with its test twin; these docs run on a shared public test key.
  • Platform: GET /v1/health, GET /v1/openapi.json (the machine-readable contract), RestaurantSummary gains openViolations, /v1/me gains mode.
  • These docs: rebuilt as a reference generated from the OpenAPI document, with per-endpoint consoles, guides, and dark mode.

v1.0 · July 21, 2026

Launch

  • Restaurants: search, nearby (geo radius), full profile (risk + vermin report + fines), inspection history, violations.
  • Properties: address search, profile by BBL (risk, open counts, judgment exposure, per-agency rollup).
  • Contractors: company search, docket profile with the reopen-window savings envelope.
  • Bearer API keys (SHA-256 at rest, shown once), commissioned daily limits with X-RateLimit headers, /v1/me introspection.