Ellipse Gradient for Header

Dotmatics Integration Guide

Integrate Dotmatics scientific applications with enterprise systems through product-specific REST APIs, scheduled workflows, supported files, and selected event notifications.

Dotmatics integration options at a glance

Dotmatics is a portfolio of scientific applications, so integration capabilities depend on the selected product, tenant, deployment model, enabled modules, and API entitlement. REST APIs are the primary mechanism to investigate for Projects, Experiments, Samples, Compounds, Assays, Results, and related objects. Selected products may also support outbound notifications, imports, exports, batch operations, or file and attachment handling, but these capabilities require product-level confirmation. Martini can consume documented Dotmatics APIs, receive supported callback notifications, run scheduled polling workflows, process files, map scientific data, and expose a normalized API for downstream systems.

Integration pointSupported by Dotmatics?Common use casesHow Martini supports it
REST APIsLimitedThe selected Dotmatics product may expose REST resources for Projects, Experiments, Samples, Compounds, Assays, Results, or other scientific objects. Base URLs, resources, pagination, authentication, and write operations must be confirmed per product and tenant.Martini can consume documented REST endpoints, transform responses, orchestrate related calls, expose normalized APIs, and handle validation, retries, and synchronization state.
Webhooks / outbound callbacksLimitedSelected products may provide notifications for selected object or workflow events, but universal webhook coverage was not confirmed. Event payloads and delivery behavior must be verified.Martini can expose an HTTP API endpoint to receive supported notifications, validate requests, retrieve the current object when necessary, and route downstream workflows.
Bulk, asynchronous, or batch APIsLimitedSome Dotmatics applications may provide imports, exports, batch operations, or asynchronous jobs. No universal bulk API was confirmed.Martini can orchestrate batch requests or export jobs, process bounded result sets, and persist job and checkpoint state for restartable workflows.
File and attachment APIsLimitedScientific records may include documents, analytical outputs, and research artifacts, but a common cross-product attachment API was not confirmed.Martini can process supported file metadata, downloads, uploads, export packages, and storage transfers while preserving identifiers, versions, and checksums where available.
AuthenticationLimitedAPI authentication may use product-specific tokens, API keys, client credentials, OAuth 2.0, or other controls. Interactive SSO should not be assumed to authorize API calls.Martini can externalize credentials and endpoint configuration in secure environment settings and invoke APIs using the authentication model documented for the selected product.
GraphQL APIsNot confirmedA public, product-wide Dotmatics GraphQL API was not verified. GraphQL should be considered only when explicitly documented for the selected application.If a product-specific GraphQL endpoint is confirmed, Martini can consume it using standards-based API workflows; the interface should not be assumed in advance.
SOAP APIsNot confirmedA current, product-wide Dotmatics SOAP interface was not verified. SOAP should be used only when documented for a particular deployment.If a product-specific SOAP service is confirmed, Martini can consume the documented service and transform its responses; no universal Dotmatics SOAP capability is claimed.
Database and analytics accessNot confirmedDirect database access, reporting databases, and standard warehouse exports were not confirmed across Dotmatics products.Martini can connect to an approved database or data service when the customer provides one, but documented Dotmatics APIs and supported exports should be preferred.

How Dotmatics exposes data and business events

Dotmatics REST APIs

REST is the primary mechanism to investigate for new Dotmatics integrations, but Dotmatics does not provide one universally documented API across its product portfolio. Resources, write capabilities, pagination, identifiers, and authentication must be confirmed for the selected product and tenant.

Martini implementation pattern

Martini implementation pattern: Martini authenticates to the documented product API, retrieves or writes the required scientific objects, transforms the product-specific schema into a canonical model, applies business rules, and records synchronization state and errors.

Implementation sequence

Confirm the Dotmatics product, tenant, API version, and permissions
Authenticate using the product-specific API method
Retrieve or submit the required Dotmatics resource
Process pagination or continuation information
Map scientific fields to the target model
Apply validation, routing, and idempotency rules시면

Dotmatics webhook-style notifications

Some Dotmatics products may provide outbound notifications for selected object or workflow events, but universal webhook coverage was not confirmed. The event payload may contain a complete object or only an identifier.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled HTTP endpoint, validates the notification according to the confirmed product behavior, retrieves the current Dotmatics object when needed, and routes the event to downstream workflows with duplicate protection.

Implementation sequence

Confirm event types, payloads, delivery behavior, and replay support
Receive the Dotmatics notification at a Martini API endpoint
Validate the request and identify the source object
Retrieve the current object when the event is incomplete
Apply duplicate and ordering controls
Route the normalized event to downstream systems

Dotmatics scheduled synchronization

When callbacks are unavailable, a scheduled workflow can poll a supported Dotmatics API or process a supported export. Incremental synchronization depends on modification timestamps, revision numbers, change tokens, or equivalent product features.

Martini implementation pattern

Martini implementation pattern: A scheduler starts a bounded workflow, retrieves changed objects or export packages, maps them to target structures, writes successful batches, and persists a ledger for restart and replay.

Implementation sequence

Define the polling window or export scope
Start the Martini workflow on a schedule
Retrieve changed objects or the supported export package
Process pages or batches within bounded limits
Write target records and synchronization checkpoints
Retry transient failures and report permanent errors

Dotmatics files and attachments

Dotmatics applications commonly manage scientific documents, analytical outputs, and research artifacts, but a common attachment API was not confirmed. File contents, metadata, temporary URLs, and export packages must be verified for the selected product.

Martini implementation pattern

Martini implementation pattern: Martini obtains supported file metadata or content, validates authorization and transfer properties, maps document relationships, and sends the artifact to an approved storage or target application without treating large files as ordinary JSON records.

Implementation sequence

Confirm file endpoints, size limits, metadata, and authorization
Retrieve file content or a supported download reference
Validate identifiers, version information, and checksum data
Transfer the file to the approved target location
Write the associated metadata and relationship
Record transfer status and retry failed transfers

Common Dotmatics integration patterns

Pattern 1: Synchronize Dotmatics research data to a data platform

When to use this pattern

Use this pattern when Projects, Experiments, Samples, Assays, or Results must be consolidated for reporting, analytics, or cross-domain research analysis. It is suitable for scheduled API retrieval or supported export processing.

Integration direction
Dotmatics
Martini
Snowflake
Example Mapping
Dotmatics FieldCanonical FieldTarget Field
projectIdresearchProjectIdPROJECT_ID
sampleIdsampleIdentifierSAMPLE_ID
resultValuemeasurementValueRESULT_VALUE
resultUnitmeasurementUnitRESULT_UNIT
Martini implementation pattern

A scheduled Martini workflow retrieves changed objects using the product's supported filter or export mechanism, handles pagination, preserves scientific units and provenance, maps records to warehouse structures, and writes bounded batches. A synchronization ledger prevents duplicates, while transient failures are retried and invalid scientific payloads are routed for review.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • data transformation
  • business rules
  • error handling
  • monitoring

Pattern 2: Align commercial context with Dotmatics Projects

When to use this pattern

Use this pattern when account, collaboration, or commercial project information from Salesforce or Microsoft Dynamics 365 must be associated with Dotmatics research work. Product-specific Dotmatics write permissions and matching rules must be confirmed.

Integration direction
Salesforce
Martini
Dotmatics
Example Mapping
Dotmatics FieldCanonical FieldTarget Field
Account.IdexternalAccountIdaccountReference
Opportunity.NamecollaborationNameprojectName
Opportunity.OwnerIdbusinessOwnerprojectOwner
Opportunity.StageNamecommercialStatusprojectStatus
Martini implementation pattern

Martini receives or polls CRM changes, validates account and project identifiers, checks for an existing Dotmatics Project, and submits a create or update request where supported. Deterministic matching prevents duplicates, while permission failures and invalid project mappings are separated from retryable API errors.

Martini capabilities used
  • API consumption
  • workflow orchestration
  • data mapping
  • validation
  • business rules
  • idempotency
  • error handling

Pattern 3: Synchronize laboratory inventory information

When to use this pattern

Use this pattern when Inventory Items, materials, reagents, or consumables need to remain aligned with SAP S/4HANA or another approved enterprise inventory source. Bidirectional ownership and supported Dotmatics write operations must be established first.

Integration direction
SAP S/4HANA
Martini
Dotmatics
Example Mapping
Dotmatics FieldCanonical FieldTarget Field
MaterialNumberinventoryItemIdentifieritemIdentifier
BaseUnitquantityUnitunitOfMeasure
PlantStockavailableQuantityavailableQuantity
ExpirationDateexpiryDateexpiryDate
Martini implementation pattern

A Martini workflow normalizes material identifiers and units, applies ownership and lot-status rules, and updates supported Dotmatics Inventory Items. It stores source and destination identifiers, prevents repeated writes, and routes unit-conversion, authorization, and partial-update failures for controlled recovery.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • data mapping
  • unit transformation
  • business rules
  • retry handling
  • audit logging

Pattern 4: Route Dotmatics research status notifications

When to use this pattern

Use this pattern when the selected Dotmatics product provides outbound notifications for Projects, Experiments, Assays, Results, or workflow changes. If notifications are unavailable, the same downstream flow can be started by scheduled polling.

Integration direction
Dotmatics
Martini
ServiceNow
Example Mapping
Dotmatics FieldCanonical FieldTarget Field
objectIdsourceObjectIdu_dotmatics_object_id
objectTyperesearchObjectTypecategory
statusresearchStatusstate
updatedAtsourceUpdatedAtu_source_updated_at
Martini implementation pattern

Martini receives a supported callback or detects a changed object, validates the source and event identity, retrieves the current Dotmatics resource when required, and maps the status to a ServiceNow task or request. Event deduplication, ordering controls, and retry queues protect against repeated or incomplete notifications.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflow orchestration
  • data mapping
  • business rules
  • duplicate handling
  • error handling

Applications commonly integrated with Dotmatics

Dotmatics integrations often connect scientific applications with commercial, operational, data-platform, and collaboration systems. The appropriate direction and interface depend on the Dotmatics product, deployment, and enabled API or export capabilities.

Application Scenario Direction Martini Pattern
Salesforce Align customer, account, collaboration, and commercial project context with Dotmatics Projects and related research records. Salesforce → Martini → Dotmatics Martini receives Salesforce changes or polls the relevant API, validates ownership and external identifiers, maps account and project information to the Dotmatics product API, and routes authorization or duplicate-project failures for review.
SAP S/4HANA Synchronize materials, procurement, suppliers, inventory references, and operational data with laboratory workflows. SAP S/4HANA → Martini → Dotmatics A Martini workflow retrieves approved SAP business data, normalizes material identifiers and units, applies product-specific write rules, and submits supported objects to Dotmatics while recording correlation and retry status.
Microsoft Dynamics 365 Exchange account, project, and business-process information with Dotmatics applications where the selected product supports corresponding objects. Microsoft Dynamics 365 → Martini → Dotmatics Martini orchestrates API calls from Dynamics 365 and Dotmatics, applies deterministic matching for accounts and Projects, transforms payloads into the product-specific schema, and isolates validation failures from transient API errors.
ServiceNow Route laboratory requests, incidents, approvals, and operational tasks between enterprise workflow processes and Dotmatics research operations. Dotmatics → Martini → ServiceNow Martini polls or receives supported Dotmatics events, maps project or workflow state to ServiceNow records, creates or updates tasks, and stores source identifiers to prevent duplicate work items.
Snowflake Consolidate Dotmatics research and laboratory data for reporting, analytics, and cross-domain analysis. Dotmatics → Martini → Snowflake A scheduled Martini workflow retrieves changed Dotmatics objects or supported exports, preserves scientific units and provenance, transforms the data into warehouse structures, and writes bounded batches with synchronization checkpoints.
AWS S3 Exchange scientific files, analytical outputs, export packages, and controlled data artifacts where supported by the Dotmatics deployment. Dotmatics → Martini → AWS S3 Martini retrieves file metadata or content through the supported Dotmatics interface, validates size and checksum information, transfers files to S3, and records document identifiers and version state.
Slack Notify research and operational teams about selected project, experiment, or workflow events. Dotmatics → Martini → Slack Martini receives a supported Dotmatics callback or detects a changed object through polling, applies notification rules, formats a concise message, and sends it to the appropriate Slack destination with duplicate suppression.
Jira Create or update technical, laboratory, and research work items from Dotmatics project or workflow state. Dotmatics → Martini → Jira Martini maps Dotmatics Projects, Experiments, or status changes to Jira issue fields, applies routing and priority rules, and maintains source-to-target identifiers for idempotent updates and replay.

How to build a Dotmatics integration in Martini

Objective

Identify the exact Dotmatics product and configure the documented API, export, or callback interface with least-privilege access.

Instructions in Martini

  • Confirm the product, tenant, deployment, API version, and enabled modules
  • Verify the API authentication method, scopes, roles, and environment endpoints
  • Store credentials, tokens, and endpoint configuration in secure Martini environment settings

Objective

Select an event-driven, scheduled, or API-led entry point based on the interfaces available in the selected Dotmatics product.

Instructions in Martini

  • Use a Martini API endpoint for confirmed Dotmatics callbacks
  • Use a scheduler when polling or export processing is required
  • Define the object scope, polling window, and replay behavior

Objective

Obtain the current Dotmatics objects or files while respecting pagination, volume, authorization, and product-specific query rules.

Instructions in Martini

  • Retrieve Projects, Experiments, Samples, Assays, Results, or other confirmed resources
  • Process pages, continuation tokens, or export jobs in bounded batches
  • Retrieve complete objects when notifications contain only identifiers

Objective

Coordinate Dotmatics calls, target-system operations, state tracking, and conditional routes in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, transformation, target writes, and checkpoint persistence
  • Use reusable workflow logic for shared authentication and error paths
  • Route permanent validation failures separately from transient service failures

Objective

Convert product-specific scientific structures into canonical and target schemas without losing scientific fidelity.

Instructions in Martini

  • Map stable identifiers, relationships, timestamps, statuses, units, precision, and provenance
  • Normalize dates and units only according to agreed business rules
  • Handle JSON, XML, files, and attachment metadata according to the confirmed interface

Objective

Enforce ownership, permissions, duplicate detection, routing, and data-quality requirements before writing to target systems.

Instructions in Martini

  • Validate required fields and source-to-target relationships
  • Use deterministic external identifiers or idempotency keys for create operations
  • Apply rules for sensitive data, project scope, inventory status, and notification routing

Common Dotmatics data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ProjectsRepresent research initiatives, programs, study groupings, or collaboration context.Salesforce, Microsoft Dynamics 365, ServiceNow, Snowflake, JiraMartini retrieves or receives Project changes, maps identifiers and ownership, applies validation and routing rules, and maintains source-to-target synchronization state.
ExperimentsCapture experimental procedures, runs, and recorded laboratory activities.Snowflake, Slack, Jira, AWS S3Martini preserves experiment identifiers, status, timestamps, scientific metadata, and related file references while processing changes in bounded batches.
SamplesTrack biological, chemical, or laboratory samples through research workflows.Snowflake, SAP S/4HANA, laboratory data servicesMartini maps sample identifiers, status, provenance, units, and relationships, with product-specific permissions and schema validation.
CompoundsRepresent chemical substances or molecular records in chemistry-focused applications.Snowflake, SAP S/4HANA, research data platformsMartini preserves compound identifiers and scientific attributes, applies field and unit transformations, and routes invalid or incomplete payloads for review.
AssaysRepresent assay definitions, executions, and assay-related scientific data.Snowflake, research analytics platforms, JiraMartini retrieves supported assay data, links it to Projects or Experiments, preserves execution context, and handles pagination and partial failures.
ResultsStore measurements, observations, analysis outputs, and experiment or assay results.Snowflake, AWS S3, reporting APIsMartini processes Results incrementally where supported, preserves precision, units, status, and provenance, and separates large analytical files from ordinary JSON payloads.

Authentication and security considerations

Product-specific authentication

Dotmatics does not have one publicly confirmed authentication model for every product. Confirm whether the selected API uses OAuth 2.0, client credentials, API keys, tokens, or another mechanism. Interactive SSO should not automatically be treated as API authorization.

Least-privilege access

Use product- and tenant-specific service accounts, roles, scopes, and permissions. Restrict access to the Projects, Samples, Compounds, Results, Inventory Items, or other scientific data required by the workflow.

Secure configuration

Store credentials, tokens, endpoint URLs, and API versions in Martini environment configuration and secrets-management facilities rather than in mappings or source code. Protect sensitive scientific, patient-related, compound, study, and intellectual-property data throughout processing.

Operational considerations for Dotmatics integrations

Pagination and volume

Results, Assays, Samples, file metadata, and analytical outputs may be large. Confirm whether the selected API uses pages, offsets, cursors, continuation tokens, or asynchronous exports, and process data in bounded batches.

Incremental synchronization

Prefer documented timestamps, revision numbers, change tokens, or event feeds. Maintain a ledger with object type, source identifier, processed version, destination identifier, status, error details, and retry count.

Idempotency and events

Use stable Dotmatics identifiers and deterministic external keys. Treat callback notifications as potentially duplicated unless exactly-once delivery is explicitly guaranteed, and account for event ordering and incomplete payloads.

Scientific fidelity

Preserve units, significant figures, precision, assay context, result status, instrument or method metadata, time zones, qualitative and quantitative values, and provenance. Handle large analytical files separately from ordinary JSON payloads.

Rate limits and change management

A universal Dotmatics rate-limit policy was not confirmed. Obtain product-specific quotas, honor documented response guidance, and monitor schema or API-version changes across development, testing, and production.

Retries and testing

Separate rate limits, timeouts, and temporary service failures from authorization or validation errors. Use bounded retries, backoff, dead-letter or review handling, replay procedures, representative scientific test data, and workflow monitoring.

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

Adapt to a portfolio architecture

Dotmatics products can differ in object models, authentication, APIs, events, and deployment. Martini provides workflows and reusable integration logic that can accommodate product-specific interfaces without embedding the entire implementation in a one-off script.

Separate orchestration from mapping

Martini separates API consumption, transformation, business rules, target writes, and error handling. This makes it easier to preserve scientific data fidelity, add downstream systems, and update mappings when a product schema changes.

Support multiple operating models

The same platform can coordinate scheduled polling, callback-driven processing, API-led requests, supported exports, and file transfers. It can also expose a controlled API façade for applications that should not call Dotmatics directly.

Improve operational control

Centralized workflows provide consistent validation, idempotency, retries, checkpoints, logging, and environment configuration. This is more maintainable than separate point-to-point scripts when research data flows across multiple enterprise systems.

Frequently asked questions

How can Dotmatics be integrated with enterprise systems?

Dotmatics is a portfolio of scientific applications rather than one product with a universal interface. Integration typically starts with the selected product's documented REST API, and may also use supported callbacks, scheduled polling, imports, exports, batch operations, or file interfaces. Authentication, objects, pagination, and write capabilities must be confirmed for the specific product and tenant.

Can Martini integrate with Dotmatics?

Yes. Martini can integrate with Dotmatics by consuming a documented product-specific REST API, receiving supported webhook-style notifications, polling APIs on a schedule, processing supported files or exports, and exposing APIs for downstream systems. The available path depends on the selected Dotmatics application and its enabled interfaces.

Do I need a connector to integrate Dotmatics with Martini?

No. A dedicated Dotmatics connector is not required. Martini can use Dotmatics' confirmed native APIs, callbacks, exports, files, and authentication methods through workflows, APIs, mappings, transformations, and business rules. A native Martini Dotmatics connector is not documented in the supplied sources.

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

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

Which Dotmatics integration method should be used first?

Investigate the product-specific REST API first because it is the primary mechanism identified for new integrations. Confirm its resources, authentication, pagination, filtering, write operations, and rate limits. Use callbacks, exports, batch processing, or files when the selected product documents them and they better suit the workload.

Can Martini receive Dotmatics webhooks or callbacks?

Potentially, but universal webhook coverage was not confirmed. If the selected Dotmatics product supports outbound notifications and permits Martini's endpoint as a callback target, Martini can receive and process selected events. Otherwise, a scheduled workflow can poll supported APIs for changes.

How does Martini synchronize Dotmatics data?

Martini can run event-driven or scheduled workflows that retrieve changed Dotmatics objects or supported exports, process pagination and bounded batches, map scientific data, and write to target systems. Incremental synchronization should use documented timestamps, revisions, change tokens, or an external synchronization ledger.

How does Martini handle Dotmatics mapping, errors, and API façades?

Martini can map product-specific scientific objects to canonical and target schemas while preserving identifiers, units, precision, status, and provenance. Workflows can distinguish validation failures from transient errors, retry eligible operations, suppress duplicates, and route unresolved items for review. Martini can also expose a controlled REST API façade over supported Dotmatics operations; GraphQL and SOAP should not be assumed for Dotmatics unless separately documented.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Connect Dotmatics with the rest of your enterprise

Use Martini to design a maintainable Dotmatics integration around the APIs, events, exports, and file interfaces supported by your selected product and deployment.

EXPLORE MARTINI
BOOK A DEMO