.png)
iManage Integration Guide
Integrate iManage Work with enterprise systems through its REST APIs, document-content operations, OAuth 2.0-style authentication, and selected webhook notifications.
iManage integration options at a glance
iManage Work’s primary integration surface is its REST API, which supports workspace, folder, document, document version, user, metadata, search, upload, and download operations. Selected iManage events can produce webhook-style notifications, although coverage, delivery behavior, and payloads depend on the deployment. OAuth 2.0-style bearer-token authentication protects API access, with permissions applied across users, libraries, workspaces, folders, and documents. Martini can consume these APIs, receive selected notifications through an exposed endpoint, stream document transfers, map JSON and metadata, and coordinate scheduled, paginated, checkpointed synchronization workflows.
| Integration point | Supported by iManage? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | The iManage Work REST API is the primary integration surface for finding and retrieving Workspaces, Folders, Documents, Users, metadata, and search results, as well as creating or updating permitted metadata and performing content operations. | Martini can consume the REST API from workflows, map JSON responses, apply business rules, expose reusable APIs, and persist checkpoints for reliable synchronization. |
| Webhooks / outbound callbacks | Limited | iManage provides webhook-style notifications for selected iManage Work events. Coverage, payload completeness, delivery guarantees, retry behavior, and subscriptions depend on the deployment. | Martini can expose an HTTP endpoint, validate and deduplicate notifications, retrieve the affected iManage object, and route the resulting event through a workflow. |
| File / document APIs | Yes | iManage Work supports downloading document content, uploading new documents, creating document versions, and reading or updating document profiles and metadata. | Martini can orchestrate streamed or controlled document transfers, validate file and metadata requirements, map profiles, and record document and version identifiers. |
| Authentication | Yes | API access uses OAuth 2.0-style bearer tokens, with application registration, client credentials or related configuration, and permissions controlling access to libraries, workspaces, folders, and documents. | Martini can store client secrets, tokens, and environment-specific endpoints in protected configuration and attach bearer authentication to API requests. |
| Scheduled synchronization | Yes | Large or non-event-driven synchronizations can use paginated REST requests, search filters, modification markers, version checks, and persisted checkpoints where supported by the endpoint. | Martini schedulers and workflows can coordinate incremental retrieval, bounded concurrency, checkpoint persistence, and restartable processing. |
| Bulk / asynchronous / batch APIs | Not confirmed | A generally available iManage Work bulk or asynchronous API was not confirmed. Large transfers should use paginated, rate-aware REST workflows unless the target deployment documents another option. | Martini can implement controlled sequential or parallel requests, pagination, checkpoints, throttling backoff, and resumable workflow processing without assuming a bulk API. |
| GraphQL APIs | Not confirmed | No official iManage GraphQL API was confirmed. REST should be evaluated for new iManage Work integrations. | Martini can consume REST endpoints and should not design the integration around GraphQL unless the target environment separately confirms support. |
| SOAP APIs | Not confirmed | No current iManage Work SOAP integration surface was confirmed as a recommended mechanism. REST should be preferred for new integrations. | Martini can support SOAP generally, but an iManage integration should use the confirmed REST and notification mechanisms instead. |
| Database / analytics access | No | Direct access to the iManage Work database is not a standard or recommended integration approach. | Martini should use supported iManage APIs and documented notifications rather than connecting to internal product databases. |
How iManage exposes data and business events
iManage REST APIs
The iManage Work REST API is the main integration mechanism for retrieving and searching Workspaces, Folders, Documents, Users, Libraries, profiles, metadata, and document content. It also supports permitted metadata updates, document creation, and version operations.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with an OAuth 2.0-style bearer token, calls the required iManage endpoints, follows pagination, maps the response into a canonical model, applies business rules, and writes the result to a target system. Checkpoints and stable object identifiers support restartable synchronization.
Implementation sequence
iManage Webhook Notifications
iManage provides webhook-style notifications for selected iManage Work events. Notifications are not universal, and a payload may identify a changed object without containing its complete current representation.
Martini implementation pattern
Martini implementation pattern: expose a secured API endpoint, validate and deduplicate the notification, acknowledge it appropriately, and retrieve current iManage state asynchronously through the REST API. The workflow then routes approved changes to downstream systems and records the processing result.
Implementation sequence
iManage Document APIs
Document-content operations are central to iManage Work integration. The API supports downloading content, uploading documents, creating versions, and reading or updating document profiles and metadata where permissions allow.
Martini implementation pattern
Martini implementation pattern: accept or retrieve an approved document, validate its workspace, folder, profile, and size, transfer content using documented API behavior, and store the resulting iManage document and version identifiers. Large files should be streamed or handled with controlled temporary storage.
Implementation sequence
OAuth 2.0-style Authentication
iManage API requests use bearer access tokens obtained through an iManage application and environment-specific authorization configuration. Exact grants, token lifetimes, scopes, and approvals can vary by deployment.
Martini implementation pattern
Martini implementation pattern: keep client credentials, tokens, and environment endpoints in protected configuration, obtain or refresh tokens as required, and attach bearer authentication to API calls. Workflows should also respect permissions enforced for the authenticated user and application.
Implementation sequence
Common iManage integration patterns
Pattern 1: Synchronize iManage Workspaces to a business application
When to use this pattern
Use this pattern when Salesforce, Microsoft Dynamics 365, ServiceNow, or another business application needs current matter or project context from iManage Work. A scheduled workflow is appropriate where notification coverage does not include every workspace change.
Integration direction
Example Mapping
| iManage Field | Canonical Field | Target Field |
|---|---|---|
| workspace_id | matter.externalId | Salesforce Matter iManage ID |
| name | matter.name | Salesforce Matter Name |
| matter_number | matter.reference | Salesforce Matter Number |
| status | matter.status | Salesforce Matter Status |
Martini implementation pattern
A Martini scheduler starts a paginated REST workflow, applies a modified-date or checkpoint filter where supported, maps workspace metadata, and upserts the target record using the iManage library and workspace identifiers. Permission failures and transient responses are separated from data errors, with checkpoints committed only after successful target updates.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination and checkpoints
- data mapping
- business rules
- error handling
Pattern 2: File business documents into iManage
When to use this pattern
Use this pattern when an application generates a contract, invoice, case document, or other approved file that must be stored in an iManage Workspace and Folder with the correct profile and security context.
Integration direction
Example Mapping
| iManage Field | Canonical Field | Target Field |
|---|---|---|
| attachment.content | document.content | iManage document content |
| case_number | document.sourceReference | iManage custom metadata |
| workspace_id | document.workspaceId | iManage Workspace ID |
| file_name | document.name | iManage Document Name |
Martini implementation pattern
The source application invokes a Martini API with content and metadata. Martini validates the workspace, folder, profile, file size, and idempotency key, then uploads a new iManage Document or creates a Document version. The workflow returns the resulting identifiers and places recoverable failures into a retry path rather than creating uncontrolled duplicates.
Martini capabilities used
- exposed APIs
- workflow orchestration
- file handling
- data validation
- data mapping
- idempotency
- error handling
Pattern 3: Route selected iManage events to enterprise workflows
When to use this pattern
Use this pattern for selected iManage Work events where webhook-style notifications are available and downstream systems need timely document, workspace, or version updates. It should not be used as the sole mechanism for detecting every iManage change.
Integration direction
Example Mapping
| iManage Field | Canonical Field | Target Field |
|---|---|---|
| event_type | change.type | ServiceNow update type |
| object_id | change.externalId | ServiceNow iManage Object ID |
| document_version | change.version | ServiceNow Document Version |
| workspace_id | change.workspaceId | ServiceNow Matter Reference |
Martini implementation pattern
Martini receives the notification, validates and deduplicates it, and immediately records a processing key. A workflow then retrieves current iManage state through REST, checks workspace and document security rules, and updates ServiceNow only when the event and current state meet routing criteria. Retries use the recorded key to avoid duplicate updates.
Martini capabilities used
- API exposure
- webhook receiving
- workflow orchestration
- deduplication
- API consumption
- business rules
- retry handling
Pattern 4: Export controlled iManage documents for review
When to use this pattern
Use this pattern when approved documents and metadata must be transferred from a defined iManage library, Workspace, or Folder scope to DocuSign, Microsoft SharePoint, or another authorized review process.
Integration direction
Example Mapping
| iManage Field | Canonical Field | Target Field |
|---|---|---|
| document_id | file.externalId | DocuSign source reference |
| document_version | file.version | DocuSign document version |
| profile.title | file.name | DocuSign document name |
| workspace_id | matter.externalId | DocuSign envelope metadata |
Martini implementation pattern
A Martini workflow retrieves an allowlisted set of iManage documents and profiles, checks access and version rules, and transfers content to the approved target. It records the source identifiers, applies file-size and temporary-storage controls, and uses idempotency keys to prevent repeated exports or unintended document duplication.
Martini capabilities used
- scheduled workflows
- API consumption
- file transfer
- data mapping
- allowlists
- business rules
- monitoring and error handling
Applications commonly integrated with iManage
iManage Work can be integrated with adjacent enterprise applications to connect governed document management with matter, customer, workflow, transaction, signature, and collaboration processes. These are architecture patterns rather than claims of packaged native integrations; endpoint availability, permissions, and product-specific capabilities should be validated for each environment.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Associate clients, matters, opportunities, and case-related records with iManage workspaces and documents. | Salesforce → Martini → iManage | Expose a Martini API for filing requests, validate the workspace and document profile, upload content or create a version in iManage, and return the document identifier and link. Scheduled or event-driven workflows can synchronize selected iManage metadata back to Salesforce. |
| Microsoft Dynamics 365 | Connect customer, account, and legal matter information with controlled document storage in iManage. | Microsoft Dynamics 365 → Martini → iManage | Use a Martini workflow to transform Dynamics records into iManage workspace or document metadata, apply permission and matter validation, and persist cross-system identifiers for later updates and document links. |
| ServiceNow | Link incidents, requests, legal records, and compliance activities to governed iManage documents and workspace content. | ServiceNow → Martini → iManage | Receive filing requests or selected iManage notifications through Martini APIs, retrieve current iManage state when needed, map document links and status fields, and use retryable workflows for updates in either system. |
| NetSuite | Associate client, vendor, contract, and transaction records with controlled iManage documents. | NetSuite → Martini → iManage | Orchestrate NetSuite-to-iManage filing through a Martini API or scheduled workflow, validate library and workspace scope, transfer document content, and return the iManage document and version identifiers to NetSuite. |
| Microsoft SharePoint | Support controlled content migration, publishing, or document-reference exchange between repositories. | Microsoft SharePoint → Martini → iManage | Run a bounded, checkpointed Martini workflow that reads approved SharePoint content or iManage documents, maps metadata, applies security and retention rules, transfers files in controlled batches, and records source-to-target identifiers. |
| DocuSign | Send iManage documents for signature and return completed agreements or signature status metadata. | iManage → Martini → DocuSign | Retrieve an approved iManage document and metadata, create a signature-package request through the DocuSign API, monitor completion, and file the completed document or a new iManage version with its status and audit references. |
| Jira | Associate project or issue work with governed iManage documents and document links. | Jira → Martini → iManage | Use Martini to accept Jira filing requests, create or update iManage documents, and synchronize selected document links or status notifications back to Jira with deduplication and permission checks. |
| Workday | Store selected employee, contract, policy, or HR-related documents under controlled access in iManage. | Workday → Martini → iManage | Transfer only approved document types through a secured Martini workflow, externalize tenant configuration and secrets, apply data-residency and access rules, and maintain references rather than unnecessary content copies. |
How to build a iManage integration in Martini
Objective
Establish secure access to the target iManage environment and confirm that the application identity has the required library, workspace, folder, document, and user permissions.
Instructions in Martini
- Register or identify the iManage application configuration.
- Store client credentials, tokens, and environment endpoints in Martini secrets or protected configuration.
- Configure OAuth 2.0-style bearer-token authentication.
- Test access using the least-privilege identity intended for the workflow.
Objective
Select a trigger that matches the integration requirement and the confirmed iManage capability, recognizing that webhook coverage is limited to selected events.
Instructions in Martini
- Use an iManage notification endpoint for selected event-driven flows.
- Use a scheduler for workspace, document, or version synchronization where event coverage is incomplete.
- Define the library, workspace, folder, and object scope explicitly.
- Choose a checkpoint or replay strategy before processing data.
Objective
Retrieve current iManage state through the REST API rather than assuming that a notification contains a complete object representation.
Instructions in Martini
- Call the required Work API endpoint after authentication.
- Follow pagination and documented continuation parameters.
- Use modification or version filters where the endpoint supports them.
- Retrieve document content only when the workflow requires it.
Objective
Coordinate validation, retrieval, transformation, target updates, checkpointing, and recovery as a maintainable Martini workflow.
Instructions in Martini
- Separate notification receipt from longer-running retrieval and downstream processing when appropriate.
- Apply workspace, library, folder, permission, and file-size checks.
- Route transient failures to controlled retries and permanent validation failures to an operational error path.
- Persist progress only after the relevant target operation succeeds.
Objective
Transform iManage JSON, profiles, custom metadata, document identifiers, and version information into a canonical model for the target application.
Instructions in Martini
- Map actual iManage objects such as Workspaces, Documents, Folders, Users, Libraries, and document versions.
- Preserve stable library, workspace, document, and version identifiers.
- Handle optional or tenant-specific metadata without assuming every field is present.
- Avoid writing document content or secrets to ordinary logs.
Objective
Apply business and security rules before creating, updating, transferring, or exposing iManage content.
Instructions in Martini
- Validate that the target library, workspace, and folder are approved.
- Determine whether a repeat request creates a document, creates a new version, updates metadata, or is ignored.
- Enforce downstream content, retention, residency, and access policies.
- Use idempotency keys and durable cross-system references.
Common iManage data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Workspaces | Matter- or project-oriented containers used to organize documents and related information. | Salesforce, Microsoft Dynamics 365, ServiceNow, NetSuite, Jira | Martini retrieves paginated workspace data, maps matter numbers, names, status, and custom metadata, then creates or updates target records idempotently while retaining library and workspace identifiers. |
| Documents | Managed files stored in iManage Work, including document profiles and metadata. | Microsoft SharePoint, DocuSign, Salesforce, ServiceNow, NetSuite | Martini can retrieve metadata or content, validate destination rules, upload or download files, transfer document links, and record cross-system identifiers without exposing content in logs. |
| Document versions | Individual revisions of an iManage Document used to track changes and preserve document history. | DocuSign, Microsoft SharePoint, Salesforce, ServiceNow | Martini includes version identifiers in synchronization keys, determines whether a request creates a new version or updates metadata, and prevents duplicate processing through durable references. |
| Folders | Hierarchical containers within Workspaces used to organize documents. | Microsoft SharePoint, Salesforce, ServiceNow, Jira | Martini validates library, workspace, and folder scope before filing, maps folder paths or identifiers, and routes documents to approved destinations. |
| Users | iManage identities that can own, access, or act on documents and workspaces. | Salesforce, ServiceNow, Microsoft Dynamics 365, Workday | Martini can retrieve user information where permitted and use it for ownership, attribution, routing, or reconciliation without bypassing iManage security controls. |
| Libraries | Logical or administrative repositories in which Workspaces and Documents are managed. | Salesforce, Microsoft SharePoint, ServiceNow, enterprise data stores | Martini keeps library scope in configuration and checkpoints, applies library-specific mappings and allowlists, and uses it as part of idempotency and security validation. |
Authentication and security considerations
OAuth 2.0-style access
iManage Work API access is based on bearer access tokens associated with an iManage application and environment-specific authorization configuration. Exact grants, token lifetimes, scopes, and approval requirements can vary by deployment.
Permissions and least privilege
Effective access depends on the authenticated identity and iManage permissions across libraries, workspaces, folders, documents, users, and applications. Use a least-privilege identity and do not assume that a technically valid request is authorized.
Secret protection
- Store client secrets, refresh tokens, access tokens, and environment endpoints in protected Martini secrets or configuration.
- Use TLS for API calls and avoid logging bearer tokens or document content.
- Consider retention, residency, temporary-file cleanup, and audit requirements before copying documents downstream.
Operational considerations for iManage integrations
Pagination and checkpoints
List and search operations should be designed for pagination. Persist the last successful timestamp, cursor, document identifier, version, and scope as appropriate so long-running workflows can resume safely.
Throttling and retries
Applicable rate limits depend on the iManage deployment. Use bounded concurrency, controlled retries, and backoff for throttling and transient failures. Separate authorization, validation, and permission failures from recoverable transport errors.
Idempotency and versions
Document identifiers alone may not detect new versions. Include version information in synchronization keys and define whether repeated uploads update metadata, create a new version, or are ignored.
Notifications and schema changes
Webhook delivery may be partial, unordered, or incomplete. Validate and deduplicate notifications, retrieve current state through REST, and test mappings against each target library, tenant, API version, and custom metadata configuration.
Large files
Use documented upload and download behavior, streaming or controlled temporary storage, file-size limits, cleanup procedures, and audit-safe logging for large or sensitive documents.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Martini separates triggers, API calls, mappings, business rules, document transfers, checkpoints, and error paths into maintainable workflows. This is useful when iManage must coordinate with several business applications or when notification coverage is incomplete.
Reusable integration assets
Martini can expose controlled APIs and reusable workflow logic for filing, retrieval, metadata synchronization, and event processing without requiring point-to-point implementations for every source and target.
Reliable operations
- Use scheduled and event-driven workflows according to the iManage capability available for each process.
- Centralize authentication, validation, transformation, idempotency, retries, and monitoring.
- Keep environment endpoints, secrets, mappings, and operational rules configurable as deployments change.
Frequently asked questions
iManage Work can be integrated primarily through its REST API for Workspaces, Folders, Documents, document versions, Users, Libraries, metadata, search, uploads, and downloads. Selected iManage events can also produce webhook-style notifications. OAuth 2.0-style bearer-token authentication, pagination, checkpoints, and permission-aware workflows support reliable enterprise synchronization.
Yes. Martini can consume the iManage Work REST API, receive selected iManage webhook-style notifications through an exposed API, transfer document content, map metadata, orchestrate workflows, and handle retries and checkpoints. No native Martini iManage connector was verified in the supplied information.
No. A dedicated iManage connector is not required. Martini can integrate using iManage’s confirmed REST APIs, OAuth 2.0-style authentication, document-content operations, scheduled workflows, and selected webhook-style notifications.
Lonti does not charge an additional per-connector or per-vendor fee to integrate iManage. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from iManage, infrastructure, storage providers, or other third-party systems depending on subscriptions, usage, and deployment model.
REST APIs should be the default mechanism for new iManage Work integrations. Use document-content APIs for uploads and downloads, selected webhook-style notifications for supported events, and scheduled, paginated, checkpointed REST workflows for changes that are not covered by notifications. GraphQL and current SOAP APIs were not confirmed.
Martini can receive iManage webhook-style notifications for selected iManage Work events through an exposed endpoint. Coverage is partial, and payloads may require a follow-up REST request. The integration should validate and deduplicate notifications and should not assume that every change or event is delivered.
Use durable cross-references containing the iManage library, workspace, document, and version identifiers together with the source-system identifier. Workflows should apply idempotency rules that distinguish creating a document, creating a new version, updating metadata, and ignoring a repeated request. Checkpoints should be committed only after successful processing.
Yes. Martini can expose a controlled API that accepts filing, retrieval, or metadata requests from business applications and then orchestrates the corresponding iManage REST operations. The façade can centralize authentication, validation, workspace and folder rules, mappings, idempotency, document transfer, and error handling.
Related Martini documentation
APIs
Transformation
Operations
Connect iManage Work with your enterprise systems
Use Martini to build secure, maintainable iManage Work integrations for document filing, workspace synchronization, event-driven workflows, and controlled content transfer.