Embedded intake

An API integration with applicant-facing intake. The applicant lives in the city’s permit software for most of their journey, and is briefly lifted into Archistar’s UI to complete the PreCheck step. Results land back in the city’s system via webhook and API pull, and the report can be embedded in the application view via a signed viewer link, so reviewers don’t leave the permit software.

This is the strongest pattern for tight integration combined with the quality lift from self-assess — the applicant is already in Archistar’s UI for intake, so adding a review-and-iterate loop is a small extension.

What the flow looks like. The applicant logs into the city’s permit portal, creates an application, and clicks Run AI PreCheck at the configured step. The permit software creates a draft submission in Archistar via API, hands the applicant off to Archistar for the question set and uploads, then receives the completion webhook and pulls the report back. The applicant returns to the city portal; the report is visible inside the existing application record.

The calls behind this pattern

1. Create a draft project when the applicant reaches the PreCheck step. Store the projectId against your application record.

   POST /projects            # → { "id": "P_7A3F21C9" }

2. Hand the applicant off to finish in Archistar (Option C) — redirect them to the completion link to complete the question set and uploads, then return to your portal. (Or collect files yourself and use Option B.)

   GET /projects/:projectId/complete-link

3. Receive the completion webhook (project_report_completed), carrying your metadata so you can match it to the application. It fires once per report.

4. Embed the signed viewer link in the application record so reviewers see the live project view without leaving the portal.

   GET /projects/:projectId/viewer-link?signed=1&generatedFor=reviewer@city.gov

5. Self-assess loop — to let the applicant fix and retry, add the replacement file and process again. Each attempt refreshes the project’s reports.

Full code — API reference cURL + TypeScript for create, upload, process, status, and embedding the viewer.

Tip

See this pattern end to end in the Sandbox — choose Gated or Ungated.

When this fits

• Your permit software is API-capable and your vendor has appetite for the integration build.
• You want PreCheck visible in the applicant flow rather than running invisibly.
• You want to gate progression on PreCheck results — e.g. block submission to formal review until PreCheck completes successfully.
• Improving submission quality before formal review is a priority. Embedded is the strongest fit for self-assess.

The vendor must be able to call the Archistar API, store the submission ID against their application record, handle the completion webhook, embed the viewer link, and hand the applicant off and back at the right point in the flow. Once that integration exists for a vendor, per-city configuration is light — mostly tenant setup, not custom code.

Trade-offs

	Pros	Cons
For the applicant	Stays in the familiar city portal for everything except the PreCheck intake step	Brief context-switch into the Archistar UI may feel like two systems
For the city	Tight integration; ability to gate progression on results; embedded results view inside the existing application record	Requires a real integration build with the permit-software vendor
For PreCheck quality	Self-assess slots in naturally — the strongest pattern for iteration-before-submit	Quality benefit only materialises if self-assess is actually enabled
Effort to stand up	Once the vendor integration exists, per-city configuration is light	Initial vendor integration is the heaviest lift of the three patterns