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.
When this fits
Section titled “When this fits”- You want PreCheck to be a background capability, not a visible product to applicants.
- Strong branding, accessibility, or internal policy reasons mean the permit software must be the only applicant-facing surface.
- Your permit-software vendor has appetite to build both the integration and the intake UI for PreCheck’s question set and uploads.
- Submission quality lift from self-assess is not the top priority — or you have a separate process for it.
Backend-only requires everything embedded requires, plus the permit software must collect the full PreCheck question set and file uploads natively within its own application form, and maintain that intake UI as the question set evolves. This is meaningfully more vendor-side work than embedded.
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 hosted 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 is awkward to retrofit; 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 |