Integrate without a project.
Open311 GeoReport v2, signed webhooks for request events, and a documented REST API with an OpenAPI file.
What it does
Sentra 311 speaks Open311 GeoReport v2, the open standard for 311 systems: list service types, read requests and accept new ones, with your city’s subdomain as the jurisdiction. Apps and civic tech projects that support Open311 can work with Sentra 311 without custom code.
For your own systems, webhooks send request events — created, assigned, status changed, closed, reopened — to any URL you choose, signed so your server can verify they came from Sentra 311. Everything the staff portal does goes through a documented REST API, described in an OpenAPI 3 file kept up to date with every release.
IT teams need to connect 311 to work orders, GIS and data portals.
How it works
Open311
Services, attributes and requests, GET and POST.
Webhooks
Five request events, HMAC-SHA256 signed, retried with backoff and logged.
REST API
Every staff endpoint documented in OpenAPI 3.
Key features
Open311 GeoReport v2
Services, requests and new requests in JSON.
Signed webhooks
Request events with a signature header and retries.
REST API and OpenAPI
Cursor paging, a standard error shape, If-Match on updates and Idempotency-Key on creates.
Tenant-scoped
Every endpoint is tested so one city can never reach another’s data.
A day with it
Sentra 311 implements GeoReport v2 in JSON with your city’s subdomain as the jurisdiction ID: services.json lists your request types, services/{code}.json returns a type’s questions, requests.json lists and creates requests, and requests/{id}.json returns one. Requests created through Open311 follow the same validation, routing and deadlines as the report page and are marked with the channel “Open311”.
In practice
- Work order system. A webhook sends new streetlight requests to the utility’s system.
- Data warehouse. IT pulls requests nightly through the REST API.
- Civic tech app. A local app lists service types through Open311.
Webhooks and the REST API
Admin › Webhooks sends HTTP POSTs to your URLs on request.created, request.assigned, request.status_changed, request.closed and request.reopened. Each delivery carries a timestamp and an X-Civic311-Signature header so your server can verify it, and failed deliveries are retried.
Common integrations
Typical connections: sending new requests of certain types to a work order or asset system when they’re created (webhook on request.created); updating a GIS or dashboard when requests close (request.closed); pulling requests into a data warehouse nightly through the REST API; or letting a civic tech app read service types and submit requests through Open311. Each city’s API access is scoped to that city, and every endpoint is covered by tests that check one city can’t reach another’s data.
Accessibility, security and privacy
Work-order connectors for systems like Cityworks, Cartegraph and Lucity are on our roadmap; today, webhooks and the API are the integration path.
Who uses it
City IT
Integrate on your terms.
GIS and asset teams
Receive events when requests change.
Civic tech partners
Build on the Open311 standard.
Questions cities ask
Is the API rate-limited?
Yes, public endpoints have rate limits to protect the service.
Who can configure webhooks?
City admins, in Admin › Webhooks.
Is there API documentation?
Yes. An OpenAPI 3 file describes every endpoint and is kept in sync with each release.