Community API

The status codes configured for your community — the lookup table behind status_code on /active-units. This is configuration, not live data: it changes only when an admin edits it, so fetch it once at startup and cache it.

Order: by sort_order, then code. This is the order the CAD itself displays them in, so you can render a status picker straight from this response.

Example

curl https://api.lux-cad.com/api/v1/unit-statuses \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  { "code": "10-8",  "label": "Available",   "color": "#22c55e", "sort_order": 0, "roles": [],       "is_base": true },
  { "code": "10-7",  "label": "Unavailable", "color": "#ef4444", "sort_order": 1, "roles": [],       "is_base": true },
  { "code": "10-6",  "label": "Busy",        "color": "#f97316", "sort_order": 2, "roles": [],       "is_base": true },
  { "code": "10-18", "label": "En Route",    "color": "#1e40af", "sort_order": 3, "roles": [],       "is_base": true },
  { "code": "10-97", "label": "On Scene",    "color": "#581eae", "sort_order": 4, "roles": [],       "is_base": true },
  { "code": "10-23", "label": "Air Support", "color": "#0ea5e9", "sort_order": 5, "roles": ["LEO"], "is_base": false }
]

Every unit currently on duty in your community, with its live status already resolved to a label and colour. This is the endpoint most integrations start with.

Order: unspecified — sort on your side if it matters.

Example

curl https://api.lux-cad.com/api/v1/active-units \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "callsign": "1-ADAM-12",
    "department": "LEO",
    "agency": "LSPD",
    "special_unit_code": null,
    "status_code": "10-97",
    "status_label": "On Scene",
    "status_color": "#581eae",
    "current_incident_id": "6b1f0e2a-9c74-4a51-b0d8-2f3c8e5a1d90",
    "since": "2026-07-20T09:14:02.317849+00:00"
  },
  {
    "callsign": "DISPATCH 110",
    "department": "DISPATCH",
    "agency": null,
    "special_unit_code": null,
    "status_code": "10-8",
    "status_label": "Available",
    "status_color": "#22c55e",
    "current_incident_id": null,
    "since": "2026-07-20T08:52:41.008204+00:00"
  }
]

Every individual person currently on duty, with their Discord ID and the unit they are staffing. Where /active-units lists the units, this lists the people in them — one row per on-duty member. A unit crewed by more than one person appears as multiple rows sharing the same unit_callsign.

Order: by department, then unit_callsign, then member_name.

Example

curl https://api.lux-cad.com/api/v1/active-unit-members \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "discord_id": "285181941777694720",
    "member_name": "J. Rivera",
    "unit_callsign": "1-ADAM-12",
    "department": "LEO",
    "agency": "LSPD",
    "special_unit_code": null,
    "status_code": "10-97",
    "status_label": "On Scene",
    "status_color": "#581eae",
    "current_incident_id": "6b1f0e2a-9c74-4a51-b0d8-2f3c8e5a1d90",
    "joined_at": "2026-07-20T09:14:02.317849+00:00"
  },
  {
    "discord_id": "399949667997319168",
    "member_name": "K. Osei",
    "unit_callsign": "1-ADAM-12",
    "department": "LEO",
    "agency": "LSPD",
    "special_unit_code": null,
    "status_code": "10-97",
    "status_label": "On Scene",
    "status_color": "#581eae",
    "current_incident_id": "6b1f0e2a-9c74-4a51-b0d8-2f3c8e5a1d90",
    "joined_at": "2026-07-20T09:15:40.113220+00:00"
  }
]

Pursuits that are currently running. Finished pursuits are not returned — this is a live snapshot, not a history endpoint.

Order: oldest first, by started_at.

Example

curl https://api.lux-cad.com/api/v1/pursuits \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "pursuit_id": "c4e8a1d7-3b52-49f6-8e10-7a9d2c4b6f31",
    "incident_id": "6b1f0e2a-9c74-4a51-b0d8-2f3c8e5a1d90",
    "status": "ACTIVE",
    "primary_callsign": "1-ADAM-12",
    "backup_callsigns": ["1-ADAM-14", "AIR-1"],
    "paused": false,
    "started_at": "2026-07-20T10:31:18.442071+00:00",
    "active_seconds": 437
  }
]

When nothing is running:

[]

Every incident type configured for your community. This is the list your POST /incidents calls pick a short code from — read it once at startup rather than hard-coding codes, because your admins can add, rename and remove types at any time.

Order: by sort_order, then code.

STANDARD is the special case in the other direction: it means "not typed yet" and is always accepted, even if it isn't in this list. It is what every in-game call arrives as, and a dispatcher types it properly afterwards.

Example

curl https://api.lux-cad.com/api/v1/incident-types \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "code": "STANDARD",
    "label": "Standard",
    "is_system": false,
    "default_departments": [],
    "default_sub_departments": [],
    "default_priority": null,
    "sort_order": 10
  },
  {
    "code": "TRAFFIC_STOP",
    "label": "Traffic Stop",
    "is_system": true,
    "default_departments": [],
    "default_sub_departments": [],
    "default_priority": null,
    "sort_order": 30
  },
  {
    "code": "VEHICLE_COLLISION",
    "label": "Vehicle Collision - No Injury",
    "is_system": false,
    "default_departments": ["LEO"],
    "default_sub_departments": [],
    "default_priority": 3,
    "sort_order": 840
  }
]

Every incident in your community that is not closed — both PENDING (waiting for a unit) and ACTIVE (being worked). This is the live call queue, the same set a dispatcher sees.

Closed incidents are never in here. To read one, fetch it by id with /incidents.

Order: newest first, by created_at.

Takes no parameters. The field shape is identical to /incidents — see the table there.

Example

curl https://api.lux-cad.com/api/v1/incidents-open \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "incident_id": "c4db0b05-d36a-4e7e-a03d-bfc85545921a",
    "call_number": "#911-7287",
    "incident_type": "ALARM_FIRE",
    "incident_type_label": "Fire Alarm",
    "title": "Fire Alarm",
    "description": "LTD on fire",
    "priority": 2,
    "status": "PENDING",
    "departments": ["SAFR"],
    "sub_departments": ["FIRE"],
    "location_text": "Postal 101",
    "address": "Amador Road",
    "created_at": "2026-08-10T01:22:34.673520+00:00",
    "updated_at": "2026-08-10T01:22:34.673520+00:00"
  }
]

One incident by id, in any state — including closed. Use this to follow an incident you created, or to look up a call number a player mentioned.

Returns an array with one incident, or an empty array. An incident belonging to another community is indistinguishable from one that does not exist.

Example

curl "https://api.lux-cad.com/api/v1/incidents?incident_id=c4db0b05-d36a-4e7e-a03d-bfc85545921a" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "incident_id": "c4db0b05-d36a-4e7e-a03d-bfc85545921a",
    "call_number": "#911-7287",
    "incident_type": "ALARM_FIRE",
    "incident_type_label": "Fire Alarm",
    "title": "Fire Alarm",
    "description": "LTD on fire",
    "priority": 2,
    "status": "PENDING",
    "departments": ["SAFR"],
    "sub_departments": ["FIRE"],
    "location_text": "Postal 101",
    "address": "Amador Road",
    "created_at": "2026-08-10T01:22:34.673520+00:00",
    "updated_at": "2026-08-10T01:22:34.673520+00:00"
  }
]

Create an incident, pre-specified on an incident type. It lands in the dispatch queue immediately and appears on every dispatcher's console in your community, exactly like a call raised in the CAD.

Read Writing first — especially the part about 502.

Body: JSON object. Unknown fields are rejected.

Priority and departments are not yours to set. They follow the incident type as your server owner configured it — that is the whole point of pre-specifying on a short code. If a type has no departments configured, the incident is created with none, and it will not show up in a department-filtered view until a dispatcher types it. Check /incident-types if a call seems to vanish. The response always tells you what was actually applied.

Send coordinates; we work out the rest. With x and y we look up the nearest postal in your community's postal list (including a custom one your admins uploaded) and the nearest street, and fill location_text and address for you. Anything you send yourself always wins. Without coordinates and without a postal, the incident is created with Location unknown — it will still reach dispatch, but there is no map pin and no automatic arrival detection.

The call number. You get #<PREFIX>-<six digits>; the # is part of the value, don't add your own. Pick a call_prefix that identifies your integration. The prefixes the CAD issues itself — 911, 311, TS, TIP, PUR, 10 — are reserved and rejected, so a script cannot pass itself off as a 911 call. Note that call numbers are not unique: keep the returned incident_id, that is the handle.

Rate limit: 10 per minute, separate from and stricter than the general limit. Creating an incident notifies every connected client in your community, so this one is deliberately tight.

There is no PATCH or DELETE. Once a call is in the queue it belongs to dispatch; closing it is a dispatcher's decision, made in the CAD.

Returns 201 with the created incident, in the same shape as a GET /incidents row.

Example

curl -X POST https://api.lux-cad.com/api/v1/incidents \
  -H "x-lux-api-key: $LUX_API_KEY" \
  -H "content-type: application/json" \
  -d '{
        "incident_type": "ROBBERY_ARMED",
        "title": "Armed robbery in progress",
        "description": "Two masked suspects fled on foot.",
        "x": 1230.5,
        "y": -1720.75,
        "reporting_party_name": "Marcus Webb",
        "callback_number": "555-0142",
        "weapons_involved": "Handgun",
        "call_prefix": "BOT"
      }'

{
  "incident_id": "21446722-6f14-41a0-b6eb-1a20b5c26ea7",
  "call_number": "#BOT-001272",
  "incident_type": "ROBBERY_ARMED",
  "incident_type_label": "Robbery - Armed",
  "title": "Armed robbery in progress",
  "description": "Two masked suspects fled on foot.",
  "priority": 1,
  "status": "PENDING",
  "departments": ["LEO"],
  "sub_departments": [],
  "location_text": "Postal 181",
  "address": "Innocence Blvd",
  "created_at": "2026-08-11T16:41:06.130645+00:00",
  "updated_at": "2026-08-11T16:41:06.130645+00:00"
}

Note that priority, departments and location_text in that response were all filled in for you — the first two from the incident type, the last from the coordinates.

Add a line to an incident's operational log — the running timeline dispatchers and units read on the call. Useful for reporting back what your own script did: a tow dispatched, a gate opened, a scene cleared.

Send exactly one of author or system. Sending both, or neither, is a 400.

Returns 201 and the created line: log_id, incident_id, content, is_system, created_at.

There is no GET, PATCH or DELETE here. The log is an append-only timeline; the CAD has no way to edit a line either.

Example

curl -X POST "https://api.lux-cad.com/api/v1/incident-logs"   -H "x-lux-api-key: $LUX_API_KEY"   -H "Content-Type: application/json"   -d '{
    "incident_id": "3f8c1a90-27d4-4b6e-9c15-8a0e4d7b2f31",
    "content": "Vehicle recovered and released to owner",
    "system": true
  }'

{
  "log_id": "9e4b2c71-5a83-4f02-b6d9-1c7e83a5f204",
  "incident_id": "3f8c1a90-27d4-4b6e-9c15-8a0e4d7b2f31",
  "content": "[SYSTEM] Vehicle recovered and released to owner",
  "is_system": true,
  "created_at": "2026-08-20T14:52:07.118342+00:00"
}

Every report type configured for your community, with the two rules that decide what a POST /reports may contain.

Read this once at startup rather than hard-coding codes. The list is not fixed: your server owner can turn a type off, which takes it out of this response, and we add types to the CAD over time.

A type that is turned off is not listed here. That is deliberate — this endpoint answers "what can I use", and a type you cannot file would only be a 400 waiting to happen. Two consequences worth knowing:

• POST /reports with a turned-off type is a 400, with a message that says so rather than "unknown type". The type still exists; it is just closed for new reports.
• GET /reports is unaffected. Reports already filed under that type keep coming back, with their type_label intact. Turning a type off closes the door; it does not rewrite history.

Order: by sort_order, then code.

departments and read_departments are informational, and they always will be: your key authenticates a community, not a department, so there is no LEO or SAFR on your side of the line for us to check against. They are published because a community building its own panel needs to know who is supposed to see what — and because publishing who may write, but not who may read, would be half an answer.

supports_charges is derived, not stored: it is true when the type applies a fine, a jail sentence, or both. A warning is the usual example of false — it goes on someone's record without costing them anything.

Which types carry a court date is decided here too, and is not currently in this response. Today ARREST, NTA and CITATION carry one; WARNING and INVESTIGATION do not. Sending court_date for a type that does not carry one is a 400, the same way charges is. We have deliberately not published the underlying per-type field list yet: it would be a contract we cannot take back, and there is no way to send arbitrary custom fields, so it would describe something you cannot use. If you need to know whether a type takes a court date, treat the three codes above as the answer and tell us if your community configured something else.

Example

curl https://api.lux-cad.com/api/v1/report-types \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "code": "ARREST",
    "label": "Arrest",
    "is_system": true,
    "sort_order": 10,
    "supports_charges": true,
    "requires_subject": true,
    "departments": ["LEO", "DISPATCH"],
    "read_departments": ["LEO", "DISPATCH"]
  },
  {
    "code": "NTA",
    "label": "NTA",
    "is_system": true,
    "sort_order": 20,
    "supports_charges": true,
    "requires_subject": true,
    "departments": ["LEO", "DISPATCH"],
    "read_departments": ["LEO", "DISPATCH"]
  },
  {
    "code": "CITATION",
    "label": "Citation",
    "is_system": true,
    "sort_order": 30,
    "supports_charges": true,
    "requires_subject": true,
    "departments": ["LEO", "DISPATCH"],
    "read_departments": ["LEO", "DISPATCH"]
  },
  {
    "code": "WARNING",
    "label": "Warning",
    "is_system": true,
    "sort_order": 40,
    "supports_charges": false,
    "requires_subject": true,
    "departments": ["LEO", "DISPATCH"],
    "read_departments": ["LEO", "DISPATCH"]
  },
  {
    "code": "INVESTIGATION",
    "label": "Investigation",
    "is_system": true,
    "sort_order": 50,
    "supports_charges": false,
    "requires_subject": false,
    "departments": ["LEO", "DISPATCH", "SAFR"],
    "read_departments": ["LEO", "DISPATCH", "SAFR"]
  }
]

Published reports — one by id, or every report a character or Discord user appears in, with charges and totals worked out.

Send exactly one of report_id, character_id or discord_id. since_number and limit are optional and combine with any of them.

Order: by report_number, ascending. Always — this is also what makes the cursor work.

Only PUBLISHED reports are returned. Drafts are an officer's unfinished work and stay out of every read path, this one included.

Each entry in charges:

Charges are ordered by penal_code.

Verdicts are set per charge but usually as a whole. A court rules on a case, so both the citizen portal and PATCH /reports set one verdict across every charge at once; only an officer in the CAD can differ per charge. Expect them to agree, and handle the case where they don't.

Jail time is always expressed in days. How long a day is in your roleplay is your community's own convention — we store and return the number your penal code carries, and never convert it.

court_date is a stored date, not a calculation. It is a calendar day with no time of day, written when the report is filed and never recomputed afterwards — so a report you read today and read again next year gives the same answer. It defaults to two weeks after the report was filed, worked out in your community's own timezone, and an officer can change it before the report is published.

null genuinely means "no court date": either the type does not carry one (WARNING, INVESTIGATION), or it was cleared on purpose. Do not substitute a date of your own for it.

Example

curl "https://api.lux-cad.com/api/v1/reports?character_id=b7d6bc59-8126-465f-9e67-8e1a353392ca&limit=1" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "report_id": "02786fe2-7276-43cf-8b94-37db4421a5a6",
    "report_number": 97,
    "type": "ARREST",
    "type_label": "Arrest",
    "status": "PUBLISHED",
    "title": "Armed robbery — Vespucci Beach",
    "narrative": "[LSPD 402 — 2026-03-14 21:05]\nSuspect was arrested after a foot pursuit and booked at Mission Row.",
    "issuing_officer": "LSPD 402",
    "location_text": "Postal 181",
    "address": "Innocence Blvd",
    "court_date": "2026-03-28",
    "character_id": "b7d6bc59-8126-465f-9e67-8e1a353392ca",
    "suspect_ids": ["b7d6bc59-8126-465f-9e67-8e1a353392ca"],
    "incident_ids": [],
    "total_fine": 3000,
    "total_jail_days": 480,
    "charges": [
      {
        "penal_code": "HS.1.01",
        "title": "Possession of a Controlled Substance",
        "classification": "MISDEMEANOR",
        "charge_count": 2,
        "fine": 500,
        "jail_days": 60,
        "fine_total": 1000,
        "jail_days_total": 120,
        "verdict": "CONVICTED",
        "verdict_label": "Convicted",
        "verdict_at": "2026-03-28T19:12:44+00:00"
      },
      {
        "penal_code": "HS.1.02",
        "title": "Possession with Intent to Distribute",
        "classification": "FELONY",
        "charge_count": 1,
        "fine": 2000,
        "jail_days": 360,
        "fine_total": 2000,
        "jail_days_total": 360,
        "verdict": null,
        "verdict_label": null,
        "verdict_at": null
      }
    ],
    "created_at": "2026-03-14T21:05:00+00:00",
    "updated_at": "2026-03-14T21:05:00+00:00"
  }
]

Walking a character's whole record, 200 at a time:

GET /reports?character_id=<id>&limit=200
GET /reports?character_id=<id>&limit=200&since_number=<highest report_number you saw>

File a report on a character — including a back-dated one, which is how you give a character a history that was never played out.

Read Writing first — especially the part about 502.

Body: JSON object. Unknown fields are rejected.

A type your server owner has turned off is a 400. The message says the type is turned off, not that it is unknown — it still exists and its existing reports still come back from GET /reports; it is closed for new ones. This is the same class as requires_subject and supports_charges: your server owner's configuration, not a change to this API. It is also the reason to read /report-types at startup instead of hard-coding a list of codes.

The report is created as PUBLISHED. There is no draft state on this endpoint: a draft is an officer's unfinished work, visible only to its author, and a report filed by a script has no author to come back to it.

You do not set the fine or the jail time. Send penal_code and, if it applies, charge_count; the amounts come from your community's own penal code, exactly as they would if an officer had picked the charge in the CAD. This is the same rule as priority on POST /incidents: the server owner's configuration wins, and your integration keeps working when they retune it.

The same code twice is one charge with a higher count. [{"penal_code":"X"},{"penal_code":"X"}] becomes one entry with charge_count: 2, not two entries — that is how counts work throughout the CAD.

Leave court_date out and you get the right one. For a type that carries a court date (ARREST, NTA, CITATION) the default is two weeks after the report was filed, worked out in your community's timezone — the same date an officer would have got in the CAD. On a back-dated report it counts from created_at, not from today, so importing a year of history gives each report the court date it would have had at the time.

Send it explicitly only when you know better. It must be a plain calendar date, YYYY-MM-DD: a timestamp is rejected, because a court date is a day and the paper prints no time. 2026-02-30 is rejected too. Sending it for a WARNING or an INVESTIGATION is a 400 — which types carry one is your server owner's configuration, the same as charges.

issuing_officer is free text on purpose. The report is not attributed to a CAD user account, so it will not turn up in any officer's "My Reports". Write the callsign or name you want printed on the paper.

Rate limit: 10 per minute, shared with PATCH /reports and separate from the general limit. Both notify every connected client in your community, so this one is deliberately tight.

Returns 201 with the created report, in the same shape as a GET /reports row.

Example

curl -X POST https://api.lux-cad.com/api/v1/reports \
  -H "x-lux-api-key: $LUX_API_KEY" \
  -H "content-type: application/json" \
  -d '{
        "type": "ARREST",
        "character_id": "b7d6bc59-8126-465f-9e67-8e1a353392ca",
        "title": "Armed robbery — Vespucci Beach",
        "narrative": "Suspect was arrested after a foot pursuit and booked at Mission Row.",
        "issuing_officer": "LSPD 402",
        "location_text": "Postal 181",
        "address": "Innocence Blvd",
        "created_at": "2026-03-14T21:05:00+00:00",
        "charges": [
          { "penal_code": "HS.1.01", "charge_count": 2 },
          { "penal_code": "HS.1.02" }
        ]
      }'

{
  "report_id": "02786fe2-7276-43cf-8b94-37db4421a5a6",
  "report_number": 97,
  "type": "ARREST",
  "type_label": "Arrest",
  "status": "PUBLISHED",
  "title": "Armed robbery — Vespucci Beach",
  "narrative": "[LSPD 402 — 2026-03-14 21:05]\nSuspect was arrested after a foot pursuit and booked at Mission Row.",
  "issuing_officer": "LSPD 402",
  "location_text": "Postal 181",
  "address": "Innocence Blvd",
  "court_date": "2026-03-28",
  "character_id": "b7d6bc59-8126-465f-9e67-8e1a353392ca",
  "suspect_ids": ["b7d6bc59-8126-465f-9e67-8e1a353392ca"],
  "incident_ids": [],
  "total_fine": 3000,
  "total_jail_days": 480,
  "charges": [
    {
      "penal_code": "HS.1.01",
      "title": "Possession of a Controlled Substance",
      "classification": "MISDEMEANOR",
      "charge_count": 2,
      "fine": 500,
      "jail_days": 60,
      "fine_total": 1000,
      "jail_days_total": 120
    },
    {
      "penal_code": "HS.1.02",
      "title": "Possession with Intent to Distribute",
      "classification": "FELONY",
      "charge_count": 1,
      "fine": 2000,
      "jail_days": 360,
      "fine_total": 2000,
      "jail_days_total": 360
    }
  ],
  "created_at": "2026-03-14T21:05:00+00:00",
  "updated_at": "2026-03-14T21:05:00+00:00"
}

Note that total_fine and total_jail_days were worked out for you from the community's penal code — 2 × 500 + 2000, and 2 × 60 + 360.

Update a report you filed earlier. Fields you leave out are untouched.

Body: JSON object. Unknown fields are rejected.

narrative edits your own contribution, not the whole document. A report can hold contributions from several officers, each headed by [author — timestamp] in the narrative you read back. This endpoint writes and rewrites exactly one of them — the one it added itself — and never touches anyone else's text. Sending "" removes yours and leaves the rest standing. The first time you patch the narrative of a report written entirely in the CAD, that officer's existing text is preserved as a contribution of its own before yours is appended.

Charges cannot be patched. Set them when you create the report. If they are wrong, the practical route today is to file a corrected report.

Any report of your community can be patched, in any state — including one an officer wrote, and including a draft. That is the same reach a signed-in staff member has. Note that this leaves no audit trail: nothing in the CAD records that the change came from an integration rather than from a person.

Changing type leaves existing charges alone, even if the new type has supports_charges: false. They stay on the record but stop being shown in the CAD. A stored court_date survives a type change the same way — it stops being printed, but it is not thrown away as a side effect of an unrelated edit.

court_date: "" really removes it, and that is the point of the field being editable: a court date that was set in error has to be removable, and nothing puts it back. There is no recalculation to fall back on — clear it and GET /reports returns null until someone sets a new one. Rescheduling a hearing is a normal PATCH with the new date; this is a stored value, so the new one sticks.

verdict sets the outcome of the case. It applies to every charge on the report at once, which is the shape a court result actually has: the bench rules on the case, not on line 3 of the charge sheet. Read it back per charge in charges[].verdict.

Which verdicts exist is set by the server owner. Four are always present — PENDING, CONVICTED, ACQUITTED, DISMISSED — and a community can add its own (NOLLE PROSEQUI, APPEAL PENDING, and so on). An unknown code is a 400 naming the code you sent. A report with no charges is a 400 as well: there is nothing to rule on, and returning 200 would tell you a verdict was stored when none was.

Verdicts are append-only, so there is no "" to clear one. Every verdict is kept, along with who set it and in what capacity — an officer, a citizen on their own record, or an integration like yours. Correcting a verdict means sending the new one; both moments stay on the record. To reopen a case, send PENDING.

Rate limit: 10 per minute, shared with POST /reports.

Returns 200 with the report as it now stands, in the same shape as a GET /reports row.

Example

curl -X PATCH "https://api.lux-cad.com/api/v1/reports?report_id=02786fe2-7276-43cf-8b94-37db4421a5a6" \
  -H "x-lux-api-key: $LUX_API_KEY" \
  -H "content-type: application/json" \
  -d '{ "title": "Armed robbery — Vespucci Beach (amended)" }'

Every hearing scheduled in your community between two dates. This is the docket: one row per report that carries a court date, oldest hearing first.

Where /reports answers "what is on this person's record", this answers "who is due in court this week". Use it to build a schedule, to post a reminder in Discord, or to find the no-shows.

Order: by court_date ascending, then report_number.

from is required on purpose: without a lower bound this is a sweep of your community's entire archive, and that is not what this endpoint is for. A day range is the intended shape — from and to equal for a single day.

Only PUBLISHED reports appear here, same as everywhere else in this API.

Which report types carry a court date is your community's configuration, not a fixed list. Arrest reports, notices to appear and citations do by default, but a server owner can add a type of their own that carries one, and it will show up here without any change on your side. Do not filter on type yourself to decide what counts as a hearing — carrying a court_date is what counts.

open_charges tells you whether the hearing still needs to happen. A charge counts as open when no verdict has been recorded, or when the recorded verdict is one your community marks as an unfinished case (PENDING out of the box, and whatever else the owner flags that way). So open_charges: 0 means the case has been decided and the entry is history; anything above zero is still live. A report with no charges at all reports 0 — there is nothing to rule on, but the summons is real, so read this field together with the report itself rather than as a filter on its own.

Example

curl "https://api.lux-cad.com/api/v1/court-dates?from=2026-08-24&to=2026-08-30" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "report_id": "871fb442-a981-4be9-80ab-bf44dad78195",
    "report_number": 84,
    "type": "CITATION",
    "type_label": "Citation",
    "title": null,
    "court_date": "2026-08-24",
    "character_id": "2ee16f72-8716-4543-9b63-f7a475e6ee0e",
    "suspect_ids": ["2ee16f72-8716-4543-9b63-f7a475e6ee0e"],
    "issuing_officer": "SASP 190 A.Calloway",
    "open_charges": 1,
    "created_at": "2026-08-07T18:24:29.484775+00:00"
  },
  {
    "report_id": "c1b02318-2b32-43f8-8781-277e6179fc7e",
    "report_number": 85,
    "type": "CITATION",
    "type_label": "Citation",
    "title": null,
    "court_date": "2026-08-24",
    "character_id": "2ee16f72-8716-4543-9b63-f7a475e6ee0e",
    "suspect_ids": ["2ee16f72-8716-4543-9b63-f7a475e6ee0e"],
    "issuing_officer": "SASP 847 Jake S.",
    "open_charges": 2,
    "created_at": "2026-08-07T18:25:35.500140+00:00"
  }
]

Yesterday's no-shows, in one call:

GET /court-dates?from=2026-08-23&to=2026-08-23

Every warrant in your community that is open right now — arrest, search and bench warrants alike.

No parameters. This is the list a "most wanted" board or a Discord bot wants: a warrant appears here while its status is ACTIVE, and drops out the moment it is served, recalled or passes its expiry date.

Order: by warrant_number, ascending.

The fields are exactly those of /warrants, so one parser handles both. On this endpoint status is always ACTIVE.

Example

curl "https://api.lux-cad.com/api/v1/warrants-active" \
  -H "x-lux-api-key: $LUX_API_KEY"

Warrants — one by id, or every warrant on a character or on any character of a Discord user, in any status, with charges and totals worked out.

Send exactly one of warrant_id, character_id or discord_id. since_number and limit are optional and combine with any of them.

Order: by warrant_number, ascending. Page on warrant_number, the same way you page /reports on report_number.

Warrants on an archived character are still returned: a warrant is part of the record, and archiving a character does not erase it.

status is worked out, not copied. A warrant whose expiry date has passed reads EXPIRED even though nobody touched it, exactly as the CAD shows it. SERVED and RECALLED are set by an officer. There is no timestamp for when a warrant was served or recalled; the CAD does not record one.

Each entry in charges:

Charges are ordered by penal_code. Unlike report charges they carry no verdict: a warrant is an order to bring someone in, and the ruling happens on the report that follows.

Example

curl "https://api.lux-cad.com/api/v1/warrants?discord_id=285181941777694720&limit=1" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "warrant_id": "4b0f2c1e-8d7a-4e61-9c3b-2f6a1d9e7c55",
    "warrant_number": 42,
    "warrant_type": "ARREST",
    "status": "ACTIVE",
    "reason": "Fled a traffic stop on Route 68 and rammed a patrol vehicle.",
    "issued_by": "BCSO 904",
    "self_reported": false,
    "issued_by_discord_id": "399949667997319168",
    "character_id": "b7d6bc59-8126-465f-9e67-8e1a353392ca",
    "discord_id": "285181941777694720",
    "first_name": "Robert",
    "middle_name": "James",
    "last_name": "Kane",
    "issued_at": "2026-10-29T19:02:11.204512+00:00",
    "expires_at": "2026-11-12T19:02:11+00:00",
    "created_at": "2026-10-29T19:02:11.204512+00:00",
    "incident_id": "e3a91c07-5d2b-4f88-a1c6-7b0d2e94f310",
    "call_number": "1187",
    "source_report_id": null,
    "report_ids": [],
    "total_fine": 3500,
    "total_jail_days": 40,
    "charges": [
      {
        "penal_code": "P.C. 2004",
        "title": "Evading a Peace Officer",
        "classification": "MISDEMEANOR",
        "charge_count": 1,
        "fine": 1500,
        "jail_days": 10,
        "fine_total": 1500,
        "jail_days_total": 10
      },
      {
        "penal_code": "P.C. 3009",
        "title": "Assault with a Deadly Weapon",
        "classification": "FELONY",
        "charge_count": 2,
        "fine": 1000,
        "jail_days": 15,
        "fine_total": 2000,
        "jail_days_total": 30
      }
    ]
  }
]

The person-lookup endpoint. Two ways in — send exactly one:

Sending neither, both, or a malformed value is a 400.

A Discord user who has no characters in your community — including one the CAD has never seen — returns []. You cannot read a character from another community with your key: an id that belongs to someone else's community simply returns [], exactly like an id that doesn't exist.

Order: oldest first, by created_at.

Building a full name. Join the parts you get and skip the empty ones — do not assume all three are present:

const fullName = [c.first_name, c.middle_name, c.last_name].filter(Boolean).join(" ");

Concatenating unconditionally (`${c.first_name} ${c.middle_name} ${c.last_name}`) yields a double space for the majority of characters, who have no middle name. If you display names in a compact list or a single scrolling line, first_name + last_name is the form the CAD itself uses there.

Example

curl "https://api.lux-cad.com/api/v1/characters?discord_id=285181941777694720" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "character_id": "7f2a19c4-6d83-4b0e-9a51-c3e8f04b7d22",
    "discord_id": "285181941777694720",
    "first_name": "Marcus",
    "middle_name": "Elliot",
    "last_name": "Vance",
    "dob": "1994-02-17",
    "gender": "Male",
    "status": "CLEAN",
    "job": "Mechanic",
    "phone": "555-0199",
    "address": "128 Vespucci Blvd",
    "birth_place": "Los Santos",
    "avatar_url": "https://…/avatars/abc.png",
    "created_at": "2026-07-05T17:15:30.289075+00:00"
  },
  {
    "character_id": "b81c40de-2f77-4c95-8e3a-1d6b90f5a4c8",
    "discord_id": "285181941777694720",
    "first_name": "Sky",
    "middle_name": null,
    "last_name": "Blue",
    "dob": "1998-11-03",
    "gender": "Female",
    "status": "CLEAN",
    "job": null,
    "phone": null,
    "address": null,
    "birth_place": null,
    "avatar_url": "https://…/avatars/def.png",
    "created_at": "2026-07-11T08:02:11.447901+00:00"
  }
]

Create a character for a player who already has a LUX CAD account.

We also cannot check whether that player is a member of your Discord server; membership is read live at sign-in and is not stored. A character you create for someone who is not in your community will simply sit there until they join and select it.

Returns 201 and the character as a single object, in the same shape as GET /characters. Keep the character_id — it is the handle for PATCH.

Example

curl -X POST "https://api.lux-cad.com/api/v1/characters"   -H "x-lux-api-key: $LUX_API_KEY"   -H "Content-Type: application/json"   -d '{
    "discord_id": "291273248543604737",
    "first_name": "Robert",
    "middle_name": "James",
    "last_name": "Kane",
    "dob": "1991-04-17",
    "gender": "Male",
    "job": "Mechanic"
  }'

Update a character. Takes ?character_id=<uuid> and a JSON body.

A real partial update: a field you leave out stays as it is. An empty string clears an optional field (middle_name, job, address, birth_place).

Returns 200 and the updated character, plus an archived boolean.

There is no DELETE, and there will not be one. Twenty-one tables reference a character, and three of those cascade into records that belong to other people — reports naming them as a suspect, warrants, medical treatments. Deleting a character would destroy those without a trace. archived: true is the equivalent: the character disappears from every lookup and picker, and everything written about them stays intact.

Example

curl -X PATCH "https://api.lux-cad.com/api/v1/characters?character_id=7f2a19c4-6d83-4b0e-9a51-c3e8f04b7d22"   -H "x-lux-api-key: $LUX_API_KEY"   -H "Content-Type: application/json"   -d '{ "job": "Paramedic", "address": "1 Elgin Ave" }'

Vehicle lookup. Two ways in — send exactly one:

Sending neither, both, or a malformed value is a 400.

Plates are not unique. Two players can register the same plate, so a plate lookup can return more than one row. Handle a list, not a single object.

Order: by plate, then created_at.

Example

curl "https://api.lux-cad.com/api/v1/vehicles?plate=bert-xl" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "vehicle_id": "1c4d8e02-9b77-4a35-8f60-2ad1e5c93b48",
    "plate": "BERT XL",
    "make": "Albany",
    "model": "Cavalcade XL",
    "year": 2015,
    "color": "Red/Black",
    "type": "SUV",
    "status": "ACTIVE",
    "insurance_status": "EXPIRED",
    "insurance_company": "MORS MUTUAL",
    "insurance_expires": "2026-06-30",
    "owner_kind": "PLAYER",
    "owner_character_id": "7f2a19c4-6d83-4b0e-9a51-c3e8f04b7d22",
    "owner_name": "Kane, Robert James",
    "expires_at": null,
    "created_at": "2026-06-14T20:41:09.882115+00:00"
  }
]

Plate to owner, in two calls (get() is the small fetch helper from the worked example at the bottom of this page):

const [vehicle] = await get("vehicles?plate=BERT-XL");
if (vehicle.owner_kind !== "PLAYER") {
  // No citizen record behind this registration — owner_name is all there is.
  console.log(`${vehicle.plate} → ${vehicle.owner_name} (not a citizen record)`);
} else {
  const [owner] = await get(`characters?character_id=${vehicle.owner_character_id}`);
  console.log(`${vehicle.plate} → ${owner.first_name} ${owner.last_name} (${owner.discord_id})`);
}

Register a vehicle. Either on one of your community's characters, or on a free-text name for a vehicle that has no citizen record behind it.

Send exactly one of character_id or owner_name. Sending both, or neither, is a 400.

Returns 201 and the created vehicle as a single object, in the same shape as GET /vehicles. Keep the vehicle_id — it is the handle for PATCH and DELETE.

Registering a vehicle with no owner

This exists for the case where a vehicle needs to be in the CAD but no player owns it: a stolen NPC car that a script reports with /stolen, for example. Officers can then look the plate up and see the name it was registered under, and the plate alarms on ALPR when status is STOLEN.

Two limits apply, both returning 409:

• A plate must be unique within your community. Registering a plate that already exists is refused — use PATCH on the existing vehicle instead. This is deliberate: the in-game plate lookup picks one row, and a duplicate makes which one non-deterministic.
• 200 live registrations without an owner, per community. If you hit this, your script is not cleaning up. Delete what you no longer need.

Example

curl -X POST "https://api.lux-cad.com/api/v1/vehicles"   -H "x-lux-api-key: $LUX_API_KEY"   -H "Content-Type: application/json"   -d '{
    "plate": "46NXV129",
    "model": "Sultan",
    "color": "Black",
    "owner_name": "Marcus Webb",
    "status": "STOLEN",
    "expires_in_hours": 12
  }'

{
  "vehicle_id": "b58c1e77-3f92-4d10-a6c4-8e02b7d5194a",
  "plate": "46NXV129",
  "make": null,
  "model": "Sultan",
  "year": null,
  "color": "Black",
  "type": null,
  "status": "STOLEN",
  "insurance_status": "NONE",
  "insurance_company": null,
  "insurance_expires": null,
  "owner_kind": "UNLINKED",
  "owner_character_id": null,
  "owner_name": "Marcus Webb",
  "expires_at": "2026-08-20T02:14:31.552108+00:00",
  "created_at": "2026-08-19T14:14:31.552108+00:00"
}

Update a vehicle. Takes ?vehicle_id=<uuid> and a JSON body.

A real partial update: a field you leave out stays as it is. An empty string clears an optional field (make, type, insurance_company).

Returns 200 and the updated vehicle as a single object.

plate cannot be changed. A different plate is a different vehicle, and there is no unique index to catch the collision. Delete and re-register instead.

Transferring ownership is not supported. You cannot turn a player's vehicle into an unlinked one, or the other way round.

Example

curl -X PATCH "https://api.lux-cad.com/api/v1/vehicles?vehicle_id=b58c1e77-3f92-4d10-a6c4-8e02b7d5194a"   -H "x-lux-api-key: $LUX_API_KEY"   -H "Content-Type: application/json"   -d '{ "status": "ACTIVE", "expires_in_hours": 48 }'

Remove a vehicle. Takes ?vehicle_id=<uuid>.

This is a real deletion, not an archive. The row is gone and does not come back.

Returns 200 and { "vehicle_id": …, "plate": …, "deleted": true }.

Refused with a 409 when something else still points at the vehicle:

Unlike DELETE /news-articles this one is not idempotent: deleting a vehicle that is already gone returns 404.

Example

curl -X DELETE "https://api.lux-cad.com/api/v1/vehicles?vehicle_id=b58c1e77-3f92-4d10-a6c4-8e02b7d5194a"   -H "x-lux-api-key: $LUX_API_KEY"

Every civilian service your community has set up, whether or not anyone is on duty for it right now.

Use it to prepare your interface: the right name, icon and colour for each service, so that when a provider comes on duty in /civilian-services you can show them properly. The two are matched on code here and service_code there.

This is configuration, not live state. Read it once at startup and cache it — your admins rarely change it. If you later meet a service_code you don't have, that's your cue to fetch the list again. Services your admins have switched off are not listed.

Order: by the display order your admins configured, then code — the same order the CAD uses.

Modules. These names are stable. A new module may be added to this list later, so ignore a name you don't recognise rather than failing on it.

Example

curl https://api.lux-cad.com/api/v1/civilian-service-types \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "code": "TOW",
    "label": "Tow / Impound",
    "icon": "auto_towing",
    "color": "#f59e0b",
    "short_code": "TOW",
    "audiences": ["civilians", "dispatch", "leo_safr"],
    "sort_order": 10,
    "modules": ["impound", "map", "presence", "radio", "road_status", "tasks"]
  },
  {
    "code": "TAXI",
    "label": "Taxi / Rideshare",
    "icon": "local_taxi",
    "color": "#eab308",
    "short_code": "TAXI",
    "audiences": ["civilians", "leo_safr"],
    "sort_order": 20,
    "modules": ["live_location", "map", "presence", "task_intake", "tasks"]
  },
  {
    "code": "MECHANIC",
    "label": "Mechanic",
    "icon": "build",
    "color": "#3b82f6",
    "short_code": "MECH",
    "audiences": ["civilians"],
    "sort_order": 30,
    "modules": ["presence", "tasks"]
  }
]

Showing who is on duty with each service's own name and icon, including services nobody is working:

let services = await get("civilian-service-types");

async function board() {
  const onDuty = await get("civilian-services");

  // A service added since startup: refresh the list once.
  if (onDuty.some((p) => !services.some((s) => s.code === p.service_code))) {
    services = await get("civilian-service-types");
  }

  for (const s of services) {
    const providers = onDuty.filter((p) => p.service_code === s.code);
    console.log(`[${s.icon}] ${s.label}: ${providers.length} on duty`, s.color);
  }
}

Everyone currently on duty as a civilian service provider — tow operators, taxi drivers, mechanics, lawyers, press, and whatever else your admins have configured. One row per open shift, so a service with three drivers on duty appears three times. For the services themselves, including the ones nobody is working right now, see /civilian-service-types.

This is the same set the CAD shows civilians on its own services page, which means it is also the set that would answer "is there a tow truck online right now?".

A provider is on this list until they go off duty. Shifts that go quiet are closed automatically after a couple of hours, so a stale row cannot linger indefinitely.

Order: by the display order your admins configured for the service, then service code, then started_at.

Example

curl https://api.lux-cad.com/api/v1/civilian-services \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "service_code": "TOW",
    "service_label": "Tow / Impound",
    "service_icon": "local_shipping",
    "service_color": "#f59e0b",
    "short_code": "TOW",
    "audiences": ["civilians", "dispatch", "leo_safr"],
    "character_id": "ecb7aed9-1eb8-4891-be45-fcd6e38fd11e",
    "discord_id": "302607279759425536",
    "business_name": "Benny's Towing",
    "contact": "555-0101",
    "started_at": "2026-07-30T16:23:04.967916+00:00"
  },
  {
    "service_code": "MECHANIC",
    "service_label": "Mechanic",
    "service_icon": "build",
    "service_color": "#3b82f6",
    "short_code": "MECH",
    "audiences": ["civilians"],
    "character_id": "387c03fd-3ecc-46f6-ae17-6109c63e6cc8",
    "discord_id": "961118379614285844",
    "business_name": null,
    "contact": "555-0142",
    "started_at": "2026-07-30T16:38:04.967916+00:00"
  }
]

Counting who is online per service:

const online = {};
for (const s of await get("civilian-services")) {
  online[s.service_code] = (online[s.service_code] ?? 0) + 1;
}
// { TOW: 1, MECHANIC: 1 }

Pinging the on-duty tow operators in Discord, and naming them:

const tows = (await get("civilian-services")).filter((s) => s.service_code === "TOW");
for (const s of tows) {
  const [who] = await get(`characters?character_id=${s.character_id}`);
  console.log(`${s.business_name ?? who.first_name + " " + who.last_name} — <@${s.discord_id}>`);
}

Articles published in your community's newspaper. Built for syncing: ask for everything published since the last article you saw, and page forward until you're up to date.

Order: oldest first, by published_at. This is the opposite of how the CAD displays the paper, and it is deliberate — ascending order is what makes since work as a resume point.

Paging. Keep calling until you get back fewer rows than your limit; each time, pass the published_at of the last row you received as the next since. Because since is exclusive you will never see the same article twice, and because timestamps carry microsecond precision you will not skip one either.

Example

curl "https://api.lux-cad.com/api/v1/news-articles?since=2026-07-25T03:26:08.595569Z&limit=2" \
  -H "x-lux-api-key: $LUX_API_KEY"

[
  {
    "article_id": "8b2d4304-890a-4683-a1a4-ef1878a9e781",
    "service_code": "NEWS",
    "service_label": "News / Media",
    "author_name": "R. Beland",
    "title": "Harbour Road Closed After Multi-Vehicle Collision",
    "subtitle": "Traffic diverted through Elgin Avenue until further notice",
    "body": "Emergency services responded shortly after dawn …",
    "image_url": "https://…/news/harbour.webp",
    "image_aspect": "panorama",
    "vote_count": 4,
    "status": "ARCHIVED",
    "published_at": "2026-07-25T03:27:43.532015+00:00",
    "archived_at": "2026-07-28T03:30:00.101090+00:00"
  },
  {
    "article_id": "182c5611-3ef6-4a50-97c1-fe38a6525f65",
    "service_code": "NEWS",
    "service_label": "News / Media",
    "author_name": "R. Beland",
    "title": "City Council Approves Overnight Parking Ban",
    "subtitle": null,
    "body": "The measure passed six votes to three …",
    "image_url": null,
    "image_aspect": null,
    "vote_count": 1,
    "status": "PUBLISHED",
    "published_at": "2026-07-25T03:28:21.188770+00:00",
    "archived_at": null
  }
]

A complete sync loop:

async function syncNews(since) {
  const seen = [];
  for (;;) {
    const query = since ? `news-articles?limit=100&since=${encodeURIComponent(since)}`
                        : "news-articles?limit=100";
    const page = await get(query);
    seen.push(...page);
    if (page.length < 100) break;          // short page = caught up
    since = page[page.length - 1].published_at;
  }
  return seen; // keep the last published_at as the `since` for your next run
}

Publish an article. It appears in the CAD's paper immediately, for everyone in your community, and it ages out on the same timer as an article written in the CAD itself.

Read Writing first — especially the part about 502.

Body: JSON object. Unknown fields are rejected.

service_code is almost always unnecessary. A community has exactly one paper. news_publish is a module your admins can switch on for more than one service, though, so if that ever happens we pick the active one with the lowest display order and keep going — your script does not break. Pass service_code only if you want to choose explicitly.

character_id decides who can maintain the article afterwards. This matters, so pick deliberately:

Neither is wrong — a bot-written column wants no owner, a player's piece filed through your own tooling does. Just know that the second one is a one-way street away from the CAD's own editing tools.

If you pass character_id, it must belong to your community and not be archived. Get one from /characters.

Unlike the CAD, this endpoint does not require anyone to be on duty as a news provider. That rule exists in the CAD's own interface only.

Returns 201 with the created article, in the same shape as a GET /news-articles row.

Example

curl -X POST https://api.lux-cad.com/api/v1/news-articles \
  -H "x-lux-api-key: $LUX_API_KEY" \
  -H "content-type: application/json" \
  -d '{
        "title": "City Council Approves Overnight Parking Ban",
        "subtitle": "Measure passes six votes to three",
        "body": "The council chamber ran late into the evening …",
        "author_name": "R. Beland",
        "image_aspect": "landscape"
      }'

{
  "article_id": "182c5611-3ef6-4a50-97c1-fe38a6525f65",
  "service_code": "NEWS",
  "service_label": "News / Media",
  "author_name": "R. Beland",
  "title": "City Council Approves Overnight Parking Ban",
  "subtitle": "Measure passes six votes to three",
  "body": "The council chamber ran late into the evening …",
  "image_url": null,
  "image_aspect": "landscape",
  "vote_count": 0,
  "status": "PUBLISHED",
  "published_at": "2026-07-31T09:14:02.317849+00:00",
  "archived_at": null
}

Edit an article you already published. Partial update: send only the fields you want to change; the rest keeps its current value.

Body: the same fields as POST, all optional, except service_code and character_id — those are fixed at publication and cannot be changed.

Clearing an optional field: send an empty string. {"subtitle": ""} removes the subtitle; leaving subtitle out entirely keeps it. title, body and author_name cannot be emptied — they are what makes an article an article.

Only PUBLISHED articles can be edited. Once an article ages out into ARCHIVED it is out of the paper and stays as it was; editing it would rewrite history. You get a 409 telling you the actual status. You can still DELETE it.

Scope: your key can edit any article in your community, including ones written by players in the CAD. The key is a community-level credential; treat it accordingly.

Returns 200 with the article as it now stands.

Example

curl -X PATCH "https://api.lux-cad.com/api/v1/news-articles?article_id=182c5611-3ef6-4a50-97c1-fe38a6525f65" \
  -H "x-lux-api-key: $LUX_API_KEY" \
  -H "content-type: application/json" \
  -d '{ "title": "Council Approves Overnight Parking Ban — Effective Monday", "subtitle": "" }'

Retract an article. It disappears from the CAD's paper and from GET /news-articles immediately.

This is a retraction, not an erasure. The row stays in the database with status RETRACTED, which is how the CAD has always handled a pulled article — and it means reader votes are not silently destroyed along with it. From your side there is no difference: no read endpoint will ever return it again.

It is idempotent. Retracting an already-retracted article returns 200 with the article, not an error, so a retry after a timeout is safe.

Works on PUBLISHED and ARCHIVED articles alike, and — like PATCH — on any article in your community.

Returns 200 with the article, status now RETRACTED.

Example

curl -X DELETE "https://api.lux-cad.com/api/v1/news-articles?article_id=182c5611-3ef6-4a50-97c1-fe38a6525f65" \
  -H "x-lux-api-key: $LUX_API_KEY"

{
  "article_id": "182c5611-3ef6-4a50-97c1-fe38a6525f65",
  "service_code": "NEWS",
  "service_label": "News / Media",
  "author_name": "R. Beland",
  "title": "Council Approves Overnight Parking Ban — Effective Monday",
  "subtitle": null,
  "body": "The council chamber ran late into the evening …",
  "image_url": null,
  "image_aspect": "landscape",
  "vote_count": 0,
  "status": "RETRACTED",
  "published_at": "2026-07-31T09:14:02.317849+00:00",
  "archived_at": null
}