Manuscript API 🔒 Restricted
The score is what a destination system receives: a valid request carrying the Intent ID. The manuscript is everything behind it: the scored diagnostic, the answers, the documents, the workflow and its signed PDF. This API serves the manuscript to the people entitled to it, the programme’s MSP and its reporting suites. Destinations never receive it.
The manuscript service runs on Deployed’s production backend (WorkAuthor). Everything on this page matches its published v1 specification exactly.
| Assessments | The scored diagnostics. Each response carries the score, its description, per-section scores, every question and answer, notes, and the ranked outcomes the decision was made from. |
|---|---|
| Documents | Records created from templates with a field payload, returned with an id and a URL, and carrying their full dated lifecycle: created, completed, published, in review, review completed, archived. |
| Surveys | Secondary evidence: who submitted, when, and every question and answer. No score fields. |
| Workflows | The approval record behind a document, including the signed PDF: the evidence entry the Compliance File points at. |
| Correlation | externalId (string, max 64 characters) on assessments and documents carries the Intent ID, so the manuscript and the published score join both ways with no lookup table. |
Base URL https://deployed.workauthor.com/api/v1. All endpoints are service-to-service, authenticated with per-customer API keys. Every operation, parameter and schema is in the full reference 🔒, generated from the service’s own OpenAPI document.
| Endpoint | What it returns |
|---|---|
| GET /assessments | Paged list of assessments: name, group, status, tags and response counts. |
| GET /assessments/{Id} | Paged list of one assessment’s scored responses, filterable by From / To dates. |
| GET /assessments/responses/{Id} | The full scored response: responseId, depReference, externalId, user, startDate / endDate, score, scoreDescription, sectionScores[], questions[], notes[], rankedScores[]. |
| GET /surveys · GET /surveys/{Id} | Paged list of surveys; paged responses for one survey (From / To). |
| GET /surveys/responses/{Id} | A survey response: user, submitted, and questions[] with question, rating and answer. |
| GET /documents/templates | Paged list of templates, filterable by UserEmail. |
| GET /documents/templates/{Id} | A template’s fields and their types (TextShort, TextLong, Number, CustomLookup, Address): what a create call must supply. |
| POST /documents | Create a document from templateId + templateFields, with ownerEmail, coAuthorEmail, documentName, externalId and an optional per-document eventNotification {webhookUrl, events[]}. Returns 201 {id, url}. |
| GET /documents/{Id} | status plus the dated lifecycle: createdDate, completedDate, publishedDate, inReviewDate, internal and external review start and complete, reviewCompletedDate, archivedDate; plus owner, co-authors, collaborators, entities and workflows[]. |
| GET /workflows/{Id} | parentId, parentType, type, status, created and last-updated dates. |
| GET /workflows/{Id}/signed-pdf | The signed PDF for the workflow: the Compliance File’s pdf_signed evidence source. |
Deliveries are signed so a receiver can prove they came from us. The rules, exactly as implemented:
| Headers | One or more X-Signature-HMAC-SHA256-{n} headers. The numeric suffix is an identifier only; it maps to no particular key. |
|---|---|
| Signature | Each value is the Base64-encoded HMAC‑SHA256 digest of the raw request body, computed with one of the active signing keys. Never digest a parsed or re-serialised payload. |
| Key rotation | Several signing keys can be active at once, so a request may carry several signature headers. A request is valid if any computed digest matches any supplied header. |
| Comparison | Timing-safe, always. Requests with no valid signature are rejected, not queued. |
| Per-document events | POST /documents accepts an eventNotification so a single document can notify a chosen URL on chosen events. |
The reference verifier, with the rotation and timing-safe rules as tests, lives in adapter/webhook_verify.py in the composerID reference code.
Every intent carries one Intent ID (itn_…, up to 64 characters). At publish time it lands in the destination record; at creation time it is written into the manuscript’s externalId. The same ID therefore finds the published score in the destination system and the full manuscript here, in either direction, with no lookup table. That is the whole audit story: ask with one ID, get both halves.
Manuscript access is granted per programme, to the MSP and reporting systems the client names, with API keys and signing keys issued at onboarding. It is never part of a destination integration: destinations receive the score, not the manuscript. To arrange access, start from developer access.