Comments and pipeline workflows

Workspace boundaries

Every API key stays bound to the organisation in which it was created. Changing the creator's active workspace does not redirect API requests. Requests act as the key creator and check current membership, roles and bid access. Organisation administrators do not automatically gain access to pipeline content. Removing membership disables the key. Write scopes are separate and unchecked by default in key creation.

Comments and replies

GET /v1/comments requires entityType (tender, buyer, supplier or framework), entityId, and optional limit/offset. Comments are ordered oldest first. POST /v1/comments requires comments:write, the same entity fields, body (up to 5,000 characters), and an idempotencyKey UUID. Supply parentId for a reply in the same thread. Posting to a tender may notify users in your organisation who bookmarked it.

DELETE /v1/comments/{id} soft-deletes a comment. The author or an organisation owner/admin can delete it; deleted entries remain in the thread with a null body. Viewers cannot post or delete. Comments belong to the organisation, not the public procurement directory.

Create and update a pipeline

GET /v1/pipelines lists readable pipelines, newest first. Use q, status and archived=active|archived|all with limit/offset. GET /v1/pipelines/{id} includes stages. Pipeline writes require pipeline:write and current editing permissions.

POST /v1/pipelines creates a pipeline owned by the key creator. Supply a name and idempotencyKey UUID, optionally a tenderId, summary, targetSubmissionDate (YYYY-MM-DD), and stages (names, descriptions, expectedDurationDays). PATCH /v1/pipelines/{id} changes name, summary, status or targetSubmissionDate. Use null to clear an optional date or summary. At least one update field is required.

PATCH /v1/pipelines/{id}/stages/{stageId} changes stage status, name, notes or dueDate. Stage status is pending, in_progress, blocked or completed. The API preserves existing submission controls: changing a pipeline to submitted requires the app's submission receipt and final-file workflow and returns 409 through this endpoint.

POST /v1/pipelines/{id}/archive with {"archived":true} archives a pipeline; false restores it. This uses the existing archive permission and keeps the underlying bid status.

Retry safely

Generate a UUID for each new comment or pipeline. Reuse the same idempotencyKey only for retries of the identical operation. Reusing it with different content returns 409. Successful retries return the existing record. Every accepted attempt still uses one API request. Update, archive and bookmark operations can be retried with the same desired state. The API never submits bids or changes billing.

See the API reference for complete request bodies and response schemas, or use the matching MCP tools.