Auth check

Fetch the extraction, derived verdicts, and presigned URLs for a standalone auth-check upload.

token is required: an embed token minted for this same document via POST /v0/auth-check/<filename>/embed-token, which carries the patient data the patient-comparison checks (patientName, patientDateOfBirth, signerName, capability, minorAuthorization, deceasedAuthorization) compare against. A missing token, a token minted for a different document, or an expired or tampered token is rejected with 401. A filename that is not a single path segment of at most 255 bytes, starts with a dot, or has no name before its extension is rejected with 400.

A null field in verdicts means that check did not run — it does not mean the check passed. datesOfService is scoped to a record request and never runs here; a HITECH authorization type detected on the document clears the revocation / redisclosure / conditioning / sensitive-info verdicts; documentValidity is null when no supporting documents raise a concern. The exception is sensitiveInformation: a null category verdict there means that category was not requested, and noSensitiveInformationRequested is set only when none is. purposeAlignment needs the owning project’s purpose, which a standalone submission has none of, so it never runs here.

While the analysis is still running, verdicts is null as a whole. Poll on verdicts, not extraction: extraction can already be present, with empty data, before the analysis finishes.

The extraction schema evolves as we expand document-type and edge-case coverage. If you are rendering the result to end users, prefer the iframe embed over consuming this schema directly — see Embedding the auth-check UI.

This endpoint also returns a presigned uploadUrl. That is preserved for backwards compatibility — new integrations should use PUT /v0/auth-check/<filename> to obtain an upload URL, which avoids the extra S3 read-side work this endpoint performs.

Request a presigned S3 upload URL for a standalone auth-check file.

Use this endpoint whenever you need to upload — previously customers had to call GET /v0/auth-check/<filename> and pluck the uploadUrl out of a combined read/write response. Prefer this route: it never touches S3 on the read path, so it is cheaper and returns faster.

You may optionally send the same patient-context body accepted by POST /v0/auth-check/<filename>/embed-token. When you do, the response carries a pre-minted embedToken for this document, saving that extra round-trip — fetch and embed can proceed as soon as the upload completes. Omit the body if you don’t yet have the patient context (e.g. the user uploads first and fills the form later); mint it separately when ready.

Patient context sent here is stored with the submission, so it stays reviewable in the auth-checker’s Submissions tab after the one-hour embed token expires. Uploading again under the same filename records a new submission with the patient context sent that time.

The body may also carry an optional referenceId: your own identifier for the patient (an MRN or account number), at most 255 characters, shown in the Submissions tab so the submission can be matched back to your patient. A blank value is treated as absent, and a longer one is rejected with 400. It is stored with the submission only, never in the embed token.

filename must be a single path segment of at most 255 bytes, must not start with a dot, and must have a name before its extension; anything else is rejected with 400.

After a successful PUT to the returned uploadUrl, call GET /v0/auth-check/<filename> to fetch the analysis payload and a presigned download URL for the uploaded object.

Mint an embed token for iframing the auth-check UI.

The token encapsulates the patient info and PDF storage key so the read-only embed view at GET /ui/auth-check/embed?token=... can render without any session or DB lookup. Tokens are stateless, sealed with authenticated encryption (encrypt-then-MAC, keyed apart from the generic URL-query oracle), and expire one hour after minting. The pdfStorageKey is derived server-side from the authenticated user, so a caller cannot mint a token for another user’s document.

The same token is also required by the JSON endpoint GET /v0/auth-check/<filename>?token=..., which uses its patient info to run the patient-comparison verdicts.

The patient info is also stored with the submission, so it stays reviewable in the auth-checker’s Submissions tab after the token expires. Minting again for the same filename with different patient info corrects it.

The body may also carry an optional referenceId: your own identifier for the patient (an MRN or account number), at most 255 characters, shown in the Submissions tab beside the patient. It is stored with the submission only, never in the token. Minting again with a different referenceId replaces it. Minting for the same patient without one, or with a blank one, keeps the reference already recorded, so a recorded reference cannot be removed this way; minting for a different patient drops it unless a new one is sent, and re-uploading the document clears it. A longer referenceId is rejected with 400.

filename must be a single path segment of at most 255 bytes, must not start with a dot, and must have a name before its extension; anything else is rejected with 400.

This endpoint is for the standalone flow (a document uploaded outside any patient context — typically via the auth-checker UI). For patient- or record-request-scoped documents, PatientOutput and RecordRequestOutput responses include a pre-minted embedToken field and this extra round-trip is unnecessary.

See Embedding the auth-check UI for the full iframe integration guide.

Discards the document’s current analysis and queues it to be analyzed again. The call returns as soon as the re-run is queued; until it finishes, GET /v0/auth-check/{filename} reports verdicts as null. The document must already have been uploaded.