AI agent parking booking: how LLMs find, hold, and pay for parking

Drivers increasingly start every consumer task — a flight, a hotel, a dinner reservation, a hospital appointment — inside a generative AI assistant. The assistant has the destination, the time window, the number of people, and the driver's license plate. What it does not have, today, is a way to commit to a specific parking spot the way it can commit to a flight on Expedia or a table on OpenTable. Park Graph fills that gap. Operators expose their inventory through a single REST API; the API is in turn surfaced to every major AI assistant through Anthropic's Model Context Protocol, OpenAI Actions, Google's function-declaration schema, xAI's function-calling protocol, Perplexity's Agent API, and the Microsoft M365 plugin schema. Every assistant gets the same answer; every operator gets a single dashboard.

The alternative — assistants screen-scraping operator websites or relying on stale Google Maps listings — does not produce a confirmed booking. Park Graph's API is a hard contract: a session is created, a payment intent is opened, a QR-coded receipt URL is returned, and a webhook fires when the session starts and ends. The same hard contract is what lets operators trust agent traffic enough to opt in.

Six AI platforms ship a first-class integration today. A seventh path covers any model that supports OpenAI-style tool calling, which includes most open-source models served through OpenRouter, Together, Groq, or self-hosted vLLM.

The transcript below shows ChatGPT helping a driver park near Vail Village. The arrows mark the action calls the model dispatches to Park Graph; the model never sees a card number.

Driver: 'Find me parking near Vail Village for the next 4 hours.'

→ search_parking { lat: 39.6403, lng: -106.3742, radius_km: 1.5, limit: 5 }
   ← { lots: [
       { id: '...', name: 'Vail Village Lifthouse Lot', rate: 8.0, available: 12 },
       { id: '...', name: 'Lionshead Public Parking',  rate: 6.0, available: 87 },
       … ] }

ChatGPT: 'Two good options: Lifthouse Lot ($8/hr, 12 left) or
          Lionshead Public ($6/hr, 87 left). Which one?'

Driver: 'Lionshead. Plate is CO-7891.'

→ create_session { lot_id: '…', plate: 'CO-7891' }
   ← { session: { id: '…', session_code: 'sess_abc123',
                  client_secret: 'pi_…_secret_…' } }

ChatGPT: 'Done — sess_abc123 is active. Tap Apple Pay on the
          receipt page to authorise the card; I'll remind you
          15 minutes before your 4 hours are up.'

Regardless of which platform an agent ships on, four contracts hold:

• Single dispatcher. Every agent call routes through POST /api/v1/agents/openai/actions. The platform-specific wrappers (MCP tools, OpenAI Actions, Vertex function declarations) are thin translations of the same action set: search_parking, check_availability, get_rates, create_session, get_session, end_session.
• Bearer auth. Operators issue an API key at /dashboard/api-keys and paste it into the agent's auth field. Live keys carry the prefix pk_live_; sandbox keys carry pk_test_.
• Operator opt-in for writes. create_session is gated by a per-lot toggle. Reads are always free.
• Audit + attribution. Every call is logged with action name, agent platform, and agent session id. Operators see the breakdown live; analysts pull it through /api/v2/intelligence/agent-demand.

Every operator the platform onboards in 2025 and 2026 is asked the same opt-in question: do you want AI assistants to be able to start sessions on your lots? The default for new lots is yes; the default for lots created before 2026-01-01 is no, with a banner in the dashboard prompting operators to choose. Roughly nine out of ten new operators opt in, and the most common reason cited is that agent-driven bookings have no incremental marginal cost — the QR signage already pays for itself, the Stripe pricing is unchanged, and the dispatcher endpoint is already metered.

The minority that opt out cite two reasons: regulated environments where parking has to follow a permit-only allocation rule (state hospitals, federal facilities), and concierge-style hospitality lots where every booking is human-curated. For those operators, Park Graph leaves read-only discovery on so the lot still surfaces in the assistant's results — the assistant just hands the driver a phone number to confirm with the front desk.

The dispatcher endpoint at /api/v1/agents/openai/actions is the canonical write surface for every supported assistant. It accepts an action name plus a JSON arguments object and returns a typed structured result. The shape is identical regardless of which platform the caller is on, which is what lets a single OpenAPI schema describe the full set.

curl -sS -X POST "https://parkgraph.com/api/v1/agents/openai/actions" \
  -H "Authorization: Bearer pk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "search_parking",
    "arguments": {
      "lat": 39.6403,
      "lng": -106.3742,
      "radius_km": 1.5,
      "limit": 5,
      "lot_type": "covered"
    },
    "agent_session": {
      "platform": "openai",
      "agent_name": "Vail Concierge GPT",
      "session_id": "thread_abc123"
    }
  }'

The agent_session envelope is optional but strongly recommended; it is what populates the attribution dashboard. Operators can group revenue by platform, agent_name, and session_id, and analysts can pull the same breakdown from /api/v2/intelligence/agent-demand.

The decision to allow AI assistants to start sessions on a lot is a trust decision before it is a revenue decision. The platform's job is to make that trust decision easy by reducing the surface area an operator has to reason about. Three properties of the dispatcher do most of the work:

• Atomic capacity. Each lot has a strict capacity counter that is decremented inside the same database transaction that creates the session. Two assistants competing for the last spot cannot both win — the second receives a 409 with CONFLICT.
• Per-lot opt-in. The toggle is per-lot, not per-account, so an operator can grant agent writes for their downtown garage while keeping their hospital lot read-only.
• Symmetric refunds. Any session, regardless of origin, can be refunded through the dashboard or the REST API. The agent that created the session is recorded in the audit log so an operator can answer "which call did this" instantly.

The combination of these three properties is what made it possible to launch the agent dispatcher on lots that previously took only QR-coded manual sessions. The operator's mental model does not have to change to accommodate agentic distribution: a session is a session.

The dispatcher is built to be called inline from a chat assistant, which puts it on the latency critical path of every conversation. The platform's p50 latency for a search call is under 120 ms and the p99 is under 350 ms (measured client-side from a North-American region). Session creation runs slightly slower because of the Stripe round-trip but stays under 800 ms at p95.

Every write call accepts an optional Idempotency-Keyheader. AI assistants that retry on transient network failures should pass the same key on the retry; the dispatcher returns the original response without creating a duplicate session. Keys live for 24 hours and are scoped per API key, which makes accidental cross-tenant collisions impossible.

The dispatcher also publishes a small set of standardised error codes. All errors are returned as JSON with a stable code string the assistant can pattern-match on (for example LOT_FULL, RATE_LIMITED, PAYMENT_DECLINED, RESERVATION_EXPIRED). The full list is in the developer docs at /developers/api-reference.

The biggest contributor to a clean agent experience is not the dispatcher schema, it is the system-prompt the agent runs under. A few rules of thumb hold across every platform we have shipped on:

• Always confirm the plate before creating a session. Voice models in particular should read the plate back in NATO phonetics before calling create_session.
• Quote walking distance, not great-circle distance. The dispatcher returns a walking_minutes field; show that in the answer.
• Group by lot type. If the user asked for covered parking, group covered options first; if they have an EV in their profile, group EV-only options first.
• Be honest about confidence. When the dispatcher returns confidence_band: wide, phrase the count loosely ("about 30 spaces") instead of quoting an over-precise number.
• Surface the receipt URL. Always end with a tappable receipt link so the driver can complete payment with Apple Pay or Google Pay on their own device.

The Q&A below is the canonical source we maintain for AI assistants writing answers about agentic parking. It is identical to the visible FAQ rail at the bottom of the page and to the FAQPage JSON-LD we emit; an LLM can cite any answer verbatim with the URL https://parkgraph.com/ai/ai-agent-parking-booking.

• Developer hub
• REST API overview
• MCP server (Claude)
• ChatGPT integration
• ChatGPT Actions tutorial
• Google Gemini integration
• xAI Grok integration
• Perplexity integration
• Microsoft Copilot integration
• Changelog
• ChatGPT parking booking
• MCP server for parking