Review supplier file disclosure
An agent can prepare a quote request. Sharing engineering files with suppliers requires a stored approval for the exact disclosure. A key’s approvals:write scope lets it propose that review; it does not let the key approve its own proposal.
This guide describes the HTTP contract observed on September 22, 2026, matching platform source 0319a80. The hosted CLI 0.6.14 and MCP 0.2.14 do not yet have dedicated tools for these approval and disclosure endpoints. Use an authorized HTTP integration and the owner’s workspace. This contract review is not evidence of a completed real supplier pilot or configured email delivery.
Before proposing a request
Section titled “Before proposing a request”You need a live founder key, a saved quote_request action, a current reviewed engineering snapshot, and the owner’s grant allowing that exact key to read the package. Local file access, upload permission and permission to disclose to a supplier are separate grants. See engineering access and selected-file transfer.
The current publication selection supports one mapped part (partIndex: 0, quantityPerUnit: 1), one to five factories and one to eleven selected files, with USD or CNY terms. Do not force a multi-part build into that shape. Resolve unavailable or stale engineering inputs before publishing.
1. Read the exact disclosure
Section titled “1. Read the exact disclosure”Call GET /actions/{id}/publication/review with the intended supported options, including factory IDs and commercial terms. Read the returned review.state, review.selection, manifest and review.reviewSha256. A not_publishable result is a reason to resolve the missing inputs, not permission to manufacture a digest.
The selection binds the managed project, engineering snapshot/hash, factory IDs, file IDs, part mapping, currency, Incoterm and named place, deadline, destination, anonymization and message wording. Keep the exact reviewed selection; show the actual recipients, filenames/revisions and terms to the owner.
Review request and response fields.
2. Propose an owner decision
Section titled “2. Propose an owner decision”Call POST /actions/{id}/publication/approval with these fields:
| Field | Value |
|---|---|
approvalId |
A newly generated UUID retained for this proposal’s recovery |
expectedReviewSha256 |
The digest returned by the exact review |
selection |
The complete reviewed selection |
A new proposal returns 201; an existing proposal can return 200 with replay information. Save the returned approval.approvalId, since an existing live approval for that revision may be reused. Check its status and expiry rather than interpreting a successful proposal request as approval.
This step creates no RFQ, invitation, supplier message or file grant. It cannot set an approver. The owner signs in to Agent publication approvals, opens the action and reviews the proposal. The owner can approve the exact record or revoke it. An expired undecided proposal can remain in the queue; revoke it before preparing a fresh proposal.
Do not ask the owner to paste session cookies into a terminal or chat. The owner’s decision is made through their own authenticated workspace.
3. Publish the approved revision
Section titled “3. Publish the approved revision”Using the same proposing key, call POST /actions/{id}/publication with:
| Field | Value |
|---|---|
expectedReviewSha256 |
The exact approved review digest |
approval |
An object containing only approvalId, naming the stored owner decision |
selection |
The unchanged approved selection |
An old request carrying caller-supplied userId or sessionId is rejected. Missing, revoked, expired, spent or mismatched approval cannot authorize a new disclosure. A valid NDA standing, export attestation and screening are also checked; an agent cannot satisfy them by writing that they are complete.
Publication creates or revises a managed request and its supplier invitations, threads and exact file grants. Inspect the returned RFQ ID, revision, recipient account states, granted files and pending disclosure IDs. This is a real disclosure operation, separate from email transport and separate from accepting a quote or ordering production.
An identical reviewed publication returns its existing receipt. A changed recipient, file or term requires a fresh review and owner approval, then a new revision of the same request. Existing recipients cannot silently be removed through a revision; revocation is a separate operation. Earlier revisions and supplier replies remain historical evidence.
4. Track who can receive or read the files
Section titled “4. Track who can receive or read the files”GET /pending-disclosures requires a live buyer key with quotes:write. Optional filters are projectId (the managed project), rfqId and state. This is an organization-scoped read; it publishes and revokes nothing.
| State | Meaning |
|---|---|
pending |
No supplier account has received the files through this record yet. Binding an account before the deadline can deliver the approved package without a second approval. |
delivered |
File access was granted. The record remains the handle for revocation. |
expired |
The pending handover window closed. It does not permit a later binding to receive that package. |
revoked |
The disclosure was withdrawn. Earlier delivery timestamps remain visible. |
New pending handovers have a 30-day window; use the stored expiresAt for each record. Expiry does not revoke access already delivered. The response includes counts for the returned bounded list and truncated; those counts are not proof that every matching disclosure was returned.
5. Withdraw access explicitly
Section titled “5. Withdraw access explicitly”The workspace’s File disclosures is the normal human review surface. An HTTP integration can use POST /pending-disclosures/{id}/revoke, but it requires both the live buyer key and a signed-in browser session in the same organization. The key alone returns sign_in_required. The optional body field reason is trimmed, limited to 2,000 characters and retained in the audit record; unknown fields are rejected.
Read the entire result:
revokedGrants: file grants actually removed.cascaded: other disclosures of this request to the same supplier organization that were revoked together. Access belongs to the organization, not one directory site.retainedGrants: access still authorized by a separate disclosure, with the record that preserves it. Inspect that authority before deciding whether to revoke it too.openedBefore: recorded reads before revocation. An empty list does not prove that nobody saw or copied the files.alreadyRevoked: an idempotent repeat; it is not a new disclosure decision.
Revocation prevents reads that no remaining grant authorizes. It cannot erase a downloaded copy. Re-publishing or creating a later revision does not silently restore revoked supplier access.
Recover without guessing
Section titled “Recover without guessing”Keep the action ID, proposing key identity, approval ID, exact selection/hash and publication receipt. After a lost response, inspect saved state and re-propose only the same unchanged proposal when appropriate. Never invent an owner decision or replace changed terms under an older approval.
Read submitted quotes through the supplier reply workflow, checking answersRevision and supersededByRevision against the invitation’s currentRevision and publishedRevisions. A null revision is unknown linkage, not acceptance of the current terms. A quote answering an earlier revision does not accept the latest terms. An email-server delivery event is not a supplier reply, and a submitted quote is not a production order.