Ellipse Gradient for Header

Tulip Integration Guide

Connect Tulip frontline applications, Tables, operators, stations, and machines with enterprise systems through REST APIs, selected webhook events, and scheduled workflows.

Tulip integration options at a glance

Tulip provides REST APIs for accessing platform and operational resources such as Apps, Tables, Table Records, Machines, Users, and Stations. Tulip also supports webhook-style notifications for selected events and use cases, although coverage must be verified for each resource and event. Collection endpoints should be handled with pagination, checkpoints, throttling, and retries because a general-purpose bulk API was not confirmed. Martini can consume Tulip APIs, receive supported webhook callbacks through exposed APIs, transform operational data, apply business rules, and synchronize results with enterprise applications. Tulip API credentials use an API key and API secret, commonly through HTTP Basic Authentication.

Integration pointSupported by Tulip?Common use casesHow Martini supports it
REST APIsYesRead and write Tables and Table Records, retrieve Apps, Users, Machines, and Stations, and synchronize Tulip operational data with enterprise platforms.Martini workflows consume Tulip REST endpoints over HTTP, map payloads, apply validation and business rules, and can expose normalized REST APIs for downstream systems.
Webhooks / outbound callbacksLimitedReceive notifications for selected Tulip events or use cases where the required resource and event are supported.Martini can expose an HTTPS API endpoint, validate the inbound request, apply idempotency controls, transform the payload, and route it to other workflows or systems.
Bulk / async / batch APIsLimitedLarge Table or operational data synchronizations can use collection pagination, but a general-purpose bulk or asynchronous API was not confirmed.Martini implements paginated, checkpointed workflows with throttling, bounded windows, retries, and reconciliation rather than assuming bulk semantics.
File / attachment APIsLimitedAttachment behavior may exist for selected Tulip resources such as Table Records or App-related data, but a universal file API was not confirmed.Martini can process files or attachments when the selected Tulip resource exposes a documented endpoint and can route content through workflow transformations.
AuthenticationYesTulip API credentials use an API key and API secret, commonly supplied with HTTP Basic Authentication and scoped by user, role, workspace, and resource permissions.Martini stores credentials in secrets or environment configuration and references them from API-consuming workflows without hard-coding them.
Database / analytics accessNot confirmedTulip Tables are normally accessed through Tulip APIs; direct access to Tulip’s production application database was not confirmed.Martini should consume documented Tulip APIs or separately evaluated export and analytics mechanisms rather than assuming direct database connectivity.
SDKs and standard HTTP clientsYesTulip REST APIs can be consumed with standard HTTP clients; a vendor SDK is not required for integration.Martini uses API-consumption workflows and reusable mappings, so integration logic does not depend on a Tulip-specific SDK.

How Tulip exposes data and business events

Tulip REST APIs

Tulip exposes REST resources for platform and operational data, including Apps, Tables, Table Records, Machines, Users, and Stations. Exact resources, operations, API versions, and permissions vary by Tulip instance.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with the Tulip API key and secret, calls the required endpoint, validates the response, maps Tulip fields to a canonical model, applies business rules, and writes to an enterprise target or returns a normalized API response.

Implementation sequence

Authenticate with the Tulip API key and secret
Retrieve or submit the required Tulip resource
Handle pagination and persist an incremental checkpoint
Validate the response and map fields to the target model
Apply business rules and perform an idempotent write
Record correlation identifiers and workflow status

Tulip Webhooks

Tulip supports webhook-style integrations for selected events and use cases. Coverage is resource- and event-specific, so an implementation must verify that the required event, payload, authentication, and delivery behavior are available.

Martini implementation pattern

Martini implementation pattern: expose a secured HTTPS API endpoint, receive the Tulip notification, validate and record the event, prevent duplicate processing, then retrieve additional resource data when needed before routing the result to enterprise systems.

Implementation sequence

Receive the Tulip webhook notification
Authenticate and validate the inbound request
Record the event and apply idempotency checks
Retrieve the current Tulip resource when the payload is incomplete
Map the event to the target system model
Route the result and handle retryable failures

Paginated Synchronization

Tulip collection access is paginated, while comprehensive support for a general-purpose bulk or asynchronous API was not confirmed. Large synchronizations therefore require controlled incremental processing.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow reads bounded pages, tracks a cursor, timestamp, or object identifier, throttles requests, transforms records, and resumes from the last successful checkpoint after a failure.

Implementation sequence

Start the scheduled synchronization window
Read the next Tulip page
Transform and validate each Table Record or resource
Write records using durable source identifiers
Persist the successful checkpoint
Retry transient failures and reconcile missed changes

Common Tulip integration patterns

Pattern 1: Synchronize ERP work orders with Tulip

When to use this pattern

Use this pattern when an ERP such as SAP S/4HANA or NetSuite is the system of record for production work orders and Tulip Apps need an operational representation. The reverse flow can return completed quantities, operator results, and exceptions.

Integration direction
SAP S/4HANA
Martini
Tulip
Example Mapping
Tulip FieldCanonical FieldTarget Field
workOrderNumberworkOrderIdTable Record.workOrderId
materialNumbermaterialIdTable Record.materialId
plannedQuantityplannedQuantityTable Record.plannedQuantity
statusworkOrderStatusTable Record.status
Martini implementation pattern

A scheduled Martini workflow retrieves changed work orders, maps them to the selected Tulip Table schema, validates required fields, and performs idempotent create or update operations. Completion and exception records can be sent back to the ERP, while validation failures and transient API errors follow separate handling paths.

Martini capabilities used
  • workflow scheduling
  • API consumption
  • data mapping
  • business rules
  • idempotent writes
  • error handling

Pattern 2: Route quality inspections and nonconformances

When to use this pattern

Use this pattern when a Tulip App captures inspection results in Table Records and the organization needs quality-system or issue-management action when a result fails defined rules.

Integration direction
Tulip
Martini
ServiceNow
Example Mapping
Tulip FieldCanonical FieldTarget Field
inspectionIdinspectionIdServiceNow correlation key
resultinspectionOutcomeIncident or quality task state
defectCodenonconformanceCodeServiceNow category
stationIdworkstationIdServiceNow location context
Martini implementation pattern

Martini receives a supported Tulip webhook or polls for newly completed inspection records, validates the inspection payload, and applies thresholds or defect rules. Qualifying failures create or update a ServiceNow task, while Tulip identifiers and timestamps prevent duplicate issue creation.

Martini capabilities used
  • webhook reception
  • scheduled polling
  • data validation
  • conditional routing
  • field transformation
  • deduplication

Pattern 3: Synchronize machine events with maintenance workflows

When to use this pattern

Use this pattern when machine status or activity in Tulip should create maintenance-relevant work in ServiceNow or another enterprise service platform. It is suitable when event coverage requires polling rather than a webhook.

Integration direction
Tulip
Martini
ServiceNow
Example Mapping
Tulip FieldCanonical FieldTarget Field
machineIdassetIdServiceNow asset
eventTimestampoccurredAtIncident opened time
statusmachineStateIncident state or impact
activityCodemaintenanceReasonWork order category
Martini implementation pattern

A Martini scheduler retrieves relevant Machine data or activity records, normalizes identifiers and timestamps, and applies severity and duplicate rules. It then calls ServiceNow APIs and records the source event key so retries do not create duplicate incidents.

Martini capabilities used
  • scheduler trigger
  • API consumption
  • canonical mapping
  • business rules
  • correlation keys
  • retry handling

Pattern 4: Provision Tulip users and stations

When to use this pattern

Use this pattern when an HR, workforce, or identity system provides approved operator and organizational data for Tulip. Exact write operations and permissions must be confirmed for the target Tulip resources.

Integration direction
Workday
Martini
Tulip
Example Mapping
Tulip FieldCanonical FieldTarget Field
workerIdoperatorIdTulip User identifier
displayNameoperatorNameTulip User name
organizationworkgroupStation or operational context
activeStatususerLifecycleStateTulip User status
Martini implementation pattern

Martini retrieves approved workforce changes, validates required identity and organizational fields, and invokes the applicable Tulip User or Station APIs where supported. The workflow logs correlation identifiers, isolates permission failures, and avoids deactivating or updating resources without explicit business rules.

Martini capabilities used
  • scheduled synchronization
  • API orchestration
  • data validation
  • mapping and transformation
  • authorization-aware error handling

Applications commonly integrated with Tulip

Tulip can be connected with enterprise applications that provide planning, service, quality, workforce, issue-management, or analytics data. These are implementation-specific integrations using Tulip REST APIs, supported webhook events, and the adjacent application’s documented interfaces.

Application Scenario Direction Martini Pattern
SAP S/4HANA Synchronize production orders, materials, confirmations, and quality results between enterprise planning and Tulip frontline execution. SAP S/4HANA → Martini → Tulip Martini retrieves or receives SAP business data, maps it to Tulip Tables and Table Records, validates required fields, and performs idempotent create or update operations. Completed quantities and quality outcomes can flow back through a separate workflow.
Salesforce Exchange service, asset, customer, or case-related work information with Tulip Apps and operational records. Salesforce → Martini → Tulip A Martini workflow consumes Salesforce API data, normalizes customer or service identifiers, and writes the operational subset to Tulip. Tulip completion results can be mapped back to Salesforce with duplicate detection and retry handling.
ServiceNow Create or update incidents, work orders, and maintenance tasks from Tulip operational or machine events. Tulip → Martini → ServiceNow Martini receives a supported Tulip webhook or polls Machine and Table Record data, applies maintenance and severity rules, then calls ServiceNow APIs. Tulip identifiers and event timestamps are retained to prevent duplicate incidents.
NetSuite Synchronize work orders, inventory-related information, and completion data with Tulip Apps and Tables. NetSuite → Martini → Tulip Scheduled Martini workflows retrieve NetSuite records, transform them into Tulip Table Records, and store source-system keys for idempotent upserts. Completion and exception data can be sent back through NetSuite APIs.
Microsoft Dynamics 365 Exchange production, service, inventory, or work-order information with Tulip operational applications. Microsoft Dynamics 365 → Martini → Tulip Martini orchestrates calls to Dynamics and Tulip, maps product, order, and execution fields into a canonical model, and routes validation failures separately from transient API failures.
Jira Create engineering, quality, or operational issues from Tulip exceptions and return issue status to operational teams. Tulip → Martini → Jira Martini detects qualifying Tulip Table Records or supported events, applies issue-creation rules, and calls Jira APIs with a durable Tulip-to-Jira correlation key. Status updates can be synchronized back to Tulip.
Snowflake Replicate Tulip operational data for centralized analytics, reporting, and cross-system performance analysis. Tulip → Martini → Snowflake Martini incrementally reads paginated Tulip resources, converts payloads into an analytics-friendly structure, and writes them through the selected Snowflake ingestion architecture. Checkpoints and reconciliation workflows address missed changes.
Workday Provide selected worker and organizational data for operator provisioning, accountability, and workforce context. Workday → Martini → Tulip Martini consumes approved Workday data, validates workforce and organizational attributes, and invokes the applicable Tulip User or Station resources where the target API supports the operation. Permission and resource availability are verified per instance.

How to build a Tulip integration in Martini

Objective

Establish Tulip API access with instance-specific credentials and confirm the required resource permissions before building business logic.

Instructions in Martini

  • Create or identify the Tulip API key and secret.
  • Store credentials in Martini secrets or secure environment configuration.
  • Configure HTTP Basic Authentication for the Tulip API calls.
  • Confirm access to the required workspace, Apps, Tables, Table Records, Machines, Users, or Stations.

Objective

Select the trigger that matches the required latency and the event coverage available in the Tulip instance.

Instructions in Martini

  • Use a Tulip webhook when the required resource and event are supported.
  • Expose a Martini API for controlled inbound requests or callbacks.
  • Use a scheduler for incremental or periodic polling when webhook coverage is unavailable.
  • Define the polling window, checkpoint, and expected delivery behavior.

Objective

Read the current Tulip resource or accept the inbound event while accounting for pagination and incomplete webhook payloads.

Instructions in Martini

  • Call the relevant Tulip REST resource.
  • Process collection responses page by page.
  • Persist a cursor, timestamp, or object identifier for incremental synchronization.
  • Retrieve the current resource when a webhook payload contains only a notification.

Objective

Coordinate Tulip calls, target-system calls, transformations, and decision points in a maintainable Martini workflow.

Instructions in Martini

  • Separate authentication, retrieval, transformation, and delivery stages.
  • Use reusable workflow logic for common API and error-handling behavior.
  • Apply bounded concurrency and throttling for larger synchronizations.
  • Capture correlation identifiers without logging secrets.

Objective

Convert Tulip Apps, Tables, Table Records, Machines, Users, or Stations into the target application’s data model.

Instructions in Martini

  • Map stable Tulip identifiers to canonical integration keys.
  • Validate required fields and handle optional or absent values.
  • Apply schema-specific transformations for dates, statuses, quantities, and identifiers.
  • Version mappings when Tulip Table schemas evolve.

Objective

Decide which operational records should be created, updated, ignored, or routed for review.

Instructions in Martini

  • Apply business rules for work-order status, inspection outcomes, machine severity, or user lifecycle.
  • Use source identifiers and timestamps to enforce idempotency.
  • Separate validation failures from authorization, throttling, and transient service errors.
  • Route exceptions to an operational review process where appropriate.

Common Tulip data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
AppsFrontline applications used by operators to execute procedures and capture operational data.ERP, MES, quality platforms, service platforms, analytics storesMartini retrieves App metadata or associates App context with synchronized operational records using Tulip REST APIs.
TablesStructured Tulip data models for operational information used by Apps and workflows.ERP, MES, CRM, service-management platforms, data warehousesMartini maps external payloads to Table schemas, validates required fields, and coordinates incremental reads and writes.
Table RecordsWork orders, inspections, production events, quality results, and other individual operational data items.SAP S/4HANA, NetSuite, Microsoft Dynamics 365, Salesforce, Jira, SnowflakeMartini creates, updates, or retrieves records through applicable REST resources, using source identifiers and idempotent upsert rules.
MachinesEquipment or assets whose status, activity, and operational information is tracked.ServiceNow, enterprise asset-management platforms, maintenance systems, analytics platformsMartini polls or receives supported event data, normalizes machine identifiers and timestamps, and routes maintenance-relevant changes.
UsersTulip users and operators who interact with Apps and operational processes.Workday, identity systems, HR platforms, reporting systemsMartini can synchronize approved user attributes where the applicable Tulip resource supports the required operation and permissions.
StationsOperational locations or workstations associated with Apps, users, and machine activity.MES, workforce systems, maintenance platforms, operational reporting storesMartini maps station identifiers and organizational context, validates relationships, and synchronizes supported station data through APIs.

Authentication and security considerations

API credentials and permissions

Tulip API authentication uses an API key and API secret, commonly supplied through HTTP Basic Authentication. Credentials are instance-specific and permissions depend on the associated Tulip user or role, workspace, and resource access.

Secure Martini configuration

  • Store Tulip credentials in Martini secrets or secure environment configuration.
  • Do not embed API keys or secrets in workflow definitions, mappings, or logs.
  • Use least-privilege access for Apps, Tables, Table Records, Machines, Users, and Stations.
  • Validate and authenticate inbound webhook requests according to the Tulip event implementation.

Authentication scope

OAuth 2.0 was not confirmed as the general authentication method for Tulip REST APIs. Confirm credentials and permissions separately for each Tulip instance and deployment environment.

Operational considerations for Tulip integrations

Pagination and rate limits

Treat Tulip collection endpoints as paginated unless the specific API documentation states otherwise. Use checkpoints, bounded windows, controlled concurrency, and backoff for throttling responses.

Idempotency and event delivery

Use Tulip object IDs, source-system IDs, and durable integration keys to prevent duplicate Table Records, issues, work orders, or maintenance events. Verify webhook delivery and retry semantics for each event.

Schema and permissions

Tulip Tables and App-driven schemas can evolve. Validate required fields, handle optional values, prefer stable identifiers over display labels, and test production credentials because permissions may differ from development.

Monitoring and recovery

Log correlation identifiers, Tulip object IDs, source-system IDs, response status, and checkpoint state while excluding credentials and sensitive operational data. Separate authentication, authorization, validation, rate-limit, network, and service failures so retries are applied safely.

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

Orchestration beyond a script

Martini coordinates Tulip API calls, webhook reception, schedules, transformations, business rules, and downstream writes in explicit workflows rather than embedding all logic in a single script.

Maintainable integration assets

Reusable workflows, API definitions, mappings, secure configuration, and controlled error paths make it easier to support multiple Tulip instances and enterprise targets without duplicating point-to-point logic.

Reliable synchronization

Martini provides a structured place to implement pagination, checkpoints, idempotency, throttling, retries, validation, and monitoring for operational data that must move reliably between Tulip and other systems.

Controlled APIs

Martini can expose APIs for enterprise systems that need to submit data to or retrieve normalized information from Tulip, allowing inbound access to be governed separately from Tulip’s native API credentials.

Frequently asked questions

How can Tulip be integrated with enterprise systems?

Tulip can be integrated through its REST APIs, which expose platform and operational resources such as Apps, Tables, Table Records, Machines, Users, and Stations. Tulip also supports webhook-style notifications for selected events and use cases. Scheduled, paginated synchronization is appropriate when the required event is not available.

Can Martini integrate with Tulip?

Yes. Martini can consume Tulip REST APIs, receive supported Tulip webhook or callback events through Martini APIs, schedule incremental synchronization workflows, transform data, and connect Tulip operational information to enterprise applications.

Do I need a connector to integrate Tulip with Martini?

No. A dedicated Tulip connector is not required. Martini can integrate using Tulip’s confirmed native REST APIs, selected webhook mechanisms, API key and API secret authentication, and scheduled workflows.

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

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

Which Tulip integration methods should an implementation use?

Tulip REST APIs are the primary integration method for Apps, Tables, Table Records, Machines, Users, and Stations. Webhook-style notifications are a secondary option for selected events. General GraphQL and SOAP APIs were not confirmed, and direct database access should not be assumed.

Can Tulip send events or webhooks to Martini?

Tulip supports webhook-style integrations for selected events and use cases. Coverage is not universal, so the specific resource, event, payload, authentication model, retry behavior, and delivery semantics must be verified. Martini can expose a secured API endpoint and process supported notifications.

How should Tulip data synchronization work?

Use scheduled or event-driven Martini workflows with paginated API requests, incremental checkpoints, bounded time windows, throttling, retries with backoff, and periodic reconciliation. Tulip object IDs, source-system IDs, and durable integration keys should be used for idempotent writes.

How does Martini handle Tulip mapping, errors, and duplicate events?

Martini maps Tulip payloads to canonical and target models, validates required fields, applies business rules, and separates permanent validation or permission failures from transient errors. Correlation keys, Tulip identifiers, checkpoints, and retry policies help prevent duplicate processing and support recovery.

Related Martini documentation

APIs

Webhooks

Workflows

Security

Operations

Connect Tulip with your enterprise systems

Use Martini to build secure, maintainable Tulip integrations around REST APIs, supported webhook events, scheduled synchronization, data mapping, and enterprise workflow orchestration.

EXPLORE MARTINI
BOOK A DEMO