Connect to a customer’s ROME deployment with a facility-issued key. Start with a read-only request.
Ask the facility’s IT administrator for the HTTPS base URL and a service-account API key. Each integration should have its own key, owner, and explicitly restricted locations.
Keys begin with rome_sk_ and are sent using Authorization: Bearer. The raw key is returned only at creation. Store it in a secret manager or server environment; never embed it in a public website or client bundle.
Set ROME_API_KEY securely in your environment, replace the example host, and run this PowerShell request:
$romeBase = 'https://rome.example/api'
$romeHeaders = @{ Authorization = "Bearer $env:ROME_API_KEY" }
Invoke-RestMethod -Uri "$romeBase/v1/facilities" -Headers $romeHeadersThe response contains facilities with id, name, site, and timezone. These IDs identify dock locations, not plants.
| Scope | Allows |
|---|---|
| appointments:read | Read appointment lists and available slots. |
| appointments:write | Create and cancel appointments. |
| history:read | Read completed runs. |
| orders:read | Read expected orders and shipments. |
| orders:write | Prepare or update expected work. Shipment creation also needs appointments:write. |
Facility discovery accepts any live key within its location restrictions. Keys do not expire automatically; IT should manage rotation and revoke unused keys.
Request GET /api/v1/slots?facilityId=…&date=YYYY-MM-DD. The date is local to the dock’s IANA timezone. Return the chosen slot’s startAt exactly as supplied when creating the appointment.
Availability can change before you book. Handle conflicts, retain the returned appointment ID, and reconcile after a lost response before attempting another write.
View the booking request →null means unknown, not zero.facilityId and appointment-list locationId refer to a dock/location ID.The deployed schema is available at GET /api/v1/openapi.json. Its examples describe shapes, not every possible response field.