.png)
Kantata Integration Guide
Connect Kantata OX with enterprise systems through OAuth 2.0-secured REST APIs, selected webhook notifications, and Martini workflows.
Kantata integration options at a glance
Kantata OX provides REST APIs as its primary programmatic integration mechanism for reading and managing Workspaces, Projects, Users, Assignments, Time Entries, Expenses, and other platform resources. Selected resources and events can generate webhook-style notifications, which Martini can receive through an exposed API and use to retrieve authoritative current state. Kantata application authorization uses OAuth 2.0, with access constrained by user permissions and granted application access. Large synchronizations should use paginated REST requests, incremental filters where available, checkpoints, throttling, and retries. File and attachment operations may be available for selected resources but require tenant-specific confirmation.
| Integration point | Supported by Kantata? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve and manage Kantata Workspaces, Projects, Users, Assignments, Time Entries, Expenses, Stories, and related resources. REST is the primary mechanism for synchronization and operational integrations. | Martini can consume Kantata REST endpoints from workflows, handle pagination and filters, transform payloads, apply business rules, and write results to external applications or databases. |
| Webhooks / outbound callbacks | Limited | Receive notifications for selected Kantata resource changes. Coverage should not be assumed for every object, field, or event. | Martini can expose an HTTPS API or webhook-triggered workflow, validate the notification, retrieve the current Kantata resource, and propagate a normalized event. |
| Authentication | Yes | Authorize third-party applications using OAuth 2.0. Access is limited by the authorizing Kantata user's permissions and granted application access. | Martini can use OAuth 2.0 configuration and securely store client credentials, tokens, and environment-specific values in secrets or configuration. |
| File / attachment APIs | Limited | Project-related documents or attachments may be available in selected Kantata product areas, but operations and coverage require confirmation. | Martini can orchestrate documented file or attachment requests when confirmed, transform metadata, and route binary content to an approved target system. |
| Bulk / async / batch APIs | Not confirmed | No sufficiently specific official documentation was verified for a broadly available Kantata bulk or asynchronous API. | Martini can implement controlled paginated REST processing with checkpoints, throttling, bounded batches, and retry handling instead of assuming a bulk endpoint. |
| GraphQL APIs | Not confirmed | No official Kantata GraphQL API documentation was verified; new integrations should use documented REST APIs. | Martini can consume GraphQL for other systems when required, but a Kantata integration should not depend on an unconfirmed GraphQL interface. |
| SOAP APIs | Not confirmed | No official Kantata SOAP API documentation was verified. | Martini supports SOAP for confirmed providers, but Kantata integrations should use REST APIs or documented webhook mechanisms. |
| Database / analytics access | No | No direct customer-database access or broadly documented analytics connection was verified for Kantata. | Martini should use Kantata APIs or supported exports rather than relying on direct database connectivity. |
How Kantata exposes data and business events
Kantata REST APIs
Kantata REST APIs are the primary documented programmatic mechanism for accessing and managing platform resources. They can support project, resource, time, expense, and delivery-data synchronization, subject to API version, tenant configuration, and user permissions.
Martini implementation pattern
Martini workflows authenticate with Kantata using OAuth 2.0, retrieve paginated resources, apply filters or incremental criteria where documented, map Kantata objects to a canonical model, and write or update target systems. Separate workflows can send permitted changes back to Kantata.
Implementation sequence
Kantata webhook notifications
Kantata provides webhook-style notifications for selected resource changes. These notifications are partial and should not be treated as a complete event stream or authoritative copy of every changed object.
Martini implementation pattern
Martini exposes an HTTPS endpoint to receive the notification, validates the request, identifies the event and affected resource, and retrieves current state through the Kantata REST API before transforming and distributing the result. Tenant-specific delivery, signing, retry, and event coverage should be confirmed.
Implementation sequence
Kantata OAuth 2.0
Kantata's documented application authorization model uses OAuth 2.0. Access is constrained by the authorizing user's Kantata permissions and by the access granted to the application.
Martini implementation pattern
Martini stores environment-specific client configuration and token material securely, uses the authorized connection when invoking Kantata REST endpoints, and separates development, test, and production configuration. Required scopes and tenant permissions must be confirmed during implementation.
Implementation sequence
Kantata file and attachment operations
Some Kantata product areas may expose project-related documents or attachments. The precise resources, operations, and transfer behavior require confirmation against current Kantata documentation before implementation.
Martini implementation pattern
When a documented attachment operation is available, Martini can retrieve metadata or content, validate project relationships, and transfer it to an approved repository. The workflow should isolate binary handling from ordinary object synchronization and capture unsupported-operation failures clearly.
Implementation sequence
Common Kantata integration patterns
Pattern 1: Synchronize projects with CRM and ERP systems
When to use this pattern
Use this pattern when Kantata Projects and Workspaces must align with customer, opportunity, or financial records. A scheduled workflow can retrieve changed projects, enrich them with parent relationships, and apply ownership rules before updating downstream systems.
Integration direction
Example Mapping
| Kantata Field | Canonical Field | Target Field |
|---|---|---|
| Project.id | externalProjectId | External Project ID |
| Project.name | projectName | Project Name |
| Project.status | deliveryStatus | Project Status |
| Workspace.id | organizationId | Customer or Subsidiary ID |
Martini implementation pattern
Martini retrieves paginated Projects and related Workspaces, applies an updated-at checkpoint where supported, validates required relationships, and performs idempotent upserts. Business rules determine whether Salesforce owns customer data and NetSuite owns financial data; transient failures are retried and unreconciled objects are reported.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- checkpointing
- error handling
Pattern 2: Synchronize resources and assignments
When to use this pattern
Use this pattern when workforce information and project allocations must be coordinated between Kantata and systems such as Workday, Jira, or Workfront. It supports staffing visibility while preserving system-specific ownership of worker and planning data.
Integration direction
Example Mapping
| Kantata Field | Canonical Field | Target Field |
|---|---|---|
| User.id | personId | Worker ID |
| User.email | ||
| Assignment.project_id | projectId | Project ID |
| Assignment.user_id | resourceId | Resource ID |
Martini implementation pattern
Martini consumes approved worker data, correlates identities, and updates Kantata Users or Assignments only when permissions and writable fields allow it. It can also retrieve Kantata allocations for workforce planning, applying effective-date rules and rejecting records without a valid project or person correlation.
Martini capabilities used
- workflow orchestration
- API consumption
- identity correlation
- data transformation
- validation
- retry handling
Pattern 3: Post approved time and expenses to finance
When to use this pattern
Use this pattern when approved Kantata Time Entries and Expenses must be posted to NetSuite, Microsoft Dynamics 365, payroll, invoicing, or another finance platform. Explicit approval, billing, and rejection rules are important because not every submitted item is eligible for posting.
Integration direction
Example Mapping
| Kantata Field | Canonical Field | Target Field |
|---|---|---|
| Time Entry.id | sourceTimeEntryId | External Time ID |
| Time Entry.project_id | projectId | Project |
| Time Entry.hours | quantity | Hours |
| Expense.amount | amount | Expense Amount |
Martini implementation pattern
A scheduled Martini workflow retrieves bounded sets of Time Entries and Expenses, filters by approved or billing-eligible status, validates project and user relationships, and maps them to the finance model. Correlation keys prevent duplicate posting, while rate limits, rejected statuses, and downstream failures flow to retry and reconciliation handling.
Martini capabilities used
- scheduled workflows
- pagination
- mapping and transformation
- business rules
- idempotency
- error handling
Pattern 4: Process event-driven project updates
When to use this pattern
Use this pattern when selected Kantata changes should trigger downstream updates without waiting for a full scheduled synchronization. Because webhook coverage is partial, the notification should initiate a REST retrieval rather than serve as the complete source object.
Integration direction
Example Mapping
| Kantata Field | Canonical Field | Target Field |
|---|---|---|
| event.resource_id | sourceObjectId | External Reference |
| Project.status | deliveryStatus | State |
| Project.id | projectId | Project Reference |
| Story.id | workItemId | Work Item Reference |
Martini implementation pattern
A Martini API receives the Kantata notification, validates and deduplicates it, retrieves the current Project, Story, Assignment, or other supported resource, and maps the authoritative state to ServiceNow or another target. The workflow records event status, handles out-of-order delivery, and retries transient API or target failures.
Martini capabilities used
- API exposure
- webhook receiving
- workflow orchestration
- API consumption
- deduplication
- monitoring
Applications commonly integrated with Kantata
Kantata commonly participates in enterprise architectures that connect professional-services delivery with customer management, financial operations, workforce data, work management, and service delivery. These are integration patterns rather than claims of prebuilt Kantata integrations; the exact direction and object ownership should be confirmed for each implementation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Align client accounts, opportunities, professional-services projects, and delivery status. | Salesforce → Martini → Kantata | Martini can receive project-initiation data from Salesforce, map account and opportunity identifiers to Kantata Workspaces and Projects, and synchronize project status or utilization updates back through separate REST workflows. Validation, correlation keys, and retry handling prevent duplicate project creation. |
| NetSuite | Transfer project financials, approved time, expenses, billing data, and invoice-related information. | Kantata → Martini → NetSuite | A scheduled Martini workflow retrieves eligible Time Entries and Expenses from Kantata, applies approval and billing rules, maps them to NetSuite project and financial fields, and records source identifiers for idempotent posting. Rejected or rate-limited requests are routed for retry or reconciliation. |
| Workday | Synchronize people, organizational information, and workforce attributes used for project staffing. | Workday → Martini → Kantata | Martini can consume worker and organizational data from Workday, transform it into Kantata Users and related resource attributes, and use stable identifiers to update existing users rather than create duplicates. Permission failures and incomplete worker data are logged for review. |
| Jira | Link delivery work with professional-services planning, assignments, and project tracking. | Jira → Martini → Kantata | Martini can map Jira work items and status changes to Kantata Stories or project-related data, while scheduled REST retrieval keeps project and assignment information aligned. Business rules can restrict synchronization by project, status, or work-item type. |
| ServiceNow | Coordinate customer projects, implementation work, service requests, and delivery status. | ServiceNow → Martini → Kantata | Martini can receive ServiceNow project or request events, retrieve the relevant Kantata Project or Story, and normalize status, ownership, and delivery fields in both systems. A correlation table and controlled retry path support reliable bidirectional updates. |
| Microsoft Dynamics 365 | Synchronize accounts, opportunities, projects, and financial or operational data. | Microsoft Dynamics 365 → Martini → Kantata | Martini can orchestrate project initiation from Dynamics 365 into Kantata and return delivery or utilization data through REST calls. Field mappings isolate Kantata-specific relationships and business rules determine which statuses or financial fields are eligible for downstream posting. |
| Workfront | Exchange project plans, work items, resource information, and delivery status where both platforms are used. | Workfront → Martini → Kantata | A Martini workflow can retrieve changed Workfront and Kantata objects, map project and resource identifiers into a canonical model, and apply ownership rules before writing updates. Checkpoints and reconciliation reports manage late changes and partial failures. |
How to build a Kantata integration in Martini
Objective
Establish Kantata application authorization and environment-specific configuration without embedding credentials in workflow logic.
Instructions in Martini
- Register or obtain the Kantata OAuth 2.0 application details
- Configure client credentials and token settings in protected Martini configuration
- Confirm the authorizing user's Kantata permissions and required access
- Separate development, test, and production values
Objective
Select a scheduled REST synchronization or a supported Kantata webhook notification based on the required freshness and event coverage.
Instructions in Martini
- Use a scheduler for reliable periodic synchronization
- Use a Martini API or webhook-triggered workflow for selected Kantata notifications
- Confirm the required object and event types before depending on webhooks
- Define a fallback schedule when webhook coverage is incomplete
Objective
Read Kantata resources in bounded, permission-aware requests and maintain enough state to support incremental processing.
Instructions in Martini
- Call the documented Kantata REST API
- Process Projects, Users, Assignments, Time Entries, Expenses, or other required objects in pages
- Use documented filters or modification criteria where available
- Store a durable checkpoint and preserve source identifiers
Objective
Coordinate retrieval, enrichment, validation, target writes, and recovery as maintainable Martini workflow stages.
Instructions in Martini
- Separate trigger, retrieval, transformation, and delivery responsibilities
- Retrieve current Kantata state after webhook notifications
- Apply bounded processing and controlled request rates
- Route transient and permanent failures to distinct handling paths
Objective
Convert Kantata object relationships and statuses into the target application's data model without losing source traceability.
Instructions in Martini
- Map Kantata identifiers to canonical and target identifiers
- Preserve Workspace and Project relationships
- Normalize dates, statuses, amounts, and user references
- Validate required fields before target writes
Objective
Ensure only valid and eligible Kantata data is propagated to downstream systems.
Instructions in Martini
- Filter Time Entries and Expenses by approval or billing eligibility
- Apply project ownership and synchronization-direction rules
- Reject incomplete relationships with actionable error context
- Use idempotent upsert logic and correlation keys
Common Kantata data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Workspaces | Group organizations, operating units, projects, and related professional-services data. | Salesforce, NetSuite, Microsoft Dynamics 365, data platforms | Martini retrieves workspace identifiers and relationships, maps them to canonical organizational keys, and preserves parent context during synchronization. |
| Projects | Represent client engagements or internal initiatives, including status, dates, financial details, and delivery information. | Salesforce, NetSuite, ServiceNow, Workfront, Microsoft Dynamics 365 | Martini uses paginated or incremental REST retrieval, validates required fields, applies project-status rules, and performs idempotent upserts using stable Kantata identifiers. |
| Users | Represent people who participate in projects, submit time, manage work, or administer Kantata. | Workday, Salesforce, Jira, Microsoft Dynamics 365 | Martini maps user identity and organizational attributes, correlates source identifiers, and handles permission-related omissions or authorization failures. |
| Assignments | Allocate users or resources to projects and planned work. | Workday, Jira, Workfront, workforce-planning systems | Martini transforms allocation and project relationships into target resource models, applies effective-date and ownership rules, and supports incremental reconciliation. |
| Time Entries | Capture submitted or approved time associated with projects, users, activities, or assignments. | NetSuite, Workday, payroll, invoicing, finance platforms | Martini filters by approval or billing status, maps project and user keys, validates financial fields, and prevents duplicate posting through correlation data. |
| Expenses | Capture project-related expenses and expense submissions. | NetSuite, Microsoft Dynamics 365, finance and invoicing platforms | Martini applies eligibility and approval rules, transforms amounts and project relationships, and routes failed postings to retry and reconciliation workflows. |
Authentication and security considerations
OAuth 2.0 authorization
Kantata's documented application authorization model uses OAuth 2.0. Access is constrained by the authorizing Kantata user's permissions and the application's granted access.
Credential protection
Store Kantata client credentials, access tokens, and environment-specific configuration in Martini secrets or protected environment configuration rather than embedding them in workflow logic.
Least privilege
- Confirm the required Kantata scopes and tenant permissions before deployment.
- Use separate credentials and configuration for development, testing, and production.
- Limit exposed Martini API operations to the Kantata processes that downstream systems require.
Operational considerations for Kantata integrations
Pagination and rate limits
Process large Kantata portfolios in bounded pages. Tenant, application, or endpoint rate limits may vary, so implement throttling, exponential backoff, and explicit handling for HTTP 429 responses.
Webhooks and idempotency
Treat webhook notifications as triggers to retrieve current state. Account for duplicate, delayed, and out-of-order notifications, and use stable Kantata identifiers and correlation data for idempotent writes.
Permissions and schemas
OAuth authorization does not bypass Kantata user permissions. API versions, fields, relationships, and status values can change, so isolate mappings, validate required fields, and monitor response changes.
Reconciliation
Record failed object identifiers, request context, response status, and retry count. Provide a bounded replay or reconciliation process for scheduled synchronizations and partially completed runs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini coordinates Kantata API calls, webhook triggers, transformations, validation, business rules, target writes, and recovery in maintainable workflows rather than scattering logic across scripts.
Reusable integration assets
Teams can expose controlled Martini APIs, reuse workflow logic, and create consistent mappings for Projects, Users, Assignments, Time Entries, and Expenses across multiple target systems.
Operational control
Checkpoints, idempotency, throttling, retry handling, logging, and reconciliation provide a stronger operational model than point-to-point code that must independently solve each concern.
Frequently asked questions
Kantata OX can be integrated primarily through its REST APIs, which provide access to resources such as Workspaces, Projects, Users, Assignments, Time Entries, Expenses, and Stories. Kantata also provides webhook-style notifications for selected resource changes and uses OAuth 2.0 for application authorization. Large synchronizations should use pagination, checkpoints, throttling, and retries.
Yes. Martini can integrate with Kantata by consuming its OAuth 2.0-secured REST APIs, receiving supported webhook notifications through an exposed Martini API, transforming Kantata objects, and orchestrating synchronization with other applications. No native Martini Kantata connector is documented in the supplied research.
No dedicated Kantata connector is required. Martini can use Kantata's confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authorization, and selected webhook-style notifications, while handling workflows, mappings, validation, retries, and target-system delivery.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Kantata. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Kantata, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
REST APIs should be the primary method for new Kantata integrations. OAuth 2.0 is the documented application authorization model, and selected webhook-style notifications can support event-driven triggers. No official Kantata GraphQL or SOAP documentation was verified, and no general-purpose bulk API was confirmed.
Martini can receive Kantata webhook-style notifications for the event types and resources that Kantata exposes. Coverage is selective, so integrations should verify the required event catalog. A reliable design treats the notification as a trigger and retrieves the current resource through the REST API.
Martini can run scheduled workflows that retrieve paginated Kantata resources, use documented incremental criteria where available, map the data to a canonical model, and write it to a target application. Stable Kantata identifiers, checkpoints, relationship preservation, and idempotent upserts help manage duplicates and late updates.
Martini can validate payloads, record source identifiers and request context, retry transient failures with controlled backoff, and route permanent failures to reconciliation workflows. Webhook notifications should be deduplicated because delivery may be delayed, repeated, or out of order. Rate-limit responses such as HTTP 429 require throttling and retry policies.
Related Martini documentation
Data processing
Connect Kantata with your enterprise systems
Use Martini to build maintainable Kantata integrations with REST APIs, selected webhook notifications, OAuth 2.0 security, workflow orchestration, data mapping, and operational controls.