Reference · built on requestConnectorWork & ticket management

Wrike

Tasks, folders, projects, custom fields, approvals, and timelogs from Wrike accounts through the Wrike API v4 and webhooks.

Request accessPricing ↗

About

Wrike is a work management platform. An account holds spaces, folders, and projects; tasks sit inside them with a status, importance, dates, responsibles, custom fields, approvals, and timelogs. The API v4 answers under https://<host>/api/v4, where host comes back with the OAuth token because Wrike keeps customer data in United States and European Union data centers.

Through Fibric, an operator reads tasks and custom fields, receives webhook events such as TaskStatusChanged and CommentAdded, and proposes a status change, an assignee, a comment, or an approval. Nothing is written until you approve it, and every applied change keeps a record you can reverse.

This is a reference listing. It documents what Fibric would read from Wrike and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Tasks across the account or within a folder through GET /tasks and GET /folders/{folderId}/tasks, with status, importance, dates, and responsibles
  • Folders, projects, and spaces through GET /folders, including a project's status, owners, and dates
  • Custom fields on the account through GET /customfields, and their values on tasks and folders
  • Comments through GET /comments, and approvals with each decision through GET /approvals
  • Timelogs through GET /timelogs, and workflows with their custom statuses through GET /workflows
  • Webhook events registered per account, folder, or space, such as TaskCreated, TaskStatusChanged, TaskResponsiblesAdded, TaskCustomFieldChanged, CommentAdded, and TaskApprovalDecisionChanged

Proposed actions

  • Target capability: propose a status, customStatus, importance, dates, or responsibles change through PUT /tasks/{taskId}
  • Target capability: propose a comment on a task through POST /tasks/{taskId}/comments
  • Target capability: propose an approval on a task through POST /tasks/{taskId}/approvals, or a change to one through PUT /approvals/{approvalId}
  • Target capability: propose a custom field value on a task through the customFields parameter of PUT /tasks/{taskId}

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Move a stalled task out of Active

    The operator reads Active tasks whose dates have passed and proposes a comment to the responsibles, or a Deferred status through PUT /tasks/{taskId}, for your approval.

    With Action Follow-up

  • Raise a project change from the ticket queue

    When a support ticket needs a project change, the operator proposes a Wrike task with the ticket summary, names the responsibles, and requests an approval on the task.

    With Escalation Packet, Ticket Triage

  • Sign off timelogs before the period closes

    The operator reads timelogs through GET /timelogs with their billingType and proposes the tasks missing hours for a manager to review.

    With Timesheet Signoff

Requirements

  • A Wrike account and an application in the App Console at wrike.com/appconsole.htm with a client id and client secret
  • Scopes Default and wsReadOnly for reads, wsReadWrite for task updates, comments, and approvals, and amReadOnlyWorkflow to read workflows
  • The host value returned with the token, used as https://<host>/api/v4 for the account's data center
  • An HTTPS endpoint that answers Wrike's X-Hook-Secret handshake with an HMAC-SHA256 of the secret before events flow
Authentication
OAuth 2.0 through https://login.wrike.com/oauth2/authorize/v4 and https://login.wrike.com/oauth2/token with client credentials from the Wrike App Console; access tokens last one hour and each refresh returns a new refresh token.

Limits

  • Wrike returns HTTP 429 too_many_requests at 400 requests per minute per IP or access token, and rate_limit_exceeded when other limits are reached
  • Webhook delivery is retried up to 3 times for retryable statuses; any other 4xx suspends the webhook until PUT /webhooks/{webhookId} sets status Active
  • Wrike does not guarantee once-only webhook delivery; the connector reads the duplicate-detection header Wrike sends and drops repeats
  • TaskParentsAdded does not reliably report tasks added to folders; Wrike advises TaskCreated with client-side filtering

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Wrike ↗

Questions and answers

Which events can a Wrike webhook send?
Task events such as TaskCreated, TaskStatusChanged, TaskDatesChanged, TaskResponsiblesAdded, TaskCustomFieldChanged, and TaskApprovalDecisionChanged; folder and project events such as ProjectStatusChanged; plus CommentAdded, AttachmentAdded, and TimelogChanged. Webhooks are registered through POST /webhooks, POST /folders/{folderId}/webhooks, or POST /spaces/{spaceId}/webhooks.
Why does the API host differ between accounts?
Wrike stores customer data in data centers in the United States and the European Union. The token response includes a host value, and every call goes to https://<host>/api/v4. The connector stores the host with the token and never assumes www.wrike.com.
How does Wrike check a webhook endpoint?
On creation Wrike sends a request with an X-Hook-Secret header and a body of requestType WebHook secret verification. Your endpoint returns an HMAC-SHA256 of that secret in the same header. Later events carry X-Hook-Signature, an HMAC-SHA256 of the body keyed by your secret, and arrive as JSON arrays.
Ask about Wrike

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Wrike through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy