Create and use an API key.
Workspace owners and admins can create keys in Developer tools. Copy a new key when it appears; MCPBinder stores only its hash and will not show it again. Choose read access or task editing, set an expiry, and revoke the key when it is no longer needed.
Send each request over HTTPS with Authorization: Bearer YOUR_API_KEY. Each key is limited to 120 requests per minute. The API returns JSON. Project and task lists support cursor pagination; each page contains at most 1,000 records.
https://www.mcpbinder.com/api/v1
Available endpoints.
Read access supports workspace details, projects, and tasks. Task editing keys can also create, update, and archive tasks. Task updates require the current version number; if someone changed the task first, the API returns a conflict so you can fetch the latest record before retrying.
Timestamps such as createdAt are ISO 8601 strings in UTC, for example 2026-09-28T14:05:00.000Z. dueOn is a calendar date such as 2026-09-28, with no time or time zone.
- GET /workspace — current workspace identity.
- GET /projects — visible projects.
- GET /tasks — visible active tasks; optionally filter with ?projectId={uuid}. GET /tasks/{id} — a visible task record with archivedAt when archived.
- POST /tasks — create a task with title and optional description, projectId, and dueOn.
- PATCH /tasks/{id} — update title, description, dueOn, status, workflow status, sectionId, labelIds, or assignee. Include version and at least one field to change.
- DELETE /tasks/{id}?version={n} — archive a task using its current version. This does not permanently delete the task.
Read every page of projects or tasks.
GET /projects and GET /tasks accept limit (1–1,000; default 1,000) and cursor. Each response includes data, hasMore, and nextCursor. Pass nextCursor as cursor on the next request until nextCursor is null. Keep the same projectId filter throughout; URL-encode query values.
Records are returned in stable ascending ID order. Editing an item does not move it between pages. Cursors are protected against tampering and tied to the workspace, user, resource type, and project filter. Permissions are checked on every page. Invalid or mismatched cursors return 400. This is a live list, not a snapshot: newly created records before your cursor need a fresh traversal, while records archived or no longer visible disappear.
GET /api/v1/tasks?limit=100&projectId=PROJECT_UUID&cursor=NEXT_CURSOR
Create and update a task.
Send JSON with Content-Type: application/json. Include an Idempotency-Key header on creates so retrying the same request does not create duplicate work.
- POST /tasks body: { "title": "Review launch brief", "projectId": "PROJECT_UUID" }.
- PATCH /tasks/TASK_UUID body: { "version": 1, "status": "in_progress" }.
Subscribe to task events.
Create an HTTPS endpoint in Developer tools and choose which task events it should receive. Each POST contains an event id, type, creation time, and task data: id, taskNumber, projectId, title, status, workflowStatusId, version, and updatedAt. Current events are task.created, task.updated, task.completed, and task.archived.
Task webhooks are configured by workspace owners and admins. They send task titles and status metadata to the public HTTPS endpoint you choose; its operator receives that information under their own terms. A change to done emits both task.updated and task.completed. Deliveries run in the background, may arrive out of order, and can be repeated if a network failure leaves the result uncertain. Network failures, 408, 429, and 5xx responses retry with backoff for up to six attempts; other non-2xx responses are marked failed. Return a 2xx response once your service has accepted the event, and deduplicate by event id.
- X-MCPBinder-Event — event type.
- X-MCPBinder-Event-Id — stable event id for deduplication across retries.
- X-MCPBinder-Delivery-Id — unique queued delivery id.
- X-MCPBinder-Timestamp — Unix timestamp in seconds.
- X-MCPBinder-Signature — t={timestamp},v1={hex HMAC-SHA256}.
Inspect and redeliver failed events.
In Developer tools, open Webhook deliveries. Failed events appear first; select All deliveries to see queued, running, and completed deliveries. Inspect event shows the original request body. Refresh to update status, or load more to browse older events. Only workspace owners and admins can inspect payloads or request a redelivery, and these actions require a recent security check.
After fixing the receiver, choose Redeliver event and confirm. A new delivery is queued with the original event ID and exact original body, a new delivery ID, and a fresh timestamp and signature. The original failed delivery is preserved and the request is recorded in the audit log. Repeated clicks reuse the same redelivery; if that delivery fails, retry the new failed delivery. Revoked endpoints cannot be redelivered. Always deduplicate by event ID, since a receiver may have accepted an event even when the sender observed a failure.
Verify webhook signatures.
Copy the signing secret when you create the endpoint; it is shown once. Read the request body as raw bytes before parsing JSON. Compute HMAC-SHA256 using the secret and the UTF-8 string `${timestamp}.${rawBody}`. Compare the hex digest to v1 using a constant-time comparison, and reject timestamps outside your short replay window. Only then parse the JSON and process the event.
The endpoint URL is checked when saved and again before delivery. Use a public HTTPS address. The full URL and signing secret are encrypted at rest; the settings page shows only the endpoint origin, without its path or query. Revoking an endpoint stops queued future sends, but cannot recall an event already delivered or a request already in flight.
Errors and access.
A 401 means the key is missing, expired, revoked, or its creator is no longer a workspace owner or admin; keys whose creator loses that role are revoked automatically. A 403 means the key lacks the required permission or the requested project is not visible to its creator. A 409 means the task version is stale. A 429 includes Retry-After. Workspace project visibility still applies to API keys.