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:

• Read-only dispatcher. Lightweight discovery calls route through POST /api/agents/openai/actions, which bundles three read actions — search_parking, check_availability, get_rates — and is gated to Pro and Enterprise plans. Booking (create, look up, and end a session) runs against the v1 REST API; the MCP server wraps the same REST endpoints as search_parking, create_parking_session, check_session_status, and end_parking_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_.
• Plan-gated access. AI agent integrations require a Pro or Enterprise plan, enforced server-side via canAccessFeature(plan, "ai_agent_bookings"). There is no per-lot opt-in toggle.
• Audit + attribution. Every call is logged with its query type and agent platform. Operators see the breakdown live; analysts pull aggregate demand through /api/v2/intelligence/agent-demand.

Agent bookings are gated by plan, not by a per-lot switch: an operator turns on AI-driven session creation by being on a Pro or Enterprise plan (enforced via canAccessFeature(plan, "ai_agent_bookings")). The most common reason operators upgrade 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.

Operators who do not want agents creating sessions simply stay on a plan without the feature. Two environments commonly do this: regulated parking that has to follow a permit-only allocation rule (state hospitals, federal facilities), and concierge-style hospitality lots where every booking is human-curated. Those lots still surface in an assistant's results from public discovery data — the assistant just hands the driver a phone number to confirm with the front desk.

The dispatcher endpoint at /api/agents/openai/actions is the canonical read-only discovery surface for every supported assistant. It accepts one of three action names — search_parking, check_availability, get_rates — plus a JSON parameters object and returns a typed structured result, and access is gated to Pro and Enterprise plans. Booking writes are not made through the dispatcher; they run against the v1 REST API.

curl -sS -X POST "https://parkgraph.com/api/agents/openai/actions" \
  -H "Authorization: Bearer pk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "search_parking",
    "parameters": {
      "lat": 39.6403,
      "lng": -106.3742,
      "radius_km": 1.5,
      "limit": 5
    }
  }'

The dispatcher request body is just an action and a parameters object. Attribution is captured server-side: each query is tagged with the calling platform (for example openai) and a human-readable agent name, which is what populates the demand dashboard. Analysts can pull the aggregate 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.
• Plan-gated access. Agent integrations require a Pro or Enterprise plan (canAccessFeature(plan, "ai_agent_bookings")), so an operator turns on agent traffic by upgrading rather than flipping a per-lot toggle.
• 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.

The reservation endpoint (POST /api/v1/reserve) requires an Idempotency-Key header (8–200 characters). AI assistants that retry on transient network failures should pass the same key on the retry; Park Graph returns the original hold instead of creating a duplicate. The read-only dispatcher creates no sessions, so its calls are naturally safe to retry.

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 distance, not just a lot name. The dispatcher returns a distance_km field for each lot; show it in the answer so the driver knows how far the option is.
• 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 precision. When a lot's available_spaces count is low or its occupancy_pct is high, 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