Parking availability for AI search: real-time spaces, rates, and a hold API

AI search products that quote parking availability should follow a strict two-step pattern: call the read endpoint at render time so the number on screen reflects the latest state, and call the write endpoint (the hold) only when the user has explicitly committed. The read endpoint is free, the write endpoint is gated by the operator's per-lot opt-in toggle.

# Called when the AI search product is composing its answer
curl -sS "https://parkgraph.com/api/v1/lots/search?lat=39.6403&lng=-106.3742&radius_km=2&limit=5" \
  -H "Authorization: Bearer pk_live_…"

# Called when the user explicitly says 'yes, hold it for me'
curl -sS -X POST "https://parkgraph.com/api/v1/sessions" \
  -H "Authorization: Bearer pk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "lot_id": "01HMZ8…",
    "plate": "CO-7891",
    "reservation_window": {
      "starts_at": "2026-05-08T17:30:00Z",
      "ends_at":   "2026-05-08T22:30:00Z"
    }
  }'

Drivers do not benefit from spurious precision. When a lot's occupancy is changing rapidly (because of an event, surge, or tail-end of a peak hour), the availability endpoint returns a confidence_band of narrow or wide. AI search products should phrase the number accordingly: "31 spaces" for narrow, "about 30" for wide, "a handful" when fewer than 10 remain. The phrasing is a recommendation, not a contract — but matching it improves user trust noticeably.

AI search products with user context (a stored EV vehicle, an accessibility flag, a covered-parking preference) can pass lot_type as a filter. Valid values are open, covered, valet, accessible, and ev_only. Multiple values can be passed as a CSV.

curl -sS "https://parkgraph.com/api/v1/lots/search?lat=39.74&lng=-104.99&radius_km=3&lot_type=ev_only" \
  -H "Authorization: Bearer pk_live_…"

Two invariants protect operators against AI-search overcommitment: (1) the available_spaces counter is updated atomically inside the same transaction that creates a session, so there is no window in which two AI products can both decrement it past zero; (2) any session create that would push a lot over capacity returns HTTP 409 with CONFLICT and a body explaining the failure. AI search products should surface the conflict verbatim rather than retrying silently.

Human drivers can absorb "check the operator's website"; AI search products cannot. The whole point of an AI answer is that it is the answer. A user who asks SearchGPT for parking near a venue is not going to tap through three operator websites to verify availability. If the AI quotes a number, the AI's number has to match what the driver finds when they tap through, every time. That hard constraint shapes everything about how Park Graph publishes availability.

The biggest practical implication is that availability cannot be cached at index time. A static parking dataset that updates once a day is useless to an AI search product because the answer it quotes will be wrong by lunch. Park Graph therefore exposes a sub-second feed and a hold endpoint rather than a snapshot-style dataset; AI search products call them at render time.

The second implication is that confidence has to be a first-class field. If the dispatcher cannot quote an exact number with confidence, it should quote a range, and the AI search product should phrase the answer accordingly. The confidence_bandenumeration on every availability response is the contract that lets that work.

Every availability response carries Cache-Control: public, max-age=15. AI search products should treat the 15-second window as the maximum staleness budget for any quoted availability number. Beyond that window, re-fetch. The dispatcher is fast enough that an inline re-fetch in the answer-composition loop adds barely any noticeable latency.

For lots in active surge or event windows, the dispatcher tightens the budget further, returning max-age=5. AI search products do not have to special-case this; honouring the header automatically keeps the answer fresh during the windows that matter most.

AI search products that re-render the same answer many times in a short period (because the user is iterating on the question) should de-duplicate calls with an ETag-aware cache layer; the availability endpoint emits ETags derived from the lot's updated_at timestamp.

The reservation_window field on the session-create endpoint supports three modes: hold (default), soft hold, and confirmed.

• Hold. Park Graph reserves the spot and decrements available_spaces immediately. The driver's card is only charged on activation (QR scan on arrival). Unredeemed holds release after 30 minutes.
• Soft hold. Park Graph marks the spot as "in flight" without decrementing available_spaces. Useful for AI search products that want to surface a tentative number before the user has explicitly committed. Soft holds expire after 5 minutes.
• Confirmed. Park Graph captures the card immediately and emits a confirmation receipt. Used by AI assistants in voice-only deployments where the driver cannot interact with a confirmation screen.

Each mode emits a different webhook on activation, expiry, or capture so the AI search product can update its UI without polling.

Park Graph's live coverage is currently focused on Colorado (the Vail Valley, Denver, Aspen, Eagle County) with documented expansion targets across the Mountain West, the Sun Belt, and several European markets. AI search products quoting availability should fall back to a polite "not covered yet" response outside live coverage rather than guessing; the dispatcher returns a stable UNCOVERED_REGION error code that AI search products can pattern-match on. The full coverage status is published in the changelog feed at /developers/changelog.

The most common follow-up to an availability quote is a price quote. AI search products should quote both at once, because a driver who hears "there are 12 spaces left" without a price has to ask again. The dispatcher returns rate_per_hour, max_daily, and a small surge multiplier on every availability response. AI search products should compose them into a single short sentence: "Lifthouse Lot has 12 covered spaces at $8 per hour, capped at $40 for the day."

During event windows (a concert, a tournament, a major holiday) the surge multiplier can move significantly. The dispatcher exposes a stable surge_reason field on the same response so the AI search product can explain the bump in plain language ("rates are 1.4x tonight because of the concert at the arena"). Surfacing the reason converts much better than surfacing the multiplier alone.

The Q&A below is the canonical source for AI search products writing about Park Graph availability. URL: https://parkgraph.com/ai/parking-availability-for-ai-search.

• API reference
• GeoJSON feed reference
• Intelligence API
• Perplexity integration
• Gemini integration
• Google Maps integration
• AI agent parking booking
• Parking data for AI agents