v0.16.0 Companion to APDS 4.1 OpenAPI 3.1 MIT

APX — APDS Parking eXtensions

An open companion standard to the APDS 4.1 API. APX adds what APDS deliberately leaves out — real-time delivery, operational control, alerting, discovery, and the business domains built on them — without redefining a single APDS entity.

Explore the API

Try the simulator →
The whole standard running in your browser: twenty-four narrated demos (operations, analytics, plate lists), the full vetting suite, a live view of event delivery and retries, and any request as any credential. Nothing leaves the page.
API reference →
Every endpoint, parameter, and schema, searchable, with request and response shapes beside the prose that governs them.
PARCS starter profile →
The minimum surface for a PARCS vendor: data, events, and control only. Byte-identical to the full spec, just smaller.
The written standard →
Every part in one document: scope and the APDS-first prime directive, conformance classes, security, errors, and each domain. Compiled from the parts on every build.
Specification documents →
APX in the form of the APDS 4.1 document set: Overview, Information Model with class diagrams, Data Dictionary, Use Cases, Interface Specification, and the requests APX makes of APDS. Read online or download as PDF.
Worked scenarios →
End-to-end stories with real wire payloads, every one machine-validated against the bundle so the samples cannot drift — plus the 379-scenario vetting suite, by module.
Requested APDS changes →
What APX asks of APDS 4.1: fourteen filed corrections, ten optional additions, and the order that helps implementers most.

The modules

Every domain APX defines, grouped the way the reference groups them. Each links to its section of the API reference and to the part of the written standard that governs it. Generated from the specification on every build, so this list is never out of date.

Start here

Where every integration starts. A partner needs exactly one thing to begin: a hostname.

API reference · Part 16

Platform

Reading and writing parking data, and staying in sync.

API reference · Part 5

Push instead of poll. A superset-compatible profile of the APDS 4.1 /webhooks endpoint: stock APDS subscription bodies work here unmodified.

API reference · Part 8

Doing things in the real world. APDS inventories devices and marks access-controlled places but defines no actuation. This is it.

API reference · Part 6

Knowing something is wrong. A net-new domain: APDS has no alert, event, or notification class.

API reference · Part 7

A location, described by APX alone. Before a call, an agent or a system should be able to learn what a site has without data from any other system: which hardware is on each lane and what each piece does, what it is, what runs on it, where the cameras are and what they see, how a parker reaches help from each lane or door, and who to escalate to.

API reference · Part 26

The vendor's own screen, without breaking the record. Most actions in a call centre still happen in a vendor's portal in another window, and the two systems never agree afterwards. A vendor will take years to implement every APX module, but it already has good screens.

API reference · Part 25

Commerce

Money. Account and balance lookup, taking a payment, refunds, voids and captures, accounting write-back, and payment history.

API reference · Part 13

Booking ahead, expressed as conventions over native APDS routes rather than a parallel booking system.

API reference · Part 14

Pooled permits: issuing from a finite allocation, over the APDS right-specification and right-pool model.

API reference · Part 14

The merchant side, from enrolment to invoice.

API reference · Part 20

Toll transactions, a net-new domain: APDS has no toll entity.

API reference · Part 15

Vehicles and access

LPR

Plates. A camera read is an APDS Observation, so ingest is the standard data route every integration already uses. No bespoke ingestion API.

API reference · Part 13

The card, the fob, the tag, the phone. The lifecycle of anything presented at a lane: issue, activate, suspend, resume, report lost, revoke, replace, plus access-event history.

API reference · Part 21

Custody. A net-new domain: APDS has no valet entity, only a restriction flag.

API reference · Part 22

Enforcement and service

Enforcement, from camera to citation to appeal. A net-new domain, and the one with the most legal exposure.

API reference · Part 19

When a customer presses the intercom. The agent, human or AI, should not have to log into another system, find the facility, find the lane, find the transaction, and reconstruct what happened.

API reference · Part 17

What happened on the last call. Support-interaction history for a resolution context: who spoke to the customer, through which channel, about what, and what was done.

API reference · Part 17

Download the spec

apx-v1.yamlFull standard · OpenAPI 3.1 · YAML apx-v1.jsonFull standard · OpenAPI 3.1 · JSON apx-parcs.jsonPARCS starter profile · JSON registries/Code-list registries · Part 11 apx-standard.mdThe written standard · one document specification/The six specification documents · HTML and PDF edition.jsonWhat this edition pins, by checksum

These are the bundled, normative artifacts, regenerated from source on every push to main. Import one into Postman, Insomnia, or your own code generator.

Run it locally

git clone https://github.com/rneubauer/apx.git
cd apx && npm install

npm test             # the full gate: vendor, registries, lint, bundle, examples, scenarios
npm run mock         # Prism mock server on :4010, generated from the spec
npm run docs:build   # rebuild this site into site/

The mock server answers every documented route with schema-valid responses, so a client integration can be written and tested before any real implementation exists. Send any bearer token.

What's in it