.png)
Icertis Integration Guide
Icertis integrates contract lifecycle data, documents, obligations, and events through REST APIs, configurable notifications, asynchronous exchanges, and OAuth 2.0.
Icertis integration options at a glance
Icertis provides REST-oriented APIs for creating, retrieving, updating, searching, and processing contract lifecycle data, subject to tenant configuration and permissions. Its integration surface includes Contracts, Parties, Clauses, Obligations, Contract Templates, and Documents. Icertis also supports event and notification patterns for selected objects or lifecycle events, along with bulk, import, export, and asynchronous processing for larger exchanges. Document APIs support contract files and versions. OAuth 2.0 is the expected authentication model. Martini can consume these APIs, receive supported notifications, orchestrate asynchronous jobs, map and transform payloads, schedule reconciliation workflows, and expose controlled APIs to downstream systems.
| Integration point | Supported by Icertis? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Create, retrieve, update, search, and process Contracts, Parties, Clauses, Obligations, Contract Templates, Documents, and related lifecycle data, subject to tenant configuration. | Martini can consume Icertis REST APIs in workflows, map request and response payloads, apply validation and business rules, and expose normalized APIs to downstream systems. |
| Webhooks and outbound callbacks | Limited | Event and notification patterns can initiate processing for selected contract or lifecycle events, but event coverage and delivery behavior depend on tenant and object configuration. | Martini can receive webhook-style HTTP requests, validate notifications, retrieve authoritative Icertis data, deduplicate events, and route failures for retry or review. |
| Bulk and asynchronous processing | Limited | Import, export, and larger-volume exchanges can support contract data migration or high-volume synchronization; operations may return a job or batch identifier. | Martini can submit the operation, store the job identifier, poll for completion, retrieve rejected records, and persist a restartable checkpoint. |
| File and document APIs | Yes | Exchange contract documents and document versions while preserving identifiers, filenames, MIME types, and related metadata. | Martini can retrieve and transfer binary or encoded content, apply file validation, preserve version information, and handle document-upload retries with idempotency controls. |
| Authentication | Yes | Authenticate API clients through OAuth 2.0, with tenant-specific client registration, scopes, roles, token URLs, and token lifetimes. | Martini can store client credentials and tokens in secrets or environment configuration and keep credentials out of payloads and logs. |
| Scheduled synchronization | Yes | Poll Icertis APIs for changed Contracts, Obligations, Parties, Documents, or lifecycle data when a required event notification is unavailable or reconciliation is needed. | Martini scheduler-triggered workflows can use modification-time, status, identifier, or other documented filters, handle pagination, and persist durable checkpoints. |
| GraphQL APIs | Not confirmed | No official Icertis GraphQL API was confirmed for new integrations. | Martini should use the confirmed Icertis REST APIs or documented event mechanisms rather than assume GraphQL availability. |
| SOAP APIs | Not confirmed | No current official Icertis SOAP integration surface was confirmed. | Martini should use Icertis REST APIs or supported event mechanisms unless a tenant explicitly exposes another documented interface. |
How Icertis exposes data and business events
Icertis REST APIs
Icertis REST-oriented APIs provide the primary integration surface for contract lifecycle data and platform operations. The available resources, fields, permissions, and API versions can vary by tenant and enabled modules.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with OAuth 2.0, calls the required Icertis resource, handles pagination and response validation, maps the result to a canonical or downstream model, and records correlation and checkpoint information.
Implementation sequence
Icertis event notifications
Icertis supports event and notification-based integration patterns for selected objects and lifecycle events. Coverage, delivery behavior, and whether the payload contains full data or only an identifier must be confirmed for the target tenant.
Martini implementation pattern
Martini implementation pattern: an API endpoint or webhook workflow receives the notification, validates its authenticity and structure, deduplicates it, retrieves the current Contract or related object when necessary, and routes the resulting business event to downstream systems.
Implementation sequence
Icertis bulk and asynchronous processing
Icertis supports larger-volume import, export, and exchange patterns, some of which may execute asynchronously. The operation-specific response and job-status behavior are tenant- and endpoint-dependent.
Martini implementation pattern
Martini implementation pattern: a workflow initiates the operation, stores the returned job or batch identifier, polls for completion at a controlled interval, retrieves processing results, and routes rejected records without losing the restart point.
Implementation sequence
Icertis document APIs
Documents are central Icertis objects and can be exchanged through document or contract APIs. Integrations must account for content encoding, MIME types, file sizes, and document versioning.
Martini implementation pattern
Martini implementation pattern: a workflow retrieves the requested Document and its metadata, validates content and version state, transfers it to an approved destination, and records the source and destination identifiers for idempotent retries.
Implementation sequence
Scheduled Icertis synchronization
Scheduled polling is appropriate when a required event is unavailable or when reconciliation is needed. Filters based on modification time, status, identifiers, or other documented change markers should be preferred.
Martini implementation pattern
Martini implementation pattern: a scheduler starts the workflow, the workflow reads a durable checkpoint, retrieves changed Icertis data with an overlap window where appropriate, deduplicates stable identifiers, and advances the checkpoint only after successful processing.
Implementation sequence
Common Icertis integration patterns
Pattern 1: Synchronize supplier contracts to procurement systems
When to use this pattern
Use this pattern when procurement or ERP applications need current Icertis Contracts, Parties, lifecycle statuses, and effective dates. Scheduled retrieval is suitable when event coverage is unavailable or when a regular reconciliation process is required.
Integration direction
Example Mapping
| Icertis Field | Canonical Field | Target Field |
|---|---|---|
| Contract.contractId | contract.externalId | External Contract ID |
| Contract.status | contract.lifecycleStatus | Contract Status |
| Contract.effectiveDate | contract.startDate | Valid From |
| Party.partyId | party.externalId | Supplier External ID |
Martini implementation pattern
A scheduler-triggered Martini workflow reads the last checkpoint, retrieves changed Contracts and Parties through the Icertis REST API, follows pagination, and normalizes tenant-specific values. It validates supplier identifiers, maps lifecycle states to the procurement model, upserts by external identifier, and uses an overlap window, retry handling, and an error route for failed records.
Martini capabilities used
- workflow scheduling
- API consumption
- pagination handling
- data mapping
- business rules
- checkpointing
- error handling
Pattern 2: Route contract lifecycle events to business workflows
When to use this pattern
Use this pattern when selected Icertis approval, signature, activation, or expiration events should initiate downstream notifications or work items. Event availability must be verified for the specific Icertis tenant and object.
Integration direction
Example Mapping
| Icertis Field | Canonical Field | Target Field |
|---|---|---|
| event.eventId | event.id | Correlation ID |
| Contract.contractId | contract.externalId | Contract Reference |
| Contract.status | contract.lifecycleStatus | Task State |
| Contract.expirationDate | contract.dueDate | Task Due Date |
Martini implementation pattern
Martini receives the notification, validates the event, checks the event or contract-version state for duplicates, and retrieves the full Contract when the event is only a reference. Business rules route selected lifecycle states to ServiceNow, while transient failures are retried and unrecoverable validation failures are recorded for review.
Martini capabilities used
- webhook receiving
- event validation
- API orchestration
- deduplication
- business rules
- retry handling
- workflow monitoring
Pattern 3: Synchronize obligations and renewal actions
When to use this pattern
Use this pattern when legal, procurement, or service-management teams need actionable visibility into Obligations, renewal dates, owners, and statuses from Icertis.
Integration direction
Example Mapping
| Icertis Field | Canonical Field | Target Field |
|---|---|---|
| Obligation.obligationId | obligation.externalId | Obligation ID |
| Obligation.dueDate | obligation.dueDate | Renewal Date |
| Obligation.status | obligation.status | Task Status |
| Contract.contractId | contract.externalId | Contract ID |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Obligations and related Contracts, applies rules for due-soon, overdue, and high-risk items, and upserts actionable records in Salesforce. It persists the obligation identifier and due-date combination to avoid duplicate notifications and reconciles closed or modified obligations on later runs.
Martini capabilities used
- scheduled workflows
- REST API consumption
- data enrichment
- conditional routing
- idempotency
- checkpointing
- error handling
Pattern 4: Distribute executed contract documents
When to use this pattern
Use this pattern when approved or executed Icertis Documents must be archived or made available in a controlled repository such as Microsoft SharePoint.
Integration direction
Example Mapping
| Icertis Field | Canonical Field | Target Field |
|---|---|---|
| Document.documentId | document.externalId | Source Document ID |
| Document.version | document.version | Document Version |
| Document.fileName | document.fileName | File Name |
| Document.mimeType | document.contentType | Content Type |
Martini implementation pattern
A notification or scheduled workflow identifies an eligible Contract and retrieves its current Document version. Martini validates lifecycle state and content metadata, transfers binary or encoded content to SharePoint, and stores a source-version correlation key so retries do not create duplicate archives or overwrite an executed document with a draft.
Martini capabilities used
- event or scheduler triggers
- file handling
- API consumption
- metadata mapping
- validation
- idempotency
- retry handling
Applications commonly integrated with Icertis
Icertis commonly participates in enterprise contract, procurement, sales, legal, and document-management architectures. The following named applications represent realistic integration targets; exact objects, direction, and availability depend on the Icertis tenant and the connected application's configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Synchronize supplier and purchasing context with Icertis contract status, effective dates, and approved contract documents. | SAP S/4HANA → Martini → Icertis | Martini can consume supplier and purchasing data from SAP S/4HANA, map it to Icertis Contracts and Parties, then return contract status or document references through a separate workflow. Checkpoints, validation, retries, and correlation identifiers support reliable bidirectional exchange. |
| Oracle Fusion Cloud Procurement | Connect supplier and procurement processes with Icertis contract records, obligations, and approved documents. | Oracle Fusion Cloud Procurement → Martini → Icertis | A Martini workflow can receive procurement context, transform supplier and purchasing fields, and invoke Icertis REST APIs. A scheduled reconciliation flow can bring contract status, obligation dates, and document references back to Oracle Fusion Cloud Procurement. |
| Salesforce | Make account, opportunity, customer, and executed-contract information available across sales and legal processes. | Salesforce → Martini → Icertis | Martini can use Salesforce events or scheduled retrieval as the initiating mechanism, validate the commercial context, and create or update Icertis Contracts and Parties. Icertis lifecycle status and approved document references can then be returned to Salesforce with duplicate protection. |
| Microsoft Dynamics 365 | Synchronize customer, supplier, sales, and contract lifecycle information between commercial processes and Icertis. | Microsoft Dynamics 365 → Martini → Icertis | Martini can normalize Dynamics 365 payloads into Icertis API requests and expose a controlled response or callback for contract status. Business rules can distinguish draft, executed, active, amended, and expired contract states. |
| ServiceNow | Send obligation, renewal, approval, and contract-related work into service-management workflows. | Icertis → Martini → ServiceNow | Martini can receive selected Icertis notifications or poll Obligations and Contracts, apply due-date and risk rules, and create or update ServiceNow work items. Processing identifiers and state checkpoints prevent duplicate tasks and support reconciliation. |
| Workday | Coordinate supplier, worker, or organizational reference data used in contracting and return relevant contract status where applicable. | Workday → Martini → Icertis | A scheduled Martini workflow can retrieve approved Workday reference data, map it to Icertis Parties or contract metadata, and selectively return Icertis lifecycle information. Optional-field handling and tenant-specific validation are important for this inferred use case. |
| DocuSign | Exchange agreements and signature status between contract approval processes and electronic-signature workflows. | Icertis → Martini → DocuSign | Martini can retrieve an approved Icertis Document, send the required content and metadata to DocuSign, and process signature-status notifications when supported by the configured solution. Contract and document identifiers provide correlation across retries. |
| Microsoft SharePoint | Publish or archive approved contract documents and metadata for controlled business access. | Icertis → Martini → Microsoft SharePoint | When a contract reaches a configured lifecycle state, Martini can retrieve the Icertis Document, preserve filename, MIME type, version, and classification metadata, and upload it to SharePoint. File validation and idempotent document-version handling reduce duplicate archives. |
How to build a Icertis integration in Martini
Objective
Establish tenant-specific Icertis connectivity using OAuth 2.0 and environment-specific API configuration.
Instructions in Martini
- Register or obtain the Icertis client credentials, token URL, scopes, and tenant API base URL.
- Store credentials, tokens, and endpoint configuration in Martini secrets or environment configuration.
- Confirm that the integration identity has only the roles and permissions required for its operations.
Objective
Select an event-driven, API-driven, or scheduled start based on the Icertis event coverage and synchronization objective.
Instructions in Martini
- Use a Martini API or webhook workflow for supported Icertis notifications.
- Use a scheduler when the required object event is unavailable or reconciliation is required.
- Define the event, modification-time, status, or identifier filter before retrieving data.
Objective
Call the relevant Icertis REST or document API and obtain authoritative object data.
Instructions in Martini
- Retrieve Contracts, Parties, Obligations, Documents, or related objects through confirmed endpoints.
- Handle pagination, continuation details, asynchronous job status, and document content requirements.
- Store correlation identifiers and checkpoints outside transient workflow payloads.
Objective
Coordinate retrieval, enrichment, validation, downstream calls, and state management in a maintainable Martini workflow.
Instructions in Martini
- Separate event intake, Icertis retrieval, transformation, target delivery, and error routes where appropriate.
- Retrieve full object details when an event contains only an identifier.
- Use reusable workflow logic for common authentication, correlation, and response handling.
Objective
Convert Icertis payloads and tenant-specific values into a canonical or downstream application model.
Instructions in Martini
- Map actual Icertis objects such as Contracts, Parties, Obligations, and Documents to target fields.
- Normalize dates, statuses, identifiers, MIME types, and document versions.
- Allow optional and custom fields to be absent without breaking core processing.
Objective
Enforce lifecycle, security, routing, and duplicate-prevention rules before writing to downstream systems.
Instructions in Martini
- Distinguish draft, executed, active, amended, and expired contract states.
- Route obligations based on due dates, status, ownership, or risk criteria.
- Use event identifiers, object versions, or external identifiers to prevent duplicate writes.
Common Icertis data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Contracts | Store contract identity, lifecycle status, dates, parties, and configured metadata for agreements. | SAP S/4HANA, Oracle Fusion Cloud Procurement, Salesforce, Microsoft Dynamics 365, ServiceNow | Martini retrieves or receives contract references, fetches authoritative details when required, maps lifecycle states, and uses stable identifiers and checkpoints for synchronization. |
| Contract Templates | Provide reusable structures for creating or standardizing contracts. | Salesforce, Microsoft Dynamics 365, SAP S/4HANA | Martini can map source business context to template-related API requests where supported and validate required tenant-specific fields before submission. |
| Clauses | Represent clause content and associated clause metadata within contracts. | Salesforce, Microsoft SharePoint, legal repositories | Martini can transform clause metadata for downstream search or governance processes while treating configurable fields and optional content defensively. |
| Obligations | Track post-signature or contractual commitments, owners, dates, and statuses. | ServiceNow, Salesforce, Microsoft Dynamics 365 | Martini can poll or process selected notifications, apply due-date and risk rules, create downstream work items, and reconcile changes by obligation identifier. |
| Documents | Store contract files, document content, and document versions. | Microsoft SharePoint, DocuSign, SAP S/4HANA, Salesforce | Martini preserves document identifiers, versions, filenames, MIME types, and contract relationships while transferring binary or encoded content with retry safeguards. |
| Parties | Represent organizations, suppliers, customers, and other participants associated with contracts. | SAP S/4HANA, Oracle Fusion Cloud Procurement, Workday, Salesforce | Martini normalizes party identifiers and attributes, validates required fields, and applies create-versus-update rules based on external identifiers. |
Authentication and security considerations
OAuth 2.0 and tenant configuration
Icertis API access commonly uses OAuth 2.0. Client registration, token URLs, scopes, token lifetimes, roles, permissions, API versions, and tenant base URLs must be confirmed with the Icertis administrator.
Protect contract information
Contracts and documents may contain confidential legal, commercial, personal, or pricing information. Store credentials and tokens in Martini secrets or environment configuration, use least-privilege access, and keep bearer tokens and document content out of general-purpose logs.
Control downstream access
When Martini exposes an API façade over Icertis, apply authentication, authorization, validation, and response filtering so callers receive only the contract data they are permitted to access.
Operational considerations for Icertis integrations
Throttling and pagination
Confirm tenant-specific rate limits, concurrency behavior, and throttling responses. Follow the documented page, offset, cursor, or continuation model rather than relying on a fixed page count, and use controlled parallelism with backoff.
Incremental synchronization
Use supported modification-time, status, identifier, or other change filters. Persist checkpoints outside transient workflow payloads, consider a short overlap window, and deduplicate stable Icertis identifiers.
Versions and idempotency
Distinguish contract identity from document version and draft from executed or active state. Use object identifiers, event identifiers, external correlation keys, and contract-version combinations to prevent duplicate writes and document uploads.
Events and asynchronous jobs
Confirm event coverage, delivery guarantees, ordering, replay behavior, and payload completeness. For bulk operations, store job identifiers, poll for completion, retrieve rejected records, and make restart behavior explicit.
Configuration and testing
Icertis fields, workflows, templates, lifecycle states, and API availability can be tenant-specific. Treat optional and custom fields defensively, validate enumerations, test API-version changes before deployment, and maintain scheduled reconciliation even when events are enabled.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate the full integration lifecycle
Martini coordinates authentication, Icertis API calls, event intake, pagination, asynchronous jobs, document handling, transformations, target-system writes, and reconciliation in maintainable workflows.
Separate business rules from transport
Rather than embedding contract logic in isolated scripts, Martini can apply reusable validation, lifecycle routing, obligation rules, duplicate prevention, and error paths across multiple Icertis integration flows.
Support controlled APIs and change
Martini can expose a controlled API façade over Icertis data and isolate downstream schemas from tenant-specific fields. Environment configuration, secrets, checkpoints, monitoring, and retry handling support operational reliability as Icertis implementations evolve.
Frequently asked questions
Icertis can be integrated through its REST-oriented APIs for Contracts, Parties, Clauses, Obligations, Contract Templates, Documents, and related lifecycle data. Selected event and notification patterns can support event-driven processing, while scheduled API retrieval, import, export, and asynchronous exchanges support reconciliation and larger-volume synchronization. OAuth 2.0 is the expected API authentication model.
Yes. Martini can integrate with Icertis by consuming its REST APIs, receiving supported event notifications or callbacks, running scheduled synchronization workflows, handling document exchanges, and exposing controlled APIs for downstream applications. Exact resources and event coverage depend on the Icertis tenant configuration.
No dedicated Icertis connector is required. Martini can use Icertis's confirmed native integration mechanisms, including REST APIs, OAuth 2.0, supported event notifications, scheduled retrieval, asynchronous exchanges, and document APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Icertis. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Icertis, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.
REST APIs are the primary recommended method for current Icertis integrations. Use event or notification mechanisms when the required object and lifecycle event are supported by the tenant, and use scheduled retrieval or bulk and asynchronous processing for reconciliation and larger exchanges. No official current GraphQL or SOAP surface was confirmed.
Icertis supports event and notification-based integration patterns, but coverage depends on the configured product, object, and lifecycle event. Do not assume that every Contract, Clause, Obligation, or Document change produces a callback. Martini can receive supported notifications and can poll the Icertis API when direct delivery is unavailable.
Martini can retrieve changed Icertis objects using supported modification, status, identifier, or other filters, follow pagination, map the data, and persist durable checkpoints. For Documents, it can preserve identifiers, versions, filenames, MIME types, metadata, and content while transferring binary or encoded files to an approved target.
Martini can separate authentication, permission, validation, throttling, temporary service, missing-object, and downstream failures into appropriate handling paths. Workflows can retry transient errors with backoff, use event identifiers or object-version combinations for idempotency, record checkpoints, and run reconciliation workflows to identify missed or incomplete processing.
Related Martini documentation
Icertis APIs
Transformation
Connect Icertis with your enterprise systems
Use Martini to implement reliable Icertis integrations across contract data, documents, obligations, lifecycle events, and downstream applications.