An API integration with no applicant-facing Archistar UI. The permit-software vendor builds the entire applicant experience — including the PreCheck question set and file uploads — and PreCheck runs invisibly in the background. The applicant interaction ends at submit; everything PreCheck-related happens server-to-server.
This is the right pattern when the city wants its permit software to be the single front door for applicants, with no visible second product in the flow.
What the flow looks like. The applicant completes the application in the city’s permit software, including all data and file uploads that PreCheck requires. On submission, the permit software calls the Archistar API with the full payload, Archistar processes the submission, and the report is pulled back via API on completion. The reviewer sees the PreCheck report inside the city’s existing application review queue — no separate UI, no separate login.
The calls behind this pattern
Section titled “The calls behind this pattern”Because your software already holds the files, the one-call file-link method is usually the cleanest — pass a link Archistar can fetch (a signed URL from your DMS).
-
On submit, create the project server-side with file links (Option A). Processing starts immediately.
Terminal window POST /projects # body includes "files": [ { "fileLink": "https://…/drawings.pdf" } ] -
Receive the completion webhook (
project_report_completed) — it carries yourmetadata, so you match it to the permit record without polling. One project sends one event per report. -
Pull the reports and attach them to the application review queue.
Terminal window GET /projects/:projectId/reportsGET /projects/:projectId/document?type=report -
(Optional) Store a signed viewer link on the record so reviewers can open the full project view.
The self-assess trade-off
Section titled “The self-assess trade-off”Because there’s no applicant-facing Archistar surface, the iteration loop lives entirely inside the city’s existing channels — in-portal messaging, correction requests, or email — with the applicant resubmitting through the same flow they used to apply. Cities running this pattern decide up front how that loop should work: whether the applicant is held until findings are addressed, whether reviewers begin in parallel, and whether revisions land as updates to the original submission or as a new one.
These are design choices that sit with the city and the permit-software vendor rather than with PreCheck. If putting an iteration loop directly in front of the applicant is a top priority, embedded or standalone handle that more directly.
Trade-offs
Section titled “Trade-offs”| Pros | Cons | |
|---|---|---|
| For the applicant | Single system, no context-switch, no awareness of a second product | No visibility into PreCheck findings before submission |
| For the city | Maximum control over the applicant UX; PreCheck runs invisibly in the background | The permit software must collect everything PreCheck needs in its own UI |
| For PreCheck quality | Default path is a clean submit-then-review pattern | Self-assess has no in-flow surface here; the iteration-before-submit quality lift is harder to capture |
| Effort to stand up | Same per-vendor integration as embedded | Plus additional UI work to collect the question set and uploads on the vendor side |