Skip to main content
The Manuscript API serves the record behind a decision to the people entitled to it: the programme’s MSP and its reporting suites. This page covers what the manuscript holds, the twelve endpoints, how webhook deliveries are signed, and how the Intent ID joins the manuscript to the operational reference. A destination system receives the operational reference: 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. Operational destinations do not receive the manuscript; authorised reporting platforms use the separate reporting path.
The Manuscript API is the API of Deployed’s production backend, WorkAuthor, served at https://deployed.workauthor.com/api/v1. This section is its documentation: every endpoint page is generated from the service’s v1 OpenAPI document, and the build fails if that document and these pages disagree. Calls are service to service with per-customer API keys, webhook deliveries are HMAC-SHA256 signed, and access is granted per programme.

​
What the manuscript holds

Each response carries the score, its description, per-section scores, every question and answer, notes, and the ranked outcomes the decision was made from.
Created from a template with a field payload and returned with an id and a URL. Each carries its full dated lifecycle: created, completed, published, in review, review completed, archived.
Who submitted, when, and every question and answer. Surveys have no score fields.
Includes the signed PDF: the evidence entry the Compliance File points at.
externalId on assessments and documents carries the Intent ID, so the manuscript and the operational reference join both ways with no lookup table. CreateDocumentBody.externalId declares a maximum of 64 characters; the assessment and document response schemas declare it as a plain nullable string.

​
Endpoints

All twelve operations are relative to https://deployed.workauthor.com/api/v1. List operations page with Page and PageSize. Every operation, parameter and schema is on the endpoint pages in this tab, generated from the service’s own OpenAPI document. Errors share one shape across every operation: type, title, status, an errors[] array of code, description and type, and a traceId.

​
Signed webhooks

Deliveries are signed so a receiver can prove they came from WorkAuthor. Verify every delivery in this order.
1

Read the raw request body

Use the body exactly as received. Never digest a parsed or re-serialised payload.
2

Compute a digest with each active signing key

For each of your active signing keys, compute the HMAC-SHA256 digest of the raw body and Base64-encode it. Several keys can be active at once during rotation.
3

Compare against every signature header

The request carries one or more X-Signature-HMAC-SHA256-{n} headers, one per active key on the sending side. Compare each computed digest against each header value with a timing-safe comparison. The numeric suffix is an identifier only; it maps to no particular key.
4

Accept on any match, otherwise reject

The request is valid if any computed digest matches any supplied header. A request with no valid signature is rejected, not queued.
POST /documents accepts an eventNotification so a single document can notify a chosen URL on chosen events. Signed webhooks quotes the rules and the vendor’s C# and Node.js examples in full, and Webhook events lists the event types. The reference verifier, with the rotation and timing-safe rules as tests, is adapter/webhook_verify.py in the composerID reference code.

​
One ID, reference and manuscript

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 is the intended join. Verify that it is populated correctly in both systems during the connection test; API availability alone does not prove that linkage.

​
Access

Manuscript access is granted per programme, to the MSP and reporting systems the client names, with API keys and signing keys issued at onboarding. The OpenAPI document declares no security scheme because API-key authentication is configured per customer, outside the specification. Manuscript credentials are separate from the Intent API’s: Authentication covers the Intent API only. Manuscript access is never part of a destination integration: operational destinations receive the reference; authorised reporting receives Manuscript data. Reference and decision detail explains the boundary.

​
Next steps

Signed webhooks

The signing rules as quoted from the OpenAPI document, with verifier examples.

Webhook events

The event types and the per-document notification configuration.

Score and manuscript

How operational references and authorised reporting use separate data paths.