Ground Services API: The Object Model for AV Fleet Ground Operations

An AV ground-services API should expose nine core objects: site, zone, capability, reservation, session, SLA, evidence, exception, and billing. Together they let a fleet ask one site "can my vehicle stage here tonight, what is it allowed to do, is it available, and what proof will I get?" and receive a structured, auditable answer. The API coordinates reservation, access, workflow, SLA, evidence, and audit. It does not map roads, own chargers, dispatch vehicles, or replace a fleet operator.

What an AV ground-services API has to model

The hard part of off-depot fleet operations is not the request. It is the state. A vehicle arrives at a private lot, does work that has to be tracked, and leaves behind a record someone will audit. An API that only books a slot misses everything after arrival.

Plain-English definition

A ground services API is a machine-to-machine interface between an autonomous fleet's operations stack and the private sites that give it ground capacity: places to stage, store overnight, queue near charging, hold during recovery, and run light service between trips.

It is not a parking-reservation endpoint with extra fields. A parking API answers "is there a spot." A ground-services API answers "is there a spot, is my vehicle allowed in it, what is it allowed to do there, what level of service applies, and what evidence will prove the session ran correctly." That last clause is the reason the object model is nine objects deep instead of two.

Why the object model matters

Fleets are moving ground work off the depot. Depots stay central and capacity-bound, while trips happen across the whole city. The number of distributed places a robotaxi needs between rides keeps growing, and each one is a different owner with different rules.

You cannot manage that by phone and PDF. As commercial fleets have scaled past 2,500 vehicles in the US, operators have moved ground work to dedicated partners and distributed facilities rather than a single depot. Waymo outsourced fleet operations, facilities, and charging to Moove across Phoenix and Miami and named Avis Budget Group its depot-and-readiness partner in Dallas (TechCrunch, Dec 2024; Avis Budget Group, Jul 2025). A fleet integrating ten sites can hand-wave the state. A fleet integrating hundreds cannot. The object model exists so that adding the 300th node is the same API call as the 3rd, and so that every session it produces is auditable the same way.

The permission/capability split is what makes this more than logistics software. HD mapping tells an AV where it may be able to drive. The site owner defines permission: where the vehicle is allowed to go and what it may do. The fleet validates capability: whether its own vehicle can perform the action safely. The API sits between them, coordinating reservation, access, workflow, SLA, evidence, and audit. The property defines permission. The fleet validates capability. XoomPark coordinates the record.

How the objects connect

The objects form a chain, each referencing the one before it. A site contains one or more zones. Each zone advertises capabilities. A reservation claims a capability in a zone for a window. When the vehicle arrives, the reservation opens into a session. The session is measured against an sla, accumulates evidence, and may spawn an exception. When it closes, it produces a billing record pointing back at the session and its evidence.

That referential chain is the audit trail. Given a billing line, you can walk back to the exact session, the evidence captured during it, the SLA it was held to, and the reservation that authorized it. No object floats free.

Illustrative request/response sketch

The snippets below are example schemas for documentation only. They are not live endpoints, and field names, paths, and values are illustrative.

POST /v1/reservations
Content-Type: application/json

{
  "site_id": "site_8f2",
  "zone_id": "zone_overnight_A",
  "capability": "overnight_storage",
  "vehicle_ref": "fleetX_av_0427",
  "window": { "start": "2026-06-26T23:00:00Z", "end": "2026-06-27T05:30:00Z" },
  "requested_sla": "standard_overnight"
}

{
  "reservation_id": "rsv_31a9",
  "status": "confirmed",
  "site_id": "site_8f2",
  "zone_id": "zone_overnight_A",
  "capability": "overnight_storage",
  "access": {
    "method": "gate_code",
    "rules": ["no_charging_in_zone", "quiet_hours_22_06"]
  },
  "sla": {
    "id": "standard_overnight",
    "check_in_grace_min": 15,
    "evidence_required": ["arrival_photo", "departure_photo", "timestamps"]
  },
  "billing_estimate": { "currency": "USD", "amount": "18.00", "_note": "illustrative example value only" }
}

Who needs this

XoomPark is not a fleet operator, not a charging network, not an autonomy or HD-mapping company. The API is the coordination layer those roles meet on, not a replacement for any of them.

Example workflow: an overnight storage session, object by object

What XoomPark does and does not do

Original analysis: the nine-object decomposition and where integrations break

We mapped the AV ground-session lifecycle against the data a fleet has to retain for audit, and reduced it to the smallest object set that still produces a defensible record. The result is the nine objects above. The test we applied: remove any one object, and either a real operational state becomes unrepresentable or an audit question becomes unanswerable. All nine survived that test. A tenth (a generic "note") did not, because anything worth retaining belonged on session, exception, or evidence.

The decomposition also exposes where naive integrations break. Most teams model reservation and session and stop. They treat evidence as optional metadata and bolt billing on at the end. That works until the first dispute, at which point there is no timestamped proof to point at, and reconciliation collapses into email. Evidence is not a nice-to-have field. It is the object that makes the SLA enforceable and the billing line defensible, which is why it gets equal weight in the model rather than living as a loose attachment.

One framework note worth stating plainly: in this model capability is decoupled from site. A site does not "have services" as fixed attributes. Each zone advertises capabilities independently, because the same lot can offer overnight storage in one corner and recovery holding in another under different rules. This zone-level variation is a modeling assumption behind the object design rather than a measured frequency; XoomPark scopes capability to the zone precisely so that a single site with mixed rules can be represented correctly. Integrations that flatten capability onto the site cannot express that, and end up booking services into zones that cannot deliver them.

Not for you

If you run a single fixed depot, never operate off-site, and own every square foot your vehicles touch, you do not need a distributed ground-services API yet. Your "object model" is one site you already control, and a reservation system would add coordination overhead with nothing to coordinate. This API earns its complexity when you operate across multiple private sites you do not own, where access rules, service levels, and evidence have to travel with each session. Come back when the depot stops being enough.

Frequently asked questions

Related pages

Talk to XoomPark about API integration

If you are building the fleet-ops stack for an autonomous fleet and need to coordinate ground capacity across private sites, talk to XoomPark about API integration. We will walk your team through the object model and how it maps to your dispatch and audit requirements.