.png)
Agiloft Integration Guide
Integrate Agiloft contract and workflow data with enterprise applications through REST APIs, configured outbound calls, attachments, and workflow-based synchronization.
Agiloft integration options at a glance
Agiloft provides REST APIs for configured tables, records, related data, actions, and—where supported by the deployment—attachments. Session-based authentication and permission-controlled service accounts are relevant to API access, while exact resources, fields, pagination, and credentials depend on the Agiloft version and tenant configuration. Some deployments can initiate outbound calls through workflow rules or integration actions for selected events; this should not be treated as universal webhook coverage. SOAP may remain relevant for legacy integrations. Martini can orchestrate scheduled or event-driven workflows, maintain incremental checkpoints, map configurable Agiloft data models, transfer documents, and expose endpoints for callbacks.
| Integration point | Supported by Agiloft? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Query, create, and update configured Agiloft records; invoke available actions; retrieve related data; and support scheduled or on-demand synchronization. | Martini can consume the Agiloft REST API, authenticate a session, map payloads, orchestrate calls, and expose reusable API-led workflows. |
| SOAP APIs | Limited | Support existing Agiloft integrations or operations that are not available through the REST interface, subject to the target release. | Martini can consume SOAP services and handle XML mappings, but the Agiloft deployment’s current SOAP availability should be confirmed first. |
| Webhooks / outbound callbacks | Limited | Selected workflow rules or integration actions may initiate outbound calls for events such as record creation, updates, approvals, or status changes. | Martini can expose a REST endpoint, authenticate and validate callbacks, route the event, and persist processing results; polling is an alternative when coverage is incomplete. |
| File / attachment APIs | Limited | Retrieve contract documents and related attachments or upload generated and executed files where the relevant API version and object type support those operations. | Martini can separate metadata and binary-file processing, transfer attachments, preserve identifiers and checksums, and record transfer status. |
| Authentication | Limited | Session-based login, username and password, or deployment-specific API credentials may be used; permissions and roles govern table, field, action, and attachment access. | Martini can store credentials in environment-specific secrets, establish sessions in workflows, and use a least-privilege Agiloft service account. |
| Scheduled synchronization | Yes | Retrieve changed Contracts, Companies, Contacts, Tasks, or other configured tables using modification filters, pagination, and controlled batches. | Martini can schedule workflows, maintain watermarks and overlap windows, apply incremental filters, and retry transient requests. |
| Bulk / asynchronous APIs | Not confirmed | A general-purpose Agiloft bulk or asynchronous API was not confirmed; large transfers should use paginated requests and controlled batching unless deployment documentation verifies otherwise. | Martini can implement bounded pagination, checkpoints, batching, idempotent upserts, and reconciliation without assuming a bulk endpoint. |
| Database access | Not confirmed | Direct production database or analytics access was not confirmed as a standard Agiloft integration mechanism. | Martini should use Agiloft-supported APIs or configured exports rather than connecting directly to the underlying production database. |
How Agiloft exposes data and business events
Agiloft REST APIs
Agiloft REST APIs provide the primary integration mechanism for configured tables and records. Depending on the release and tenant configuration, operations can include authentication, queries, record creation and updates, related records, actions, and attachments. Resource paths, field identifiers, pagination, and payload structures are deployment-specific.
Martini implementation pattern
Martini implementation pattern: a workflow establishes an Agiloft API session, retrieves or writes the required resources, validates and transforms the response, applies business rules, and records identifiers and checkpoints. API definitions and mappings should be configured for the customer’s Agiloft version rather than assumed to be universal.
Implementation sequence
Agiloft outbound callbacks
Some Agiloft deployments can initiate outbound calls through workflow rules or integration actions for selected events, such as record changes, approvals, or status transitions. This is configurable behavior rather than universal webhook coverage, and payloads depend on the implementation.
Martini implementation pattern
Martini implementation pattern: expose a secured REST endpoint, validate the caller and payload, identify the Agiloft record and event, then route the callback into a workflow. If the required event is not configured or available, use scheduled incremental retrieval instead.
Implementation sequence
Agiloft SOAP services
Agiloft has historically supported SOAP-based web services. Current availability and recommended usage must be confirmed for the target release. SOAP is most relevant to existing integrations or operations unavailable through REST.
Martini implementation pattern
Martini implementation pattern: consume the required SOAP operation, manage XML request and response mappings, normalize the result into a canonical model, and reuse the same validation, routing, retry, and audit logic used by REST workflows.
Implementation sequence
Agiloft attachments
Agiloft manages documents and attachments associated with Contracts and other records. Upload and download behavior varies by API version and object type, so the required operations should be verified before implementation.
Martini implementation pattern
Martini implementation pattern: process contract metadata and binary content as related but separately observable steps. The workflow preserves source identifiers, records checksums or transfer status where available, and retries file operations without creating duplicate downstream files.
Implementation sequence
Common Agiloft integration patterns
Pattern 1: Synchronize Agiloft Contracts with Salesforce
When to use this pattern
Use this pattern when contract lifecycle status, renewal dates, company ownership, or opportunity references must remain aligned between Agiloft and Salesforce. A scheduled incremental flow is appropriate when outbound event coverage is not available for the required Contract changes.
Integration direction
Example Mapping
| Agiloft Field | Canonical Field | Target Field |
|---|---|---|
| Contract number | contract.externalKey | External contract ID |
| Lifecycle status | contract.status | Contract status |
| Renewal date | contract.renewalDate | Renewal date |
| Company | party.externalKey | Account external ID |
Martini implementation pattern
A scheduled Martini workflow queries modified Agiloft Contracts with pagination and an overlap window, resolves the related Company, maps status and dates, and upserts the Salesforce target using the Agiloft identifier. Validation rejects incomplete records, while checkpoints, retries, and correlation logging support safe reruns.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Exchange signed contract documents
When to use this pattern
Use this pattern when approved Agiloft Contracts must be sent to DocuSign or Adobe Acrobat Sign and completed documents and signature status must return to Agiloft. The exact attachment and trigger operations require tenant-specific confirmation.
Integration direction
Example Mapping
| Agiloft Field | Canonical Field | Target Field |
|---|---|---|
| Contract ID | contract.sourceId | External reference |
| Contract attachment | document.content | Envelope document |
| Signer Contact | signature.signer | Recipient |
| Signature status | signature.status | Agiloft lifecycle status |
Martini implementation pattern
Martini retrieves the approved Contract and attachment, creates or updates the signature envelope, and exposes a secured callback endpoint for completion notifications. A follow-up workflow downloads the executed file, updates Agiloft metadata and attachment status, and retries transient transfer failures while preventing duplicate envelopes.
Martini capabilities used
- workflows
- API consumption
- API exposure
- file handling
- data mapping
- deduplication
- error handling
Pattern 3: Synchronize Workday users for approval routing
When to use this pattern
Use this pattern when Agiloft approval ownership and access-related data depend on current worker, manager, department, or cost-center information from Workday. Limit synchronization to the attributes required by contract ownership and routing.
Integration direction
Example Mapping
| Agiloft Field | Canonical Field | Target Field |
|---|---|---|
| Worker ID | person.externalId | Agiloft user external ID |
| Worker name | person.displayName | User name |
| Manager ID | person.managerExternalId | Manager reference |
| Employment status | person.active | User active status |
Martini implementation pattern
A scheduled Martini workflow retrieves the required Workday population, validates organizational references, and upserts configured Agiloft Users, Contacts, or approval-related records. Business rules exclude unnecessary data, and failures are isolated by record so a malformed worker does not block the complete batch.
Martini capabilities used
- scheduling
- API consumption
- data mapping
- validation
- business rules
- batch processing
- error handling
Pattern 4: Coordinate Agiloft Tasks with ServiceNow
When to use this pattern
Use this pattern when Agiloft approval exceptions, remediation work, or integration failures need operational tracking in ServiceNow. Bidirectional status synchronization should use explicit mappings and stable external identifiers.
Integration direction
Example Mapping
| Agiloft Field | Canonical Field | Target Field |
|---|---|---|
| Task ID | workItem.sourceId | Correlation ID |
| Task description | workItem.summary | Short description |
| Task status | workItem.status | Incident or task state |
| Task owner | workItem.assignee | Assigned to |
Martini implementation pattern
Martini selects eligible Agiloft Tasks or failure records, creates or updates ServiceNow work items, and writes the external identifier back to Agiloft. Returned status changes are validated before updating the source Task, with duplicate detection, transient retries, and a dead-letter or operational review path for persistent failures.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- idempotency
- error handling
- monitoring
Applications commonly integrated with Agiloft
Agiloft can be integrated with adjacent business applications to coordinate contract intake, approvals, signatures, ownership, remediation, and financial or operational data. The exact direction and scope should be confirmed against the customer’s Agiloft configuration and API version.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Align contracts with accounts, opportunities, customer ownership, and renewal activity. | Salesforce → Martini → Agiloft | Use REST API workflows to receive intake or account references from Salesforce, retrieve or update Agiloft Contracts and Companies, and return contract status and renewal data. Store cross-system identifiers and apply idempotent create-or-update rules. |
| DocuSign | Send Agiloft contract documents for signature and return execution status and completed files. | Agiloft → Martini → DocuSign | Retrieve an approved Contract and attachment from Agiloft, create or update the DocuSign envelope, receive a completion callback through a Martini API, then write signature status and the executed document back to Agiloft. |
| Adobe Acrobat Sign | Coordinate electronic signatures for documents originating in Agiloft. | Agiloft → Martini → Adobe Acrobat Sign | Orchestrate document retrieval, agreement creation, callback validation, completed-document download, and Agiloft attachment updates in separate workflow stages with correlation identifiers and retry handling. |
| ServiceNow | Coordinate contract-related requests, incidents, approvals, and operational tasks. | Agiloft → Martini → ServiceNow | Create or update ServiceNow work items from Agiloft Tasks or integration failures, map source identifiers and status values, and write external issue references back to Agiloft for bidirectional tracking. |
| Jira | Track contract remediation, legal review, implementation, and integration tasks. | Agiloft → Martini → Jira | Use a Martini workflow to create Jira issues from selected Agiloft Tasks, apply routing rules based on task type and owner, and synchronize completion status while preventing duplicate issue creation. |
| Workday | Provide worker, organizational, and manager data for contract ownership, approval routing, and access control. | Workday → Martini → Agiloft | Run a scheduled workflow that retrieves the required Workday worker data, validates organizational mappings, and upserts Agiloft Contacts, Users, Companies, or approval-related records using stable source identifiers. |
| Microsoft Dynamics 365 | Connect customer, sales, and contract lifecycle information across commercial processes. | Microsoft Dynamics 365 → Martini → Agiloft | Map customer and sales references into Agiloft Companies and Contracts, synchronize lifecycle changes in the opposite direction where required, and use checkpoints, validation, and deterministic matching for repeatable updates. |
| NetSuite | Align supplier, customer, purchasing, and contract information with financial operations. | Agiloft → Martini → NetSuite | Transform Agiloft Companies and Contracts into NetSuite customer, vendor, or contract-related data, apply business rules for financial ownership, and retain both system identifiers for reconciliation. |
How to build a Agiloft integration in Martini
Objective
Establish access to the customer’s Agiloft tenant and confirm the API version, base URL, configured tables, fields, actions, and attachment operations.
Instructions in Martini
- Use HTTPS and the authentication flow documented for the Agiloft deployment.
- Store session credentials, API credentials, and target-system secrets in environment-specific Martini secrets.
- Use a dedicated least-privilege Agiloft service account.
Objective
Select an event-driven or scheduled initiation method based on the Agiloft events available in the tenant.
Instructions in Martini
- Use a Martini REST endpoint for configured Agiloft outbound calls.
- Use a scheduler when event coverage is incomplete or polling is more reliable.
- Define the source table, change filter, page size, and checkpoint strategy.
Objective
Obtain the current Agiloft record, related data, and attachments required for the business process.
Instructions in Martini
- Retrieve records using stable filters and pagination.
- Use modification timestamps, status filters, and a small overlap window for incremental synchronization.
- Fetch the current resource after receiving a callback when the notification contains only a reference.
Objective
Coordinate API calls, lookups, actions, target writes, and compensating steps as a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, target writes, and checkpoint persistence into clear stages.
- Route records according to contract status, task type, ownership, or other confirmed business rules.
- Use reusable workflow logic for common session, retry, and correlation behavior.
Objective
Convert configurable Agiloft tables and fields into canonical models and downstream application payloads.
Instructions in Martini
- Map Contracts, Companies, Contacts, Users, Tasks, and Documents according to the tenant configuration.
- Normalize dates, statuses, identifiers, relationships, and attachment metadata.
- Validate required fields and reject or quarantine records that cannot be safely transformed.
Objective
Create or update downstream records and return relevant identifiers or statuses to Agiloft.
Instructions in Martini
- Use deterministic matching and source identifiers to distinguish create from update operations.
- Write external IDs and processing status back to Agiloft when the configured fields and permissions allow it.
- Transfer binary attachments separately from metadata and preserve correlation information.
Common Agiloft data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Contracts | Synchronize contract metadata, lifecycle status, effective and renewal dates, owners, company references, and related documents. | Salesforce, Microsoft Dynamics 365, NetSuite, DocuSign, Adobe Acrobat Sign | Martini retrieves or receives configured Contract data, validates required fields, maps status and dates, preserves the Agiloft identifier, and coordinates attachment transfers separately. |
| Companies | Represent customers, suppliers, partners, or other organizations related to contracts and workflows. | Salesforce, Microsoft Dynamics 365, NetSuite, Workday | Martini matches Companies using stable identifiers and approved business keys, then applies create-or-update rules and relationship mapping. |
| Contacts | Represent people associated with companies, contracts, approvals, and signature processes. | Salesforce, Workday, Microsoft Dynamics 365, DocuSign | Martini maps identity and organization references, validates contact data, and routes only the fields required by the target process. |
| Users | Represent Agiloft users, approvers, administrators, and workflow participants. | Workday, Salesforce, Microsoft Dynamics 365 | Martini synchronizes selected identity, manager, department, and access-related attributes while respecting Agiloft permissions and data-minimization requirements. |
| Tasks | Track approval, review, renewal, obligation, remediation, and other workflow work. | ServiceNow, Jira, Salesforce | Martini routes selected Tasks to external work-management systems, maps status and ownership, links external identifiers, and prevents duplicate issue creation. |
| Documents and attachments | Store contract files, executed documents, and other files associated with Agiloft records. | DocuSign, Adobe Acrobat Sign, file repositories, Salesforce | Martini retrieves metadata and binary content through supported operations, transfers files with correlation and checksum data, and records completion or failure status. |
Authentication and security considerations
Authentication and access
Agiloft authentication depends on the deployment and API version. Session-based login and username/password credentials may be used, while deployment-specific API credentials or tokens should be confirmed rather than assumed. OAuth 2.0 was not confirmed as the general authentication method for the core Agiloft REST API.
- Use HTTPS for all API and callback traffic.
- Store credentials and session configuration in Martini environment-specific secrets.
- Use a dedicated Agiloft service account with minimum access to required tables, fields, actions, saved searches, and attachments.
- Protect contract content and attachment data in logs and apply data minimization.
Operational considerations for Agiloft integrations
Tenant and schema variability
Agiloft is highly configurable. Confirm the release, API version, table and field identifiers, relationships, workflow actions, attachment behavior, and required fields before mapping.
Pagination and reliability
- Use paginated retrieval, modification filters, stable ordering, watermarks, and overlap windows.
- Use bounded concurrency and exponential backoff for transient errors, including applicable 429 and 5xx responses.
- Classify authentication, permission, validation, conflict, missing-record, network, and attachment failures separately.
- Persist source identifiers, correlation IDs, checkpoints, retry state, and processing outcomes.
Idempotency and change management
- Use Agiloft identifiers and deterministic business keys to avoid duplicate writes.
- Test choice-list, required-field, relationship, workflow-state, and attachment-schema changes.
- Confirm how archival or deletion is represented before deactivating downstream data.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable orchestration
Scripts and point-to-point integrations often combine authentication, mapping, retries, and business rules in deployment-specific code. Martini separates these concerns into reusable workflows and APIs that can be versioned, configured, monitored, and extended when custom logic is required.
Enterprise integration control
- Coordinate scheduled synchronization, configured callbacks, API calls, attachment transfers, and downstream writes.
- Apply validation, transformation, routing, deduplication, checkpoints, and retry policies consistently.
- Keep environment-specific credentials in secrets rather than workflow mappings.
- Expose a controlled API façade when consumers should not depend directly on Agiloft implementation details.
Frequently asked questions
Agiloft can be integrated primarily through its REST APIs for configured tables, records, actions, related data, and supported attachments. Some deployments can make outbound calls from workflow rules or integration actions for selected events, while SOAP may remain relevant to legacy integrations. Scheduled incremental synchronization is an alternative when event coverage is incomplete.
Yes. Martini can consume Agiloft REST APIs, establish the deployment’s supported authentication session, orchestrate scheduled or callback-driven workflows, map configurable Agiloft objects, transfer supported attachments, and expose REST endpoints for configured outbound calls. Martini can also consume SOAP where an existing Agiloft deployment requires it.
No. A dedicated Agiloft connector is not required. Martini can integrate with Agiloft through its confirmed native mechanisms, primarily REST APIs, configured outbound calls, supported attachment operations, and SOAP services where required.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Agiloft. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Agiloft, cloud infrastructure, or other third-party services based on their subscriptions, usage, and deployment models.
REST should generally be evaluated first for new integrations because it is the primary confirmed mechanism for configured Agiloft records and tables. SOAP may be appropriate for an existing implementation or an operation unavailable through REST. The tenant’s release, API version, fields, actions, and authentication flow should be confirmed before design.
Some Agiloft deployments can initiate outbound calls through selected workflow rules or integration actions, but universal webhook coverage was not confirmed. Martini can receive and validate those callbacks through an exposed REST API. Where the required event is unavailable, a scheduled incremental workflow can retrieve changed records.
Martini can use paginated REST requests, modification timestamps, stable ordering, checkpoints, and a small overlap window for incremental synchronization. It can preserve Agiloft record identifiers, use deterministic lookups or external IDs, separate create and update logic, and make attachment transfers repeatable.
Yes. Martini can expose a REST API that provides a controlled interface over Agiloft data or receives Agiloft callbacks. Workflow logic can authenticate callers, validate and transform payloads, apply routing and business rules, invoke Agiloft APIs, and return a governed response without exposing the underlying implementation directly.
Related Martini documentation
APIs
Security
Plan your Agiloft integration
Use Martini to connect Agiloft APIs, workflows, documents, and configured callbacks with the enterprise systems that support your contract lifecycle.