Pass-through integration for local government · records are never stored System status1-559-251-7767Sentra familySign in
SentraBridgeIntegration platform
Permitting Integration basicsSeptember 17, 2026 · 4 min read

Connecting 311 to Accela without custom code

Code-enforcement complaints arrive in 311 and are worked in Accela. Here is how to connect the two in both directions, what Accela requires first, and where cities usually get stuck.

Residents report code problems through 311: overgrown lots, abandoned vehicles, unpermitted construction. Code enforcement officers work those cases in Accela. Without a connection, someone retypes each complaint, and residents never hear that their case was closed.

The integration itself is simple to describe. Code complaints in 311 become Accela records, and when a record is closed in Accela, the matching 311 request closes too. Getting there without custom code takes some preparation.

Before you start: what Accela needs

An app, approved by your agency

Accela's Construct API v4 uses an app registered on Accela's developer portal. The app ID and secret come from there, but your agency administrator must approve the app for your agency before it can read or write your records. Ask for this early. It is the step that most often delays a project.

A user for the integration

The connection signs in as an Accela user, with your agency name and environment (such as PROD). Give that user only the record types it needs, and name it so your staff recognize its changes in the audit history.

Your record types and statuses

Every agency configures Accela differently. One city's complaint type is Enforcement/Complaint/Weeds/NA; another's is entirely different. Write down the record types you want created and the statuses that mean "closed" before you build anything.

Direction one: 311 to Accela

Sentra 311 can call in the moment a request is created, using a webhook. The flow checks the department, shapes the request as an Accela record, and creates it.

Flow diagram: 311 code-enforcement requests become Accela recordsWhen Sentra 311 sends request.created, code-enforcement requests become new Accela records. Everything else is ignored.Sentra 311 calls inWhen a system calls inCode enforcement?If / elseShape as an AccelarecordMap fieldsCreate Accela recordSend records · AccelaYes
311 code-enforcement requests become Accela records · 4 steps · a real SentraBridge template

The steps in plain terms:

  • When a system calls in. Sentra 311 sends request.created. The flow can check the sender's signature so only genuine messages are accepted.
  • If / else: code enforcement? Only requests for the Code Enforcement department continue. Everything else is ignored.
  • Map fields. The record type is built from the 311 category, the description is prefixed with the 311 number, and the address is copied across.
  • Send records. A new Accela record is created, and its ID is read from the response.

The 311 request number is stored as Accela's custom ID, starting with REQ-. That small choice is what makes the return trip possible.

Direction two: Accela back to 311

Here is the catch: Accela does not send webhooks. There is no message when a record changes. Instead, the integration asks Accela on a schedule for records updated since the last good run, using the updateDateFrom filter.

Flow diagram: Closed Accela records close their 311 requestsEvery 15 minutes, finds Accela records closed since the last run and closes the matching Sentra 311 request.Every 15 minutesOn a scheduleChanged Accela recordsGet records · AccelaClosed, from 311FilterClosing updateMap fieldsClose 311 requestSend records · Sentra 311
Closed Accela records close their 311 requests · 5 steps · a real SentraBridge template
  • On a schedule. Every 15 minutes is a common choice. You can go more or less often.
  • Get records, only changed. Reads Accela records updated since the last successful run.
  • Filter. Keeps records whose status is Closed or Complete, and whose custom ID starts with REQ-, so only records that came from 311 are touched.
  • Send records. Updates the matching 311 request to closed.

Because the flow only reads changes since the last good run, a missed run catches up on its own the next time.

Where cities get stuck

  • Status names. "Closed", "Complete", "Closed - No Violation". Check every status that should close a 311 request, and decide what happens to the rest.
  • Address formats. Accela may expect a parsed address. Preview a few real records before turning the flow on.
  • Loops. If Accela changes also flow back into 311 and 311 changes flow to Accela, make sure one system's update doesn't trigger the other forever. Filtering on the REQ- prefix helps.
  • Volume. A full first sync of years of records is different from a 15-minute check. Start with recent changes.

Doing it in SentraBridge

SentraBridge ships both flows as templates, with a pre-built Accela connector that knows the records, fields, paging and sign-in. You pick the template, connect your Sentra 311 and Accela, adjust the record type and statuses for your agency, and preview it on real records. Nothing is written until you turn it on.

If you use OpenGov Permitting & Licensing instead, the same pattern applies with a different connector. More examples are on the 311 and permitting solution page.