Content Preparation

A project is one of two types, chosen first on New project and fixed once it is created. A Deal project has a sending and a receiving party: the handoff, approvals on both sides and delivery to the other side. A Content Preparation project is internal: the organisation gets its own titles and assets together, checks them and delivers them into its own systems. Every title, asset and record in it is the organisation's own, and Zoltar reads and fills from it like any project.

	Deal project	Content Preparation
`kind`	`deal`	`preparation`
Receiving party, client, handoff	Yes	None
Licence window, fee and rights	On the Rights tab	None
Approvals	Deal Approvals, both sides, five stages	Sign-off, one side: received, checked, good, ready, then landed
Work orders	Sending and receiving party lists	One list
Delivery spec and Project QC	The deal spec	Optional; Project QC checks against it when one is chosen
Date	Delivery window	A due date, optional
Delivers to	The other party, by the route both sides agree	The organisation’s own storage connections, with webhooks and the API for its own systems
Close-out	Delivered	Prepared

Catalogue, Markets, every deliverables tab, Project QC, Deliveries, Costs, Inbox and Administration work as on a deal. A link to a tab Content Preparation does not have opens Summary. Fields that belong to a receiving party or a licence (client, counterpartyOrgId, licenceEnds, rightsGranted and the rest) are refused on it with 400 naming the field.

Creating one

In the product: New project, Content Preparation, Next. Name it, give it a due date and a spec if the delivery needs one, and optionally attach a sheet of titles. Runner reads the sheet once the project is open, asks about anything unclear, and adds the titles when you confirm its card. Catalogue's Upload titles does the same at any time.

curl -X POST https://qa.app.final-frame.com/api/v1/projects \
  -H "Authorization: Bearer <your key>" \
  -H "Idempotency-Key: prep-autumn-refresh" \
  -H "content-type: application/json" \
  -d '{"name":"Autumn library refresh","kind":"preparation","deliveryEnds":"2026-11-30"}'
# 201 {"id":"...","kind":"preparation","direction":"outbound","counterparty":null,...}

curl "https://qa.app.final-frame.com/api/v1/projects?kind=preparation" -H "Authorization: Bearer <your key>"

Every project in /v1/projects carries kind, and ?kind=deal or ?kind=preparation narrows the list. From an assistant, create_project and find_projects take kind too.

Sign-off

One side signs each stage, in order, and a signature is withdrawn only while nothing after it is signed. Anyone who holds project.configure may sign; a key must carry it too.

Stage	Key	Means
Received	`received`	Everything expected is in: the titles, their files and their records.
Checked	`checked`	Every file and record has been looked at, by Project QC where a spec is chosen.
Good	`good`	What was checked passes. Nothing is left to fix.
Ready	`ready`	Packaged and ready to go into your own systems.
Landed	`landed`	A delivery to your storage completed. Never signed by a person: it is read from the delivery.

GET /v1/projects/{id}/approvals on a Content Preparation project answers internal: true with these stages, each signed, open or waiting, and prepared once all five are done. POST /v1/projects/{id}/approvals/{stage}/approve signs one of the first four. Change requests are refused: there is no other side. The MCP tools read_deal_approvals and approve_deal_stage work the same way.

Webhooks

Event	data
`approval.approved`	`stage`, `side` `internal`, `approvedBy`, `next` and `prepared`. For landed: `automatic`, `storageDeliveryId`, `destination` and `files`.
`approval.revoked`	`stage`, `side` `internal`, `revokedBy`, `note`.
`delivery.completed`	The delivery to your storage itself, as on any project.
`deal.closed`	The close-out, with `deal.kind` and `preparation`: the sign-off and where the delivery landed.