.png)
Intapp Integration Guide
Integrate Intapp product APIs with enterprise applications through REST workflows and product-specific event notifications.
Intapp integration options at a glance
Intapp integrations are product-specific, with REST APIs serving as the principal mechanism for working with products such as DealCloud, Intapp Time, Intapp Conflicts, Intapp Documents, and Intapp Walls. Selected products may also provide webhook-style notifications, callbacks, or document and file operations, but coverage must be confirmed for the relevant tenant and object model. Authentication commonly involves OAuth 2.0 and bearer tokens, although product-specific credentials may apply. Martini can consume the applicable APIs, receive supported notifications, transform product-specific payloads, apply business rules, maintain synchronization checkpoints, and expose normalized APIs for downstream applications.
| Integration point | Supported by Intapp? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | REST is the principal Intapp integration mechanism for reading and updating product-specific objects such as DealCloud Companies, Contacts, Opportunities, and Activities or Intapp Time Matters and Time Entries. | Martini can consume Intapp REST endpoints, configure authentication, map request and response payloads, apply validation and business rules, and expose a separate normalized API. |
| Webhooks and outbound callbacks | Limited | Selected Intapp products may provide outbound notifications for selected objects or lifecycle events. Coverage, payload completeness, signatures, retries, and event identifiers must be confirmed per product. | Martini can expose a receiving API or webhook workflow, record event identifiers, retrieve the authoritative Intapp object, and process duplicate or failed notifications safely. |
| File and attachment APIs | Limited | Intapp Documents and related products may expose document or file operations, including metadata, versions, references, uploads, or downloads, but universal portfolio coverage is not confirmed. | Martini can orchestrate supported file or metadata requests, transform document references, apply access rules, and route large or sensitive payloads according to the selected API constraints. |
| Authentication | Yes | Authentication is product-specific and may use OAuth 2.0, bearer access tokens, API credentials, or API keys. Scopes, tenant permissions, and administrator approval vary by product. | Martini can store client secrets, refresh tokens, API keys, and tenant configuration in secured environment settings and use them in API workflows. |
| Bulk, asynchronous, or batch APIs | Not confirmed | Bulk or asynchronous processing is not confirmed across the Intapp portfolio and must be verified for the selected product before high-volume designs are adopted. | If the selected Intapp product provides bulk endpoints, Martini can submit jobs, poll status, retrieve results, checkpoint progress, and route item-level errors. |
| Database access | Not confirmed | Direct access to Intapp-managed production databases is not confirmed and should not be assumed as an integration method. | Martini should use supported Intapp APIs or documented exports rather than connecting directly to Intapp-managed databases. |
How Intapp exposes data and business events
Intapp REST APIs
REST is the principal Intapp integration mechanism, but the available endpoints and object models depend on the selected product and tenant. Representative use cases include DealCloud relationship data, Intapp Time entries and matters, conflict-related data, and product-specific document or access metadata.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the applicable Intapp API, retrieves or submits product-specific resources, validates and transforms the payload, applies business rules, and writes to the target application or returns a normalized response through a Martini API.
Implementation sequence
Intapp webhooks and callbacks
Some Intapp products provide outbound notifications for selected events, but event coverage is not portfolio-wide. The implementation must confirm supported objects, lifecycle events, payload completeness, delivery retries, signatures, event identifiers, and ordering behavior.
Martini implementation pattern
Martini implementation pattern: expose a controlled receiving API or webhook workflow, validate the notification where supported, record the event ID, retrieve the authoritative Intapp object, and process it asynchronously with duplicate detection and retry handling.
Implementation sequence
Intapp document and file operations
Document and file capabilities may be available in Intapp Documents or related products, but upload, download, multipart, versioning, permissions, and temporary URL behavior must be verified for the selected API.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the relevant Intapp product, retrieves permitted metadata or file references, applies access and data-minimization rules, and transfers or exposes only the content allowed by the product contract.
Implementation sequence
Common Intapp integration patterns
Pattern 1: Synchronize DealCloud relationships to a CRM
When to use this pattern
Use this pattern when Companies, Contacts, Opportunities, or Activities in DealCloud need to remain aligned with a downstream CRM. A scheduled or product-supported event-driven flow can process changes while preserving Intapp identifiers and relationship references.
Integration direction
Example Mapping
| Intapp Field | Canonical Field | Target Field |
|---|---|---|
| Company ID | externalAccountId | External Account ID |
| Company Name | accountName | Account Name |
| Opportunity Stage | opportunityStage | Stage |
| Last Modified | sourceModifiedAt | Source Modified At |
Martini implementation pattern
A Martini workflow retrieves changed DealCloud objects, paginates results, applies an overlap window to the checkpoint, normalizes relationships, and upserts Salesforce records. Business rules can map stages and ownership, while rejected records, rate limits, and transient failures are handled separately from permanent validation errors.
Martini capabilities used
- Scheduling
- API consumption
- Data mapping
- Checkpoint management
- Business rules
- Idempotent upserts
- Error handling
Pattern 2: Export approved Intapp Time entries to finance
When to use this pattern
Use this pattern when approved Intapp Time entries must be transferred to NetSuite, Aderant, or another finance platform for billing or posting. The workflow should validate references and prevent duplicate financial transactions.
Integration direction
Example Mapping
| Intapp Field | Canonical Field | Target Field |
|---|---|---|
| Time Entry ID | sourceTimeEntryId | External ID |
| Matter ID | matterReference | Project or Matter |
| Timekeeper ID | workerReference | Employee |
| Billable Hours | billableQuantity | Quantity |
Martini implementation pattern
Martini retrieves entries filtered by approval or billing status, validates matter and timekeeper mappings, applies rounding and billing rules, and submits idempotent writes to NetSuite. The workflow records posting results, retries transient responses with backoff, and routes unmapped or rejected entries for review.
Martini capabilities used
- Scheduled workflows
- API orchestration
- Validation
- Data transformation
- Business rules
- Idempotency
- Retry handling
Pattern 3: Submit conflict-check requests and synchronize status
When to use this pattern
Use this pattern when a source application needs a controlled interface for submitting matter or conflict-check requests to Intapp Conflicts and receiving normalized status information. Product-specific write and event capabilities must be confirmed first.
Integration direction
Example Mapping
| Intapp Field | Canonical Field | Target Field |
|---|---|---|
| Matter Name | matterName | Matter Name |
| Party Name | partyName | Party Name |
| Request Reference | correlationId | External Reference |
| Conflict Status | reviewStatus | Normalized Status |
Martini implementation pattern
Martini exposes an API that validates the incoming request, transforms it to the Intapp Conflicts model, and submits it through the supported API. If status notifications are available, Martini receives them, retrieves the authoritative result, maps product-specific statuses, and returns or publishes a normalized response with correlation and retry handling.
Martini capabilities used
- API exposure
- API consumption
- Validation
- Data mapping
- Status normalization
- Correlation IDs
- Error handling
Pattern 4: Synchronize Intapp document or access metadata
When to use this pattern
Use this pattern when another enterprise application needs controlled access to Intapp Documents or Walls metadata, document references, or access status without receiving Intapp credentials directly. Actual file transfer and permission behavior must be verified for the selected product.
Integration direction
Example Mapping
| Intapp Field | Canonical Field | Target Field |
|---|---|---|
| Workspace ID | workspaceReference | Workspace Reference |
| Document ID | documentReference | Document Reference |
| Access Rule | accessDecision | Access Decision |
| Document Version | versionReference | Version |
Martini implementation pattern
A Martini API receives a lookup or synchronization request, authenticates to the relevant Intapp product, retrieves permitted metadata or a file reference, applies authorization and minimization rules, and returns a controlled response. Errors such as permission failures, unavailable versions, and transient API failures are classified and logged without exposing sensitive content.
Martini capabilities used
- API exposure
- Secure API consumption
- Authorization rules
- Data transformation
- Sensitive-data handling
- Structured logging
- Error handling
Applications commonly integrated with Intapp
Intapp is a portfolio of product-specific platforms, so adjacent application integrations depend on the selected product, tenant, object model, and available API operations. The following are common or plausible enterprise architecture patterns that should be validated against the applicable Intapp documentation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize DealCloud Companies, Contacts, Opportunities, Activities, and relationship data with sales and account processes in Salesforce. | Intapp → Martini → Salesforce | Martini can retrieve changed Intapp objects, normalize identifiers and relationship fields, apply ownership and validation rules, and upsert Salesforce records with checkpointing, retry handling, and duplicate prevention. |
| Microsoft Dynamics 365 | Exchange account, contact, opportunity, and activity information between Intapp relationship or deal-management processes and Dynamics 365. | Intapp → Martini → Microsoft Dynamics 365 | A Martini workflow can orchestrate product-specific Intapp REST calls and Dynamics 365 API operations, map the two object models, route validation failures, and record correlation identifiers for subsequent updates. |
| Microsoft 365 | Connect user, collaboration, calendar, email, or document context with Intapp workflows where the selected products expose compatible APIs. | Microsoft 365 → Martini → Intapp | Martini can receive or retrieve Microsoft 365 data, apply authorization and data-minimization rules, transform it to the selected Intapp product schema, and return selected status or metadata to Microsoft 365 processes. |
| iManage | Synchronize matters, workspaces, documents, and metadata with Intapp Documents, Conflicts, or Walls processes where the relevant product APIs support the required operations. | Intapp → Martini → iManage | Martini can coordinate metadata lookups and permitted file references, preserve external identifiers, enforce access rules, and handle product-specific document and version behavior without exposing Intapp credentials to iManage consumers. |
| Aderant | Exchange client, matter, time, billing, and financial data with Intapp Time or conflict-management workflows. | Aderant → Martini → Intapp | A scheduled Martini workflow can validate and transform matter and time data, submit supported Intapp API requests, apply billing rules, and return processing results while isolating rejected items for review. |
| NetSuite | Send approved Intapp Time, billing, matter, or financial data to NetSuite and return posting statuses to the originating process. | Intapp → Martini → NetSuite | Martini can retrieve approved Intapp objects, map matter and timekeeper identifiers to NetSuite dimensions, use idempotency controls for financial writes, and retry transient failures without duplicating postings. |
| Workday | Exchange worker, organization, project, approval, or time-related data with Intapp professional-services processes. | Workday → Martini → Intapp | Martini can orchestrate Workday and Intapp API calls, transform worker and organization references, apply approval rules, and maintain a durable checkpoint for recurring synchronization. |
| DocuSign | Coordinate document or engagement workflows and return signature status to an Intapp process where the selected product supports the required integration points. | Intapp → Martini → DocuSign | Martini can submit controlled document metadata or workflow requests, receive supported DocuSign status callbacks, correlate them to Intapp identifiers, and update the relevant process with retry and audit handling. |
How to build a Intapp integration in Martini
Objective
Identify the exact Intapp product, tenant, region, API version, object model, and permissions before configuring the integration.
Instructions in Martini
- Confirm the selected Intapp product and supported API operations
- Create or obtain the required integration identity and permissions
- Store OAuth credentials, tokens, API keys, tenant identifiers, and endpoints in Martini secured environment configuration
- Test authentication separately from business requests
Objective
Select a trigger that matches the product's capabilities and synchronization requirements.
Instructions in Martini
- Use a Martini scheduler for recurring API synchronization
- Use a Martini receiving API or webhook workflow only when the selected Intapp product supports outbound notifications
- Define event correlation, duplicate handling, and checkpoint behavior
Objective
Read authoritative Intapp resources while respecting pagination, filtering, rate limits, and product-specific object relationships.
Instructions in Martini
- Call the applicable Intapp REST endpoint
- Implement the documented pagination and updated-since behavior
- Use stable identifiers and an overlap window for incremental synchronization
- Retrieve the current resource after notification events when the event payload is incomplete
Objective
Coordinate the Intapp request, transformation, target write, and operational state as one maintainable Martini workflow.
Instructions in Martini
- Separate transport, mapping, business rules, and target-write stages
- Use correlation identifiers for each source object or event
- Branch validation failures and authorization failures from transient service errors
- Persist checkpoints and processing outcomes
Objective
Translate the selected Intapp product schema into a canonical or target model without assuming that objects are consistent across the Intapp portfolio.
Instructions in Martini
- Map actual product-specific objects such as Companies, Opportunities, Matters, or Time Entries
- Validate required fields, enumerations, relationships, and timestamps
- Apply normalization, enrichment, and product-specific business rules
- Quarantine unknown or invalid values for review
Objective
Create or update downstream objects safely and return a controlled result when Martini exposes an API façade.
Instructions in Martini
- Use external identifiers and idempotency controls where supported
- Upsert target records rather than creating duplicates on retry
- Return normalized status and correlation information to callers
- Record item-level success and rejection outcomes
Common Intapp data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Companies | DealCloud organization and relationship data used for account synchronization and reporting. | Salesforce, Microsoft Dynamics 365, data services | Martini retrieves changed Companies through the applicable Intapp API, maps identifiers and attributes to a canonical account model, and upserts the target with checkpoint and duplicate controls. |
| Contacts | DealCloud person and relationship information used by sales, client, or relationship-management processes. | Salesforce, Microsoft Dynamics 365, Microsoft 365 | Martini validates required identity fields, normalizes ownership and organization references, and routes incomplete or conflicting Contacts for review. |
| Opportunities | DealCloud opportunity and pipeline data used for downstream sales, reporting, or financial workflows. | Salesforce, Microsoft Dynamics 365, analytics platforms | Martini maps stages, values, dates, and related Companies, applies business rules, and performs idempotent upserts using stable Intapp identifiers. |
| Matters | Intapp Time, Intapp Conflicts, Intapp Documents, or Intapp Walls matter information used in professional-services and risk workflows. | Aderant, NetSuite, iManage, case-management applications | Martini treats Matters as product-specific objects, confirms field and relationship semantics, and synchronizes only the operations and permissions supported by the selected API. |
| Time Entries | Intapp Time work and billing entries used for approval, financial processing, billing, and reporting. | NetSuite, Aderant, finance platforms | Martini retrieves approved entries, validates matter and timekeeper references, applies billing or rounding rules, and uses idempotency keys or external mappings to prevent duplicate postings. |
Authentication and security considerations
Product-specific authentication
Intapp authentication varies by product, tenant, and API surface. OAuth 2.0 and bearer access tokens should be evaluated for modern APIs, while API credentials or API keys may apply to particular products or legacy surfaces.
Credential protection
Store client secrets, refresh tokens, API keys, tenant identifiers, and regional endpoints in Martini secrets or secured environment configuration rather than workflow definitions.
Least privilege
- Use a dedicated integration identity with only the scopes, roles, and object permissions required.
- Confirm administrator consent, token lifetime, refresh behavior, and tenant restrictions.
- Do not log access tokens or sensitive document, legal, financial, client, or personnel data.
Operational considerations for Intapp integrations
Rate limits and pagination
Confirm product-specific request limits, concurrency restrictions, page sizes, cursor or offset behavior, and incremental filtering. Use controlled concurrency and durable checkpoints for recurring synchronization.
Reliability and idempotency
Separate authentication, permission, validation, throttling, duplicate, and transient service failures. Retry transient responses with backoff and use stable Intapp identifiers or supported idempotency keys to avoid duplicate writes.
Events and schema changes
For notifications, validate event identifiers and signatures when provided, retrieve the authoritative resource when necessary, and handle duplicates or out-of-order delivery. Treat product-specific fields, enumerations, relationships, and status values as versioned data.
Testing and observability
Test against the selected product and tenant with representative permissions and data. Use correlation IDs, structured logs, checkpoint records, workflow error handling, and operational monitoring while minimizing sensitive payload capture.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Scripts and point-to-point integrations often duplicate authentication, mapping, retries, and monitoring logic. Martini provides a maintainable workflow layer for coordinating Intapp APIs, downstream applications, business rules, and operational state.
Reusable integration assets
Martini can expose normalized APIs and reusable workflow logic so downstream applications do not need to understand every product-specific Intapp schema or credential model.
Operational control
- Apply consistent validation, transformation, checkpointing, idempotency, and retry behavior.
- Separate transient failures from permanent data or permission errors.
- Manage product-specific secrets and environment configuration without embedding credentials in workflows.
Frequently asked questions
Intapp can be integrated through the REST APIs provided by the relevant Intapp product. Selected products may also provide webhook-style notifications, callbacks, or document and file operations. Because Intapp is a product portfolio, the exact objects, endpoints, authentication, permissions, and event coverage must be verified for the selected product and tenant.
Yes. Martini can integrate with Intapp by consuming the applicable Intapp REST APIs and, where supported, receiving product-specific webhook or callback notifications. Martini can orchestrate workflows, map and transform product data, apply business rules, and expose normalized APIs to downstream applications.
No. A dedicated Intapp connector is not required. Martini can use Intapp's confirmed native REST APIs, supported webhook or callback mechanisms, authentication methods, and product-specific file interfaces through API-consuming and workflow capabilities.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Intapp. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Intapp, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the principal method to evaluate for current Intapp integrations. Webhook-style notifications and callbacks can be used when the selected product supports the required event type. File or document operations may be available in selected products. GraphQL and SOAP were not confirmed as general Intapp integration methods.
Some Intapp products provide outbound notifications for selected events, but coverage is product- and event-specific. Confirm the supported objects, lifecycle events, payload completeness, signatures, event identifiers, retries, ordering, and replay behavior before designing an event-driven integration.
Martini can run scheduled workflows that call Intapp APIs, paginate through results, apply updated-time filters where available, and maintain durable checkpoints with an overlap window. Stable Intapp identifiers, external mappings, and idempotent target writes help prevent missed changes and duplicates.
Yes. Martini can expose a controlled API that hides product-specific Intapp schemas from downstream consumers. The API can authenticate and call Intapp, validate and transform requests, apply authorization and business rules, and return normalized responses while centralizing error handling and observability.
Related Martini documentation
Workflows
Build a maintainable Intapp integration
Use Martini to connect Intapp product APIs with enterprise applications through secure workflows, controlled APIs, data transformation, and operational error handling.