Ellipse Gradient for Header

TeamDynamix Integration Guide

Integrate TeamDynamix with enterprise applications through TDWebApi REST workflows, authenticated APIs, scheduled synchronization, and selected webhook-style notifications.

TeamDynamix integration options at a glance

TeamDynamix primarily integrates through its TDWebApi REST API, which supports authenticated access to Tickets, Users, Assets, Projects, Services, and Knowledge articles. Martini can consume these APIs in workflows, expose Martini REST APIs that orchestrate TeamDynamix operations, and transform TeamDynamix JSON for downstream applications. Selected TeamDynamix environments may provide webhook-style notifications or callbacks, but coverage depends on the enabled module, event type, tenant configuration, and delivery behavior. Scheduled workflows can provide a dependable alternative using pagination, incremental filters, checkpoints, retries, and idempotency. Attachment handling may also be available for supported objects.

Integration pointSupported by TeamDynamix?Common use casesHow Martini supports it
REST APIsYesTDWebApi is TeamDynamix’s primary programmatic surface for querying and updating Tickets, Users, Assets, Projects, Services, and Knowledge articles.Martini can authenticate, consume REST endpoints, paginate results, transform JSON, apply business rules, and expose APIs that orchestrate TeamDynamix operations.
Webhooks / outbound callbacksLimitedSelected TeamDynamix functions may provide outbound HTTP notifications for supported module events. Coverage and delivery semantics depend on the tenant and configuration.Martini can expose a REST endpoint to receive notifications, validate and deduplicate them, retrieve the current TeamDynamix object, and route the result.
File / attachment APIsLimitedAttachments are relevant to supported service-management objects, particularly Tickets, subject to endpoint, format, size, and permission constraints.Martini can retrieve metadata, download or upload supported files, transform or route attachments, and preserve source IDs and checksums for duplicate control.
AuthenticationYesTeamDynamix API access commonly uses an authenticated login request followed by a token for subsequent calls, with tenant and permission requirements varying by environment.Martini can store credentials and tokens in protected configuration, call the login flow, apply required headers, and isolate credentials from workflow data and logs.
Pagination and incremental synchronizationYesREST list operations may require pagination, and modified-date or equivalent filters may support incremental extraction where available.Martini workflows can implement page and continuation handling, overlap windows, durable checkpoints, bounded loops, and idempotent writes.
Bulk / async / batch APIsNot confirmedA general-purpose TeamDynamix bulk API was not confirmed. Larger transfers should use ordinary REST requests unless tenant documentation identifies specific batch endpoints.Martini can orchestrate paginated, time-windowed REST requests with rate-aware processing and failure isolation.
GraphQL APIsNot confirmedNo official TeamDynamix GraphQL API was confirmed in the supplied research.Martini should use the confirmed REST surface instead of assuming GraphQL availability.
SOAP APIsNot confirmedNo official TeamDynamix SOAP API was confirmed in the supplied research.Martini should not make SOAP the default TeamDynamix integration method; it can use REST unless tenant documentation confirms another endpoint.

How TeamDynamix exposes data and business events

TeamDynamix REST APIs

TDWebApi is the primary documented TeamDynamix integration mechanism. It provides authenticated REST operations for practical objects such as Tickets, Users, Assets, Projects, Services, and Knowledge articles, with exact resources and permissions varying by module and tenant.

Martini implementation pattern

Martini uses a workflow to authenticate, retrieve or update TeamDynamix resources, transform JSON, apply business rules, and write results to downstream applications. For inbound use cases, a Martini REST API can accept an external request and orchestrate TeamDynamix operations behind a controlled interface.

Implementation sequence

Authenticate with the TeamDynamix login and token flow
Receive a request or start a scheduled synchronization
Retrieve the required TeamDynamix resource pages
Validate references and apply business rules
Map TeamDynamix JSON to the target model
Create or update the target application record and store the TeamDynamix identifier

TeamDynamix webhook-style notifications

Some TeamDynamix environments may provide outbound HTTP notifications or automation callbacks for selected functions. Event coverage, payload completeness, authentication, retry behavior, and transaction timing must be verified for the tenant and module.

Martini implementation pattern

Martini exposes a secured API endpoint to receive supported notifications. The workflow validates the notification, deduplicates it, retrieves the current TeamDynamix object when the payload contains only an identifier, and routes the enriched data to downstream systems. Scheduled polling can cover events without callback support.

Implementation sequence

Receive the selected TeamDynamix notification
Validate the source, payload, and correlation data
Check the object ID and event timestamp for duplicate delivery
Retrieve the current TeamDynamix object when required
Apply routing, filtering, and sensitivity rules
Write downstream changes and record processing status

TeamDynamix attachment handling

Attachment operations may be available for supported TeamDynamix objects, particularly Tickets. Endpoint availability, file formats, size limits, permissions, and object coverage should be confirmed against the customer’s API reference.

Martini implementation pattern

Martini can retrieve attachment metadata, download supported files, validate content and size, and route files to another application or upload them to a supported TeamDynamix object. The workflow preserves source IDs and checksums to avoid duplicate transfers.

Implementation sequence

Identify the supported TeamDynamix object and attachment operation
Retrieve attachment metadata and permissions
Download or receive the file using a controlled workflow
Validate content type, size, and security requirements
Route or upload the attachment to the target system
Store the source identifier, checksum, and processing result

Common TeamDynamix integration patterns

Pattern 1: Create TeamDynamix Tickets from a support portal

When to use this pattern

Use this pattern when an external portal needs to submit service requests into TeamDynamix while receiving a Ticket identifier and initial status. Martini provides a controlled API boundary and keeps portal-specific fields separate from TeamDynamix implementation details.

Integration direction
Support portal
Martini
TeamDynamix
Example Mapping
TeamDynamix FieldCanonical FieldTarget Field
requesterEmailrequester.emailTeamDynamix User
priorityservice.priorityTicket priority
categoryservice.categoryTicket classification
descriptionrequest.descriptionTicket description
Martini implementation pattern

A Martini API receives and validates the request, resolves the requester and service references, maps external priority and category values, and calls TDWebApi to create the Ticket. The workflow returns the TeamDynamix Ticket ID, stores a correlation identifier, and routes validation or transient API failures through distinct error paths with retry rules.

Martini capabilities used
  • APIs
  • workflows
  • data mapping
  • business rules
  • API consumption
  • error handling

Pattern 2: Synchronize TeamDynamix Tickets with Salesforce

When to use this pattern

Use this pattern when customer-facing teams need selected TeamDynamix service activity in Salesforce. The design should limit copied content, use incremental extraction, and define ownership for fields that may be updated in both systems.

Integration direction
TeamDynamix
Martini
Salesforce
Example Mapping
TeamDynamix FieldCanonical FieldTarget Field
Ticket.IDsupport.externalIdCase.TeamDynamixTicketId
Ticket.Statussupport.statusCase.Status
Ticket.Prioritysupport.priorityCase.Priority
Ticket.RequestorUIDrequester.externalIdCase.ContactId
Martini implementation pattern

A scheduled Martini workflow queries modified TeamDynamix Tickets using pagination and an overlap window, resolves User references, filters sensitive content, and upserts Salesforce cases using the TeamDynamix Ticket ID as the external key. Checkpoints, bounded retries, and dead-letter handling prevent duplicate or silently missed updates.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • incremental synchronization
  • data mapping
  • idempotency
  • retry handling

Pattern 3: Synchronize TeamDynamix Users and Assets

When to use this pattern

Use this pattern when identity, endpoint-management, finance, or configuration processes need current TeamDynamix Users and Assets. It is suitable for periodic reconciliation where the TeamDynamix tenant does not provide complete event coverage.

Integration direction
Microsoft Entra ID
Martini
TeamDynamix
Example Mapping
TeamDynamix FieldCanonical FieldTarget Field
User.Emailperson.emailuser.mail
User.DepartmentIDorganization.departmentIduser.department
Asset.SerialNumberasset.serialNumberdevice.serialNumber
Asset.Statusasset.lifecycleStatusdevice.managementStatus
Martini implementation pattern

Martini retrieves source changes, normalizes organizational and lifecycle values, resolves TeamDynamix identifiers, and applies only approved updates. The workflow records checkpoints, compares stable external IDs, isolates object-level failures, and produces reconciliation results for inactive users or retired assets.

Martini capabilities used
  • workflows
  • scheduling
  • data mapping
  • business rules
  • checkpointing
  • error handling

Pattern 4: Process selected TeamDynamix events for operational notifications

When to use this pattern

Use this pattern when a tenant supports the required Ticket or service-related callback and downstream teams need timely assignment, escalation, or major-service notifications. A hybrid callback and polling design is appropriate when event coverage is incomplete.

Integration direction
TeamDynamix
Martini
Microsoft Teams
Example Mapping
TeamDynamix FieldCanonical FieldTarget Field
Ticket.IDincident.externalIdTeams notification.ticketId
Ticket.Titleincident.summaryTeams notification.title
Ticket.Statusincident.statusTeams notification.status
Ticket.Priorityincident.priorityTeams notification.severity
Martini implementation pattern

Martini receives a supported notification, validates and deduplicates it, retrieves the current Ticket when necessary, filters sensitive descriptions, and applies escalation rules before sending a Teams notification. Unsupported events can be covered by scheduled REST polling, while failed deliveries are retried without replaying already processed Ticket IDs.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflows
  • business rules
  • data transformation
  • duplicate handling
  • error handling

Applications commonly integrated with TeamDynamix

TeamDynamix can be integrated with adjacent enterprise applications through its REST APIs and, where available, selected webhook-style notifications. The following are practical architecture patterns rather than claims of native TeamDynamix integrations.

Application Scenario Direction Martini Pattern
Microsoft Entra ID Synchronize users, departments, groups, and account status for TeamDynamix requester and technician data. Microsoft Entra ID → Martini → TeamDynamix A scheduled Martini workflow retrieves approved identity changes, maps users and organizational attributes, applies provisioning rules, and updates TeamDynamix through TDWebApi. Permission and inactive-account errors are recorded for review.
Salesforce Link customer, account, contact, and case information to TeamDynamix Tickets and support activity. Salesforce → Martini → TeamDynamix Martini receives or polls Salesforce changes, validates service and priority mappings, creates or updates TeamDynamix Tickets, and synchronizes selected status and resolution fields back to Salesforce with correlation IDs.
ServiceNow Coordinate service-management processes during migration, coexistence, or cross-department support operations. TeamDynamix → Martini → ServiceNow Martini synchronizes selected Tickets, Users, Services, and related reference data between the platforms, using ownership rules, external IDs, change checkpoints, and loop-prevention logic.
Jira Synchronize incidents, defects, development tasks, or project work between service management and engineering teams. TeamDynamix → Martini → Jira A TeamDynamix workflow or scheduled poll identifies engineering-related Tickets, maps them to Jira issues, and processes Jira status updates back into TeamDynamix while handling duplicate notifications and failed references.
Workday Align employee, organization, manager, and department information with TeamDynamix Users and routing rules. Workday → Martini → TeamDynamix Martini extracts approved Workday changes, normalizes organizational values, resolves existing TeamDynamix Users, and applies controlled updates through authenticated REST calls with a durable checkpoint.
Microsoft Intune Reconcile managed devices with TeamDynamix Assets and support asset-related ticket workflows. Microsoft Intune → Martini → TeamDynamix Martini retrieves device data from Intune, maps stable device identifiers and ownership to TeamDynamix Assets, applies lifecycle rules, and routes object-level validation failures for remediation.
NetSuite Coordinate purchasing, asset financial information, vendors, or project data with TeamDynamix operational records. NetSuite → Martini → TeamDynamix A Martini workflow exchanges approved reference or asset data, transforms identifiers and financial attributes, and writes only the TeamDynamix fields required by the customer’s operating model.
Microsoft Teams Notify support teams about ticket assignments, escalations, and major service events. TeamDynamix → Martini → Microsoft Teams Martini receives supported TeamDynamix events or polls for qualifying Ticket changes, applies escalation and content-filtering rules, and sends concise notifications to Teams while preserving the source Ticket ID.

How to build a TeamDynamix integration in Martini

Objective

Establish authenticated access to the customer’s TeamDynamix TDWebApi environment with permissions limited to the required modules and operations.

Instructions in Martini

  • Confirm the tenant or account identifiers, login endpoint, required headers, and token behavior.
  • Create a dedicated TeamDynamix integration account with least-privilege access.
  • Store credentials and tokens in protected Martini configuration or secrets.
  • Test access separately for Tickets, Users, Assets, Projects, Services, or Knowledge as required.

Objective

Select an event, API request, or scheduled trigger based on the TeamDynamix capability and the required timeliness of the integration.

Instructions in Martini

  • Use a Martini API for externally initiated Ticket or service requests.
  • Use a TeamDynamix webhook-style notification only after tenant event coverage is verified.
  • Use a scheduler and incremental REST queries when callbacks are unavailable or incomplete.
  • Define the checkpoint, overlap window, and scope of each synchronization.

Objective

Obtain complete and current TeamDynamix objects while accounting for pagination, references, and payload differences between modules.

Instructions in Martini

  • Implement page, offset, or continuation handling according to the endpoint response.
  • Retrieve related Users, Services, Assets, or other reference data when required.
  • Treat callback payloads as notifications and retrieve the current object when they contain only an identifier.
  • Record source IDs, timestamps, and correlation values.

Objective

Coordinate validation, enrichment, routing, target writes, and operational outcomes in a maintainable Martini workflow.

Instructions in Martini

  • Separate authentication, retrieval, transformation, business rules, and target writes into clear workflow stages.
  • Apply module-specific permission and reference-data checks before write operations.
  • Use reusable workflow logic for common API calls, pagination, and error classification.
  • Keep TeamDynamix-specific behavior behind a controlled Martini API where consumers should not depend on TDWebApi details.

Objective

Convert TeamDynamix JSON and configured field values into the canonical and target application models.

Instructions in Martini

  • Map stable identifiers before display labels wherever possible.
  • Normalize Users, priorities, categories, Services, statuses, and Asset lifecycle values.
  • Filter descriptions, comments, attachments, and Knowledge content according to data-sharing rules.
  • Preserve source identifiers and correlation IDs for reconciliation.

Objective

Enforce routing, ownership, sensitivity, deduplication, and synchronization policies before changing either system.

Instructions in Martini

  • Use TeamDynamix Ticket IDs or other stable object identifiers as external keys.
  • Check for an existing target record before creating a new object after retries.
  • Define field ownership when both TeamDynamix and the target application can update data.
  • Route invalid references, insufficient permissions, and sensitive-content violations for review.

Common TeamDynamix data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
TicketsIncidents, service requests, tasks, assignments, status changes, comments, and related service-management work.Salesforce, ServiceNow, Jira, Microsoft Teams, reporting storesMartini retrieves or receives qualifying Ticket changes, maps categories, priorities, users, services, and statuses, applies idempotency using the Ticket ID, and creates or updates target records.
UsersRequesters, technicians, managers, approvers, and other people represented in TeamDynamix.Microsoft Entra ID, Workday, Salesforce, ServiceNow, identity and governance platformsMartini synchronizes approved identity attributes, resolves stable identifiers, applies account and organizational rules, and routes permission or reference-data failures.
AssetsHardware, software, configuration items, ownership, lifecycle, and support relationships.Microsoft Intune, NetSuite, configuration-management platforms, finance systemsMartini reconciles stable asset identifiers, maps ownership and lifecycle values, and processes attachment or related-ticket data where supported.
ProjectsProject records, plans, tasks, schedules, and project-management information.Jira, NetSuite, reporting stores, portfolio-management applicationsMartini retrieves project data through TDWebApi, transforms project and task structures, applies approved synchronization scope, and checkpoints large extracts.
ServicesService catalog offerings, request information, categories, and routing values.Salesforce, ServiceNow, external support portals, Microsoft TeamsMartini caches or retrieves service reference data, maps external service selections to TeamDynamix values, and validates references before Ticket creation.
Knowledge articlesSearchable support content and knowledge-management information.Portals, content platforms, search indexes, reporting storesMartini can retrieve supported article data, transform content and metadata, apply publication and sensitivity rules, and route indexing or migration failures.

Authentication and security considerations

Authentication model

TeamDynamix API access commonly uses an authenticated login request that returns a token for subsequent API calls. The exact login payload, headers, token lifetime, tenant identifiers, and account requirements should be confirmed in the customer’s TDWebApi reference.

Permissions and secrets

Use a dedicated integration account with least-privilege access to the required TeamDynamix modules and operations. Store credentials and tokens as protected Martini configuration or secrets, and do not embed them in workflows or log output.

Transport and data protection

  • Use HTTPS for TeamDynamix API and callback communication.
  • Limit access to Tickets, Users, Assets, Projects, Services, and Knowledge according to the integration’s purpose.
  • Apply content, attachment, retention, and malware-scanning rules before transferring sensitive data.
  • OAuth 2.0, JWT application authentication, and API-key authentication were not confirmed as TeamDynamix’s general REST model.

Operational considerations for TeamDynamix integrations

Pagination and synchronization

Do not assume that a TeamDynamix list response contains all results. Implement pagination, incremental filters where available, durable checkpoints, and an overlap window around synchronization boundaries.

Rate limits and retries

Confirm tenant-specific limits and behavior for throttling responses such as HTTP 429. Use bounded retries with backoff and avoid unrestricted parallel requests.

Idempotency and duplicates

Use stable TeamDynamix object identifiers as external keys. For Ticket creation, retain a source correlation ID and check for an existing Ticket before creating a new one, especially when callbacks or workflow retries may repeat a request.

Configuration and schema changes

TeamDynamix fields, forms, categories, priorities, statuses, Services, and permissions may vary by tenant. Prefer stable identifiers over display labels and test representative create, update, search, attachment, and error scenarios across environments.

Observability

Preserve response bodies, correlation IDs, workflow outcomes, and retry counts while excluding credentials and unnecessary sensitive Ticket content from logs.

Why use Martini instead of scripts or point-to-point integrations?

Reusable integration workflows

Martini separates authentication, API consumption, transformation, business rules, target writes, and error handling into maintainable workflows rather than scattering logic across scripts.

Controlled APIs

Martini can expose an API façade that hides TeamDynamix-specific details, validates requests, applies authorization and routing rules, and presents a stable contract to portals and enterprise applications.

Reliable synchronization

Scheduled and event-driven designs can combine pagination, checkpoints, overlap windows, idempotency, bounded retries, and dead-letter handling for dependable data movement.

Adaptable data transformation

Martini maps TeamDynamix JSON and configured reference values to canonical and target models, while allowing customer-specific rules for Users, Tickets, Assets, Projects, Services, and Knowledge articles.

Frequently asked questions

How can TeamDynamix be integrated with enterprise systems?

TeamDynamix can be integrated primarily through its TDWebApi REST API. Enterprise workflows can authenticate, retrieve and update Tickets, Users, Assets, Projects, Services, and Knowledge articles, while selected tenant configurations may provide webhook-style notifications or callbacks. Scheduled REST synchronization is an alternative when event coverage is incomplete.

Can Martini integrate with TeamDynamix?

Yes. Martini can integrate with TeamDynamix by consuming authenticated TDWebApi REST endpoints, exposing APIs that orchestrate TeamDynamix operations, running scheduled synchronization workflows, and receiving supported webhook-style notifications through a Martini API.

Do I need a connector to integrate TeamDynamix with Martini?

No. A dedicated TeamDynamix connector is not required. Martini can use TeamDynamix’s confirmed native integration mechanisms, including TDWebApi REST endpoints, the tenant’s authentication flow, scheduled workflows, and supported webhook or callback mechanisms.

Is there any extra Lonti cost to integrate TeamDynamix with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate TeamDynamix. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from TeamDynamix, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.

Which TeamDynamix integration methods should an enterprise use?

TDWebApi REST endpoints should be treated as the primary method for new integrations. Use webhook-style notifications only for verified tenant and module events, and use scheduled REST polling with pagination and checkpoints for objects or events without reliable callbacks. A general bulk API, GraphQL API, and SOAP API were not confirmed.

Can TeamDynamix send events or webhooks to Martini?

Potentially, for selected TeamDynamix functions. Webhook and callback coverage is module- and configuration-dependent, so event types, payload contents, authentication, retry behavior, duplicate delivery, and transaction timing should be verified before implementation. Martini can receive supported notifications and use polling for gaps.

How should TeamDynamix data synchronization handle mapping and duplicates?

Use incremental REST queries where supported, pagination, durable checkpoints, and a small overlap window. Map stable TeamDynamix identifiers to canonical and target keys, and use those identifiers for idempotent upserts. For Ticket creation, retain a source correlation ID and check for an existing Ticket before creating another one.

How does Martini handle TeamDynamix errors and expose an API façade?

Martini can classify authentication, permission, validation, throttling, transient network, and permanent object-level failures, then apply bounded retries or route failures for review. It can also expose a REST API façade that validates external requests, applies business rules, calls TDWebApi, and returns a controlled response without exposing TeamDynamix-specific implementation details.

Related Martini documentation

APIs

Workflows

Transformation

Security

Operations

Integrate TeamDynamix with Martini

Use Martini to connect TeamDynamix APIs and supported notifications with the applications, workflows, and data services your organization relies on.

EXPLORE MARTINI
BOOK A DEMO