.png)
Wrike Integration Guide
Integrate Wrike with enterprise systems through its REST API, OAuth 2.0 authentication, webhooks, Events API, asynchronous operations, and attachment endpoints.
Wrike integration options at a glance
Wrike’s primary enterprise integration mechanism is its versioned REST API, which can read and manage Tasks, Folders, Projects, Spaces, Users, Custom fields, comments, dependencies, and supported Attachments. OAuth 2.0 is the main application authentication model, with access-token authentication available for controlled use cases. Wrike webhooks provide notifications for configured resources and selected events, while the Events API supports incremental polling and reconciliation. Selected operations can use bulk or asynchronous job processing. Martini can consume these endpoints, expose an API for webhook intake, schedule synchronization workflows, map Wrike JSON, persist cursors and identifiers, and apply validation, retry, and business rules.
| Integration point | Supported by Wrike? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Wrike’s versioned REST API is the principal mechanism for reading and managing Tasks, Folders, Projects, Spaces, Users, Custom fields, comments, dependencies, and supported Attachments. It can support both initial loads and ongoing synchronization. | Martini workflows can consume Wrike REST endpoints, map JSON responses, paginate through collections, apply business rules, and write normalized data to downstream applications or databases. |
| Webhooks / outbound callbacks | Yes | Wrike webhooks notify external endpoints about changes in configured resources and selected event types. Coverage is resource- and event-specific and should not be assumed for every Wrike object or field. | Martini can expose a REST API endpoint for webhook intake, validate and normalize notifications, retrieve the authoritative Wrike resource, and route the result through a workflow. |
| Events API and incremental synchronization | Yes | Wrike’s Events API can retrieve changes after a known point, supporting polling-based incremental synchronization and reconciliation when webhook delivery is delayed, duplicated, or missed. | Martini can schedule event-polling workflows, persist event cursors or timestamps, process changes transactionally, and advance the checkpoint only after successful downstream processing. |
| Bulk and asynchronous operations | Limited | Selected Wrike operations support bulk-oriented processing or return job-style responses that complete asynchronously. Coverage is endpoint-specific rather than universal. | Martini can inspect job responses, poll for completion with timeouts and retry handling, and use bounded workflow concurrency for bulk-oriented operations. |
| File and attachment APIs | Yes | Wrike provides attachment operations for files associated with supported resources. These can support document handoff, metadata capture, and transfers to systems such as SharePoint or Google Drive. | Martini can retrieve attachment metadata and content, enforce file and security rules, transform metadata, and orchestrate uploads to another system. |
| Authentication | Yes | Wrike documents OAuth 2.0 for third-party applications and access-token authentication for controlled API use cases. Authorization determines which account resources the integration identity can access. | Martini can keep client credentials, access tokens, refresh information, endpoint configuration, and environment-specific values in secure configuration and secrets. |
How Wrike exposes data and business events
Wrike REST APIs
Wrike’s versioned REST API is the primary interface for accessing and managing work-management resources. It supports operations involving Tasks, Folders, Projects, Spaces, Users, Custom fields, comments, dependencies, and supported Attachments, subject to endpoint-specific permissions and behavior.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to Wrike, retrieves or changes the required resource, handles pagination and response validation, maps Wrike JSON to the target model, and records identifiers and processing status for reliable synchronization.
Implementation sequence
Wrike Webhooks
Wrike webhooks provide outbound notifications for configured resources and selected change events. Notifications may contain identifiers rather than a complete current object, and coverage is not universal across all Wrike resources or fields.
Martini implementation pattern
Martini implementation pattern: expose a Martini REST API endpoint, validate the incoming request, identify the affected Wrike resource, retrieve its authoritative current representation through the REST API, and process the normalized result. Duplicate, out-of-order, and unsupported notifications are handled through idempotency and reconciliation logic.
Implementation sequence
Wrike Events API
Wrike’s Events API supports retrieving changes after a known cursor or timestamp. It can be used for incremental synchronization and as a reconciliation mechanism for webhook-driven designs.
Martini implementation pattern
Martini implementation pattern: schedule a workflow to retrieve changes from the saved event position, process each event with follow-up REST lookups when required, and persist the next cursor only after downstream processing succeeds. Periodic reconciliation can identify missed or inconsistent changes.
Implementation sequence
Wrike asynchronous operations
Selected Wrike operations can use bulk-oriented processing or return job-style responses. An accepted request may therefore indicate that processing has started rather than that the requested change is complete.
Martini implementation pattern
Martini implementation pattern: submit the operation, inspect the returned job information, poll the job status with bounded retries and a timeout, and route failed or expired jobs to an operational error path. Workflow concurrency should remain controlled to respect service limits.
Implementation sequence
Wrike Attachments
Wrike provides attachment operations for files associated with supported work-management resources. File transfers require endpoint-specific validation for authorization, multipart behavior, size, content type, and download or upload semantics.
Martini implementation pattern
Martini implementation pattern: retrieve attachment metadata and content when permitted, validate naming, type, size, and security rules, transfer the file to the destination, and persist source identifiers and transfer outcomes for duplicate detection and recovery.
Implementation sequence
Common Wrike integration patterns
Pattern 1: Sync Salesforce opportunities to Wrike Projects
When to use this pattern
Use this pattern when sales or implementation teams need approved Salesforce opportunities to create delivery work in Wrike. The flow can create or update a Wrike Project and related Tasks, then return selected project progress to Salesforce.
Integration direction
Example Mapping
| Wrike Field | Canonical Field | Target Field |
|---|---|---|
| Opportunity.Id | externalOpportunityId | Custom field or integration key |
| Opportunity.Name | projectName | Project title |
| CloseDate | plannedStartDate | Project start date |
| OwnerId | deliveryOwner | Project owner or Task assignee |
Martini implementation pattern
Martini consumes approved opportunity changes, validates stage and required customer data, checks the stored Salesforce-to-Wrike key before creating anything, and upserts the Wrike Project and Tasks. It stores both identifiers, applies status and ownership mappings, and sends failures to a retryable error path rather than creating duplicates.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secure configuration
- error handling
Pattern 2: Sync Wrike Tasks to ServiceNow work
When to use this pattern
Use this pattern when ServiceNow incidents, requests, or changes require coordinated project work in Wrike and the originating service record needs completion visibility.
Integration direction
Example Mapping
| Wrike Field | Canonical Field | Target Field |
|---|---|---|
| ServiceNow.number | sourceWorkItemNumber | Task Custom field |
| ServiceNow.short_description | taskTitle | Task title |
| ServiceNow.due_date | dueDate | Task due date |
| ServiceNow.assignment_group | deliveryGroup | Task Custom field or routing rule |
Martini implementation pattern
A Martini workflow filters approved ServiceNow records, resolves the Wrike user and destination Folder or Project, creates or updates the Task, and stores the Wrike Task ID in ServiceNow. A second workflow receives supported Wrike notifications, retrieves the current Task, maps completion or status information, and updates ServiceNow with idempotent processing.
Martini capabilities used
- API consumption
- webhook receiving
- workflows
- data mapping
- validation
- idempotency
- retry handling
Pattern 3: Publish Wrike project reporting data
When to use this pattern
Use this pattern when executives or operations teams need normalized Wrike Projects, Tasks, statuses, dates, owners, and Custom fields in a reporting store or analytics delivery process.
Integration direction
Example Mapping
| Wrike Field | Canonical Field | Target Field |
|---|---|---|
| Project.id | sourceProjectId | project_id |
| Project.status | projectStatus | status |
| Task.assigneeId | assignedUserId | assignee_id |
| Custom field value | businessAttribute | custom_attribute |
Martini implementation pattern
Martini performs an initial paginated load and then uses Events API polling or scheduled reconciliation for changes. It normalizes nested Wrike structures, resolves Users and Custom fields, upserts rows using stable Wrike identifiers, and advances checkpoints only after successful database writes.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- SQL connectivity
- checkpoint management
- monitoring
Pattern 4: Transfer approved Wrike Attachments
When to use this pattern
Use this pattern when approved documents associated with Wrike Tasks or Projects must be transferred to a governed document store such as Microsoft SharePoint or Google Drive.
Integration direction
Example Mapping
| Wrike Field | Canonical Field | Target Field |
|---|---|---|
| Attachment.id | sourceFileId | external file identifier |
| Attachment.name | fileName | document name |
| Task.id | sourceTaskId | source task metadata |
| Project.name | projectName | library metadata |
Martini implementation pattern
Martini identifies eligible Attachments from a webhook, scheduled query, or approved Task state, retrieves the file where authorized, validates content and naming rules, and uploads it to the target library. It records source and destination IDs, detects duplicate files, and routes permission, size, or transfer failures for controlled retry.
Martini capabilities used
- workflows
- API consumption
- file handling
- data mapping
- business rules
- error handling
- audit logging
Applications commonly integrated with Wrike
Wrike can be integrated with adjacent enterprise applications when organizations need to coordinate work management with sales, service, collaboration, document, development, or reporting processes. The following patterns are conservative architecture examples based on Wrike’s role as a work-management platform; each application’s API, event, file, and authentication capabilities should be validated for the selected implementation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Create Wrike Projects or Tasks from sales opportunities, accounts, or implementation work and return project progress to Salesforce. | Salesforce → Martini → Wrike | Martini consumes Salesforce changes or scheduled records, maps opportunity and delivery data to Wrike Projects and Tasks, retains cross-system identifiers, and can process selected Wrike status events back into Salesforce through a separate workflow. |
| Jira | Coordinate software-development work in Jira with cross-functional delivery projects and milestones managed in Wrike. | Wrike → Martini → Jira | Martini retrieves or receives selected Wrike changes, applies project and task filtering, maps statuses and ownership to Jira fields, and uses identifiers and idempotency rules to avoid duplicate issue creation. |
| ServiceNow | Convert approved incidents, requests, or changes into Wrike work and return completion or project status to the originating ServiceNow record. | ServiceNow → Martini → Wrike | A Martini workflow consumes ServiceNow records, validates approval and routing rules, creates or updates Wrike Tasks, stores the Wrike ID in ServiceNow, and processes selected Wrike notifications to update the source record. |
| Microsoft Teams | Surface selected Wrike task or project updates in collaboration channels and provide users with links to relevant work items. | Wrike → Martini → Microsoft Teams | Martini receives supported Wrike notifications, enriches them with current Task or Project details, formats a Teams message through the selected Teams interface, and applies filtering to control channel noise. |
| Slack | Notify teams about Wrike assignments, milestones, or selected project events in collaboration channels. | Wrike → Martini → Slack | A Martini API receives Wrike webhook requests, retrieves the authoritative resource where necessary, maps the event to a channel and message format, and sends only approved event types to Slack. |
| Microsoft SharePoint | Transfer Wrike Attachments or approved project documents into governed SharePoint document libraries with mapped metadata. | Wrike → Martini → Microsoft SharePoint | Martini retrieves supported Wrike attachment metadata and content, validates file type and size rules, transfers the file to the selected SharePoint location, and records the source identifiers and transfer status. |
| Google Drive | Store or retrieve project-related files associated with Wrike Tasks and Projects while preserving document metadata and ownership rules. | Wrike → Martini → Google Drive | A Martini workflow retrieves eligible Wrike Attachments, applies duplicate and naming policies, uploads content and metadata to Google Drive, and routes authorization or transfer failures for retry. |
| Tableau | Publish normalized Wrike Projects, Tasks, statuses, dates, owners, and Custom fields for executive and operational reporting. | Wrike → Martini → Tableau | Scheduled Martini workflows use paginated REST retrieval and incremental Events API processing, normalize Wrike data into a reporting model, write it to an intermediary data service where required, and expose or deliver the prepared dataset to Tableau. |
How to build a Wrike integration in Martini
Objective
Establish Wrike application authorization and environment-specific configuration without embedding credentials in workflow logic.
Instructions in Martini
- Register or configure the Wrike application required for the integration
- Use OAuth 2.0 for application authorization or an approved access token for controlled use cases
- Store client credentials, tokens, refresh information, and endpoint values in Martini secrets or secure configuration
- Use an integration identity with only the Wrike permissions required by the workflows
Objective
Select the trigger that matches latency, reliability, and volume requirements for the synchronization.
Instructions in Martini
- Use a Martini API endpoint to receive supported Wrike webhook notifications
- Use a scheduled workflow for initial loads, Events API polling, or reconciliation
- Combine webhooks with scheduled reconciliation when downstream consistency is important
- Define how deletions, archival, and unsupported event coverage will be detected
Objective
Obtain the authoritative Wrike resource and any related data required for a complete business decision.
Instructions in Martini
- Validate the incoming event or scheduled cursor
- Retrieve the current Task, Project, Folder, User, Custom field, or Attachment through the Wrike REST API
- Handle pagination for collection endpoints
- Inspect asynchronous job responses and poll until completion when required
Objective
Coordinate Wrike calls, enrichment, target-system calls, and state management in a maintainable Martini workflow.
Instructions in Martini
- Separate intake, enrichment, transformation, delivery, and error paths where useful
- Persist Wrike IDs, external IDs, event identifiers, cursors, and processing status
- Use bounded concurrency and avoid uncontrolled parallel API loops
- Apply timeouts and explicit handling for deleted or inaccessible resources
Objective
Transform Wrike JSON and organization-specific Custom fields into a stable canonical or target-specific model.
Instructions in Martini
- Map Tasks, Projects, Users, statuses, dates, owners, and Custom fields explicitly
- Prefer stable Wrike field identifiers over display labels when available
- Validate required values, allowed statuses, ownership, file types, and business keys
- Route unknown fields or invalid values for review rather than silently discarding them
Objective
Create or update downstream objects while preserving relationships and preventing duplicate work.
Instructions in Martini
- Use stored cross-system identifiers for idempotent upsert behavior
- Apply business rules before creating Tasks, Projects, reporting rows, or files
- Write target data and source identifiers together where the target supports it
- Advance event or synchronization checkpoints only after successful downstream processing
Common Wrike data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Tasks | Synchronize work items, statuses, dates, assignees, descriptions, dependencies, Custom fields, and completion information. | Salesforce, ServiceNow, Jira, Slack, Microsoft Teams, reporting databases | Martini retrieves or receives change notifications, looks up the current Task when required, maps fields to a canonical work-item model, and performs idempotent create or update operations. |
| Folders | Represent organizational containers and support hierarchy-aware synchronization and routing. | Reporting databases, Jira, Salesforce, ServiceNow | Martini loads Folder identifiers and hierarchy relationships, caches stable reference data where appropriate, and uses the hierarchy to determine target project or work-item placement. |
| Projects | Synchronize project ownership, dates, statuses, milestones, Tasks, and delivery progress. | Salesforce, ServiceNow, Tableau, reporting databases, Microsoft Teams | Martini maps Projects to target project or delivery models, enriches them with selected Tasks and Custom fields, and applies upsert and reconciliation rules. |
| Spaces | Group higher-level Wrike work areas and provide account structure for filtering and access-aware synchronization. | Reporting databases, data services, governance stores | Martini can retrieve Spaces as reference data, use them to scope synchronization, and avoid assuming that an authenticated user can access every Space. |
| Users | Represent assignees, owners, participants, and other people associated with Wrike work. | Salesforce, ServiceNow, Jira, identity-aware reporting stores | Martini maps Wrike user identifiers to target identities, caches stable user reference data where suitable, and handles unresolved users through validation or exception paths. |
| Custom fields | Carry organization-specific classifications, statuses, business identifiers, and reporting attributes. | Salesforce, ServiceNow, Tableau, SQL databases | Martini maps stable Custom field identifiers and allowed values rather than relying only on display labels, logs unknown fields, and applies explicit transformation rules. |
Authentication and security considerations
Authentication and authorization
Wrike documents OAuth 2.0 as the primary application authorization model. Access tokens are then used for API requests, and controlled internal use cases may use access-token authentication directly.
- Store Wrike client credentials, access tokens, refresh information, webhook secrets, and endpoint configuration in Martini secrets or secure environment configuration.
- Use a dedicated integration identity with the minimum permissions required for the selected Spaces, Folders, Projects, Tasks, Users, and Attachments.
- Account authorization does not guarantee visibility of every Wrike resource; resource access depends on the authorized user and Wrike permissions.
- Handle token expiration and refresh behavior explicitly for OAuth-based workflows.
Operational considerations for Wrike integrations
Reliability and scale
Wrike integrations should account for API limits, pagination, resource-specific webhook coverage, and asynchronous job responses. Martini workflows should use bounded concurrency, respect rate-limit responses, and apply retry policies with backoff.
State and idempotency
Persist Wrike IDs, external identifiers, event identifiers, hashes, and synchronization cursors. Advance an Events API cursor only after downstream processing succeeds, and use periodic reconciliation to detect missed or inconsistent changes.
Schema and file handling
Custom fields, statuses, user identifiers, and hierarchy relationships can change. Map stable identifiers where available and route unknown values for review. Attachment transfers require explicit rules for permissions, content types, file sizes, duplicate names, scanning, retention, and deletion.
Testing and monitoring
Test initial loads, pagination boundaries, duplicate and out-of-order events, deleted resources, expired tokens, failed asynchronous jobs, inaccessible objects, and target-system outages. Monitor workflow logs, retry queues, cursor progress, and reconciliation results.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Point-to-point scripts often combine authentication, pagination, mapping, retries, and business rules in code that is difficult to govern. Martini provides workflows and APIs for coordinating Wrike with enterprise applications, databases, files, and messaging systems.
Reusable integration assets
Martini can separate Wrike API consumption, webhook intake, data mapping, validation, and target delivery into reusable integration logic. This supports multiple consumers without exposing Wrike-specific payloads everywhere.
Operational control
Martini can persist checkpoints and identifiers, apply idempotency and retry policies, handle asynchronous jobs, and provide monitoring and error paths for long-running synchronization processes.
Adaptable implementation
When Custom fields, target schemas, or business rules differ between organizations, Martini supports explicit transformations and custom logic where needed rather than forcing every integration into a fixed point-to-point design.
Frequently asked questions
Wrike can be integrated through its versioned REST API, OAuth 2.0 or access-token authentication, webhooks for configured resources and selected events, the Events API for incremental synchronization, selected bulk or asynchronous operations, and attachment endpoints. Enterprise workflows typically combine API retrieval with webhook notifications and scheduled reconciliation.
Yes. Martini can consume the Wrike REST API, expose an API endpoint for supported Wrike webhook notifications, run scheduled Events API synchronization, map Wrike JSON to external models, handle asynchronous jobs, and orchestrate attachment transfers. No native Martini Wrike connector is documented in the supplied material.
No. A dedicated Wrike connector is not required. Martini can integrate using Wrike’s native REST API, OAuth 2.0 or access-token authentication, supported webhooks, Events API, asynchronous operations, and attachment endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Wrike. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Wrike, cloud infrastructure, or other third-party systems according to their subscriptions, usage, and deployment models.
The Wrike REST API should be the primary integration method. Use OAuth 2.0 for application authorization, webhooks for supported low-latency notifications, and the Events API or scheduled workflows for incremental processing and reconciliation. Selected bulk, asynchronous, and attachment endpoints can be added where the specific use case requires them.
Yes, but webhook coverage is limited to configured resources and selected event types. A webhook may identify a changed resource without containing every current field, so Martini should retrieve the authoritative object through the REST API. The Events API and scheduled reconciliation can recover from missed, delayed, duplicated, or out-of-order notifications.
Martini can map Wrike Tasks, Projects, Users, statuses, dates, Custom fields, and Attachments into canonical or target-specific models. Workflows can apply validation, bounded retries with backoff, rate-limit handling, asynchronous job polling, and idempotency based on Wrike IDs, external IDs, event identifiers, or business keys.
Yes. Martini can expose a controlled REST API that accepts enterprise requests, applies authentication and business rules, and orchestrates calls to Wrike’s REST API. This can shield consumers from Wrike-specific payloads while providing a stable enterprise-facing contract. Wrike GraphQL and SOAP APIs were not confirmed for this research.
Related Martini documentation
APIs
Workflows
Data
Plan your Wrike integration with Martini
Use Martini to connect Wrike’s REST API, webhooks, Events API, and attachment endpoints with the applications and data services that support your enterprise workflows.