Ellipse Gradient for Header

Dataiku Integration Guide

Integrate Dataiku DSS with enterprise systems through REST APIs, selected scenario webhook triggers, asynchronous jobs, and governed Martini workflows.

Dataiku integration options at a glance

Dataiku DSS provides documented REST APIs for working with projects, datasets, recipes, scenarios, jobs, models, deployments, and other platform resources. Selected scenario automations can be initiated through webhook-style HTTP triggers, while many operations run asynchronously and return execution identifiers for later status checks. Dataiku also supports connection-based access to databases and analytical platforms, plus resource-specific file and dataset operations. Martini can consume these APIs, securely manage Dataiku API keys, invoke scenario triggers, poll job status, transform payloads, and expose controlled APIs around Dataiku operations. Exact resource coverage depends on the DSS version, enabled components, and deployment topology.

Integration pointSupported by Dataiku?Common use casesHow Martini supports it
REST APIsYesManage or inspect Projects, Datasets, Recipes, Scenarios, Models, jobs, deployments, and API services; retrieve metadata or supported data and start operations.Martini can consume Dataiku DSS REST APIs, generate reusable API integration assets from definitions where available, map responses, and expose APIs that wrap Dataiku operations.
Webhooks / outbound callbacksLimitedInvoke selected Dataiku Scenarios through HTTP-triggered endpoints. Coverage is selective and is not a universal outbound event stream for all Dataiku objects.Martini can call Dataiku scenario webhook endpoints and can expose a REST API for custom callbacks from Dataiku or another system.
Bulk / async / batch APIsLimitedStart jobs, scenario executions, dataset builds, and other long-running operations that may return before processing completes.Martini can persist execution identifiers, poll status, apply timeout and retry rules, and route successful, failed, canceled, or abandoned executions.
File / attachment APIsLimitedExchange supported files, dataset data, model or bundle artifacts, scenario inputs, outputs, and project or deployment packages where the specific resource and deployment support them.Martini can orchestrate resource-specific file operations and transform or stage payloads, while avoiding assumptions about a universal Dataiku file-transfer endpoint.
Database / analytics accessLimitedDataiku can use configured database and analytics-platform connections through DSS datasets. This is connection-based access rather than a general Dataiku SQL endpoint.Martini can call Dataiku APIs or connect independently to an underlying database when network access, credentials, and supported database protocols are available.
AuthenticationYesAuthenticate programmatic DSS access with API keys associated with users, service accounts, projects, API services, or governed deployments.Martini stores API keys and related credentials in secure environment configuration and applies least-privilege service identities to workflow calls.
SDKs and client librariesLimitedDataiku provides supported client libraries, including Python-based interaction with DSS, for development use cases.Martini generally uses documented HTTP APIs; custom JVM-compatible logic can be added for specialized clients or transformations when necessary.

How Dataiku exposes data and business events

Dataiku REST APIs

Dataiku DSS exposes REST APIs for administration and automation across projects, datasets, scenarios, jobs, deployments, models, API services, and other resources. Exact endpoints and availability depend on the DSS version, enabled components, and deployment topology.

Martini implementation pattern

Martini implementation pattern: Martini authenticates with a least-privilege Dataiku API key, calls the required REST endpoint, validates the response, maps Dataiku objects to an internal or target model, and routes authentication, permission, transport, and business errors separately.

Implementation sequence

Authenticate with a Dataiku API key stored in secure configuration
Call the version-appropriate Dataiku REST endpoint
Validate the response and required fields
Map the Dataiku object to the target data model
Write the result or invoke the next workflow step
Record the request, resource, and outcome without exposing credentials

Dataiku scenario triggers

Dataiku supports webhook-style HTTP triggers for selected Scenario automation use cases. These triggers are useful for starting processing from an external event, but they should not be treated as a universal outbound event stream for every Dataiku object.

Martini implementation pattern

Martini implementation pattern: Martini receives or creates the business event, validates its source and identifier, invokes the Dataiku Scenario trigger, and persists the returned execution information for later monitoring or notification.

Implementation sequence

Receive the source event or API request
Validate the business identifier and required inputs
Invoke the selected Dataiku Scenario trigger
Store the returned execution or request identifier
Poll or otherwise monitor the Scenario outcome
Route completion, failure, timeout, and duplicate requests separately

Dataiku asynchronous jobs

Many Dataiku operations are job-oriented and may return an acceptance response before processing finishes. Scenario runs, dataset builds, and other operations can require status monitoring and explicit handling of success, failure, cancellation, or timeout.

Martini implementation pattern

Martini implementation pattern: A Martini workflow starts the Dataiku operation, stores its execution identifier, waits through scheduled polling or a controlled retry loop, and publishes a final status only after the documented completion state is reached.

Implementation sequence

Submit the Dataiku job or Scenario execution
Persist the returned execution identifier
Wait for the configured polling interval
Retrieve the current execution status
Apply timeout and retry limits
Publish the final status and route failures for remediation

Dataiku datasets and files

Dataiku supports dataset-oriented and file-oriented operations through relevant APIs and configured connections. Available operations depend on the resource, connection type, DSS version, and deployment configuration, so large transfers should be designed carefully.

Martini implementation pattern

Martini implementation pattern: Martini coordinates supported dataset or file operations, uses pagination or staged storage when appropriate, validates schema and freshness, and passes only the required data to downstream systems.

Implementation sequence

Identify the supported dataset or file operation
Authenticate and verify resource permissions
Retrieve, stage, or submit the data using the supported interface
Validate schema, freshness, and payload size
Transform the data for the target system
Record transfer status and retry only safe operations

Common Dataiku integration patterns

Pattern 1: Trigger a Dataiku scenario from an operational system

When to use this pattern

Use this pattern when a Salesforce, ServiceNow, or internal business event should start feature preparation, scoring, data-quality validation, reconciliation, or another Dataiku Scenario. It is appropriate when the operational system needs a controlled initiation path without direct exposure to Dataiku credentials or project details.

Integration direction
Operational application
Martini
Dataiku
Example Mapping
Dataiku FieldCanonical FieldTarget Field
eventIdsourceEventIdscenarioInput.eventId
customerIdbusinessObjectIdscenarioInput.customerId
eventTypeprocessTypescenarioInput.processType
requestedAtrequestTimestampscenarioInput.requestedAt
Martini implementation pattern

Martini exposes or consumes an event endpoint, validates the source event and business key, checks for an existing equivalent execution, and calls the selected Dataiku Scenario webhook or REST endpoint. It stores the execution identifier and uses a separate polling path to route successful results, failures, and timeouts without launching duplicate processing.

Martini capabilities used
  • APIs
  • workflows
  • authentication and secrets
  • data mapping
  • business rules
  • asynchronous orchestration
  • error handling

Pattern 2: Publish Dataiku scoring results to Salesforce

When to use this pattern

Use this pattern when Dataiku predictions, classifications, propensity scores, or data-quality outcomes must be written to Salesforce Accounts, Contacts, Leads, or Opportunities. It separates analytical processing from the operational write and allows validation before customer-facing data changes.

Integration direction
Dataiku
Martini
Salesforce
Example Mapping
Dataiku FieldCanonical FieldTarget Field
predictionscoreDataiku_Score__c
classificationriskClassRisk_Class__c
modelVersionmodelVersionScoring_Model_Version__c
executionIdsourceExecutionIdDataiku_Execution_Id__c
Martini implementation pattern

Martini retrieves a Dataiku API-service response, dataset result, or completed job output, validates the model version and business key, maps the result to Salesforce fields, and performs an idempotent update. Failed Dataiku executions and Salesforce write errors are recorded separately so they can be retried without rerunning valid analytical work.

Martini capabilities used
  • API consumption
  • data mapping
  • validation
  • business rules
  • workflow orchestration
  • retry and error routing

Pattern 3: Coordinate scheduled Dataiku data preparation

When to use this pattern

Use this pattern when Dataiku processing must align with an enterprise batch window or when downstream systems must wait for a confirmed dataset or model result. It is useful for recurring preparation, reporting refreshes, reconciliation, and coordinated operational updates.

Integration direction
Martini
Dataiku
Snowflake
Example Mapping
Dataiku FieldCanonical FieldTarget Field
scenarioNameprocessNameDataiku Scenario
executionIdrunIdbatch_run_id
statusprocessingStatusrun_status
completedAtcompletionTimestampcompleted_at
Martini implementation pattern

A scheduled Martini workflow starts the Dataiku Scenario or job, persists its execution identifier, polls according to a controlled interval, and checks that the output is fresh before notifying or updating downstream systems. It limits concurrency, prevents duplicate launches, and routes timeout or job failure to operational handling rather than treating an accepted request as success.

Martini capabilities used
  • scheduler triggers
  • workflows
  • REST API consumption
  • state persistence
  • conditional routing
  • monitoring
  • error handling

Pattern 4: Expose a governed API façade around Dataiku

When to use this pattern

Use this pattern when internal applications need a business-level scoring or analytics request but should not receive direct access to Dataiku credentials, project identifiers, or deployment details. It provides a controlled contract that can remain stable while Dataiku implementation details evolve.

Integration direction
Business application
Martini
Dataiku
Example Mapping
Dataiku FieldCanonical FieldTarget Field
customerIdsubjectIdDataiku request subject
requestedModelmodelNameAPI service or model endpoint
channelrequestChannelDataiku request context
scoreresultValuebusiness response.score
Martini implementation pattern

Martini exposes a secured REST API, validates and normalizes the business request, selects the permitted Dataiku project or API service, and transforms the response into a controlled contract. It masks internal details, applies authorization and rate controls, and returns a correlation identifier when Dataiku processing is asynchronous.

Martini capabilities used
  • API exposure
  • authentication and authorization
  • validation
  • data mapping
  • business rules
  • workflow orchestration
  • error handling

Applications commonly integrated with Dataiku

Dataiku is commonly positioned between enterprise data platforms, operational applications, and reporting tools. Martini can orchestrate these integrations while keeping authentication, transformation, asynchronous execution, and error handling in a reusable workflow layer.

Application Scenario Direction Martini Pattern
Salesforce Apply Dataiku predictions, segmentation, propensity scores, and data-quality results to Accounts, Contacts, Leads, or Opportunities. Salesforce → Martini → Dataiku Martini receives a Salesforce event or scheduled request, validates the business key, invokes Dataiku REST APIs or an API service, and maps the result back to Salesforce through its APIs.
ServiceNow Enrich Incidents, Cases, and operational records with classification, prioritization, anomaly, or risk results. ServiceNow → Martini → Dataiku A Martini workflow retrieves the ServiceNow payload, submits the relevant request to Dataiku, waits for asynchronous completion where required, and writes the result back to ServiceNow with retry and duplicate protection.
Snowflake Coordinate feature preparation, data ingestion, model training, and result publication between Snowflake and Dataiku. Snowflake → Dataiku → Martini Martini orchestrates Dataiku jobs and downstream notifications while Dataiku uses its configured Snowflake connection for datasets; direct Snowflake access can be used when connectivity and credentials are available.
Amazon S3 Exchange source files, intermediate datasets, model artifacts, or exported results through configured storage connections. Amazon S3 → Dataiku → Martini Martini coordinates the Dataiku workflow and any supported file or dataset operation, using staged files or asynchronous processing for larger artifacts rather than assuming a universal Dataiku file-transfer API.
SAP S/4HANA Use operational data for analytics and return selected predictions or classifications to finance, supply-chain, or customer processes. SAP S/4HANA → Martini → Dataiku Martini consumes supported SAP APIs, maps business data into a Dataiku request or dataset process, monitors execution, and returns approved results to SAP through its supported interfaces.
Tableau Publish or refresh analytical outputs and make Dataiku-generated datasets available for reporting. Dataiku → Martini → Tableau Martini coordinates Dataiku completion and publication events, transforms metadata or result payloads, and invokes the selected Tableau publication or refresh interface where available.
Microsoft Power BI Deliver curated datasets, predictions, and metrics for operational and executive reporting. Dataiku → Martini → Microsoft Power BI A scheduled Martini workflow starts or monitors Dataiku processing, validates dataset freshness, and coordinates the downstream Power BI refresh or publication mechanism confirmed for the tenant.
Jira Use Dataiku results for issue prioritization, quality monitoring, or data and model pipeline remediation workflows. Dataiku → Martini → Jira Martini maps Dataiku job outcomes or anomaly results to Jira issue fields, applies deduplication using an execution or business identifier, and creates or updates issues through Jira REST APIs.

How to build a Dataiku integration in Martini

Objective

Establish access to the target Dataiku DSS, API node, or other deployment component using the authentication method documented for the selected endpoint.

Instructions in Martini

  • Create a dedicated Dataiku service identity or API key with least-privilege permissions
  • Store the key and endpoint configuration in Martini secure environment configuration
  • Confirm network access, TLS, proxy, VPN, or allowlist requirements
  • Verify that the identity can access the required Projects, Datasets, Scenarios, jobs, or API services

Objective

Select the event, API request, or schedule that should initiate the integration and define the correlation and idempotency identifiers.

Instructions in Martini

  • Use an inbound API or application event when processing is business-event driven
  • Use a Dataiku Scenario trigger when an external system should initiate selected Dataiku automation
  • Use a Martini scheduler when processing must align with a batch window
  • Define a source event ID, business key, or request ID for duplicate prevention

Objective

Call the appropriate Dataiku REST endpoint, Scenario trigger, dataset operation, or API service and capture the response needed for subsequent processing.

Instructions in Martini

  • Call the version-appropriate Dataiku endpoint
  • Validate HTTP status, response structure, and required identifiers
  • Persist job, Scenario, or execution identifiers when processing is asynchronous
  • Use pagination, staging, or supported file operations for larger data volumes

Objective

Coordinate synchronous and asynchronous steps so that Dataiku completion is distinguished from request acceptance and downstream actions occur in the correct order.

Instructions in Martini

  • Poll asynchronous execution status at a controlled interval
  • Set maximum wait times and retry limits
  • Route success, failure, cancellation, and timeout states separately
  • Prevent concurrent duplicate Scenario launches or duplicate result publication

Objective

Transform Dataiku Projects, Datasets, model outputs, or API-service responses into the canonical and target-system structures required by the business process.

Instructions in Martini

  • Map explicit field names rather than relying on column order
  • Validate required fields, model version, dataset freshness, and business identifiers
  • Normalize JSON, files, or dataset payloads before downstream writes
  • Apply conditional rules for target-specific classifications and status values

Objective

Publish validated Dataiku outputs to applications, databases, files, reporting platforms, or another API while preserving traceability.

Instructions in Martini

  • Write only after the Dataiku processing state is confirmed
  • Use target-system APIs or supported database and file protocols
  • Include correlation and execution identifiers where target schemas allow
  • Make downstream writes idempotent using business or execution keys

Common Dataiku data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ProjectsContainer for datasets, recipes, notebooks, scenarios, dashboards, models, and project-level configuration.Data warehouses, governance systems, reporting platforms, and operational applicationsMartini retrieves project metadata through REST APIs, validates project permissions, and uses project identifiers to scope subsequent operations.
DatasetsStructured data assets used by recipes, models, visual analyses, and workflows.Snowflake, Amazon S3, SAP S/4HANA, Tableau, Microsoft Power BI, and databasesMartini retrieves supported metadata or data, coordinates builds and exports, and validates freshness, schema, pagination, and payload size before mapping.
RecipesProcessing definitions that transform or combine datasets.Data warehouses, data-quality systems, reporting platforms, and downstream APIsMartini can inspect or orchestrate recipe-related operations through documented endpoints and route failures separately from transport errors.
ScenariosAutomations that execute jobs, build flows, send notifications, and run actions from schedules or triggers.Enterprise applications, notification services, monitoring platforms, and databasesMartini invokes selected scenario triggers, stores execution identifiers, polls status, prevents duplicate launches, and publishes completion outcomes.
Models and model versionsTrained machine-learning assets and versions that can be evaluated, deployed, or consumed through APIs.Salesforce, ServiceNow, SAP S/4HANA, customer portals, and operational databasesMartini invokes supported model or API-service operations, maps predictions and classifications, and applies validation and idempotent writes.
API services and endpointsDeployed prediction or business-logic services exposed through Dataiku API nodes or related deployment infrastructure.Salesforce, ServiceNow, customer portals, internal applications, and Martini APIsMartini authenticates to the relevant deployment endpoint, transforms business requests, handles endpoint-specific responses, and separates deployment or permission failures.

Authentication and security considerations

API keys and service identities

Dataiku DSS commonly uses API keys for programmatic access. Keys may be associated with a user, project, service account, API service, API node, or governed deployment, so the required identity depends on the endpoint and topology.

Least-privilege access

Use a dedicated service identity with only the permissions required for the relevant Projects, Datasets, Recipes, Scenarios, jobs, models, deployments, or API services. Network reachability alone does not establish authorization.

Secret management

  • Store Dataiku API keys and endpoint credentials in Martini secure environment configuration.
  • Separate development, test, and production credentials.
  • Plan for key rotation, expiration, revocation, and auditability.
  • Do not place secrets in mappings, URLs, source code, or logged payloads.

Deployment boundaries

Confirm whether the target is a design node, automation node, API node, or another deployment component. Resource availability and permissions can differ across Dataiku deployment topologies.

Operational considerations for Dataiku integrations

Asynchronous execution

Many Dataiku operations start jobs or Scenarios and return before processing completes. Persist execution identifiers, poll deliberately, set timeouts, and distinguish accepted, running, successful, failed, canceled, and abandoned states.

Pagination and payload size

List endpoints may paginate Projects, Datasets, jobs, deployments, or other resources. Large datasets and artifacts should use supported staging, files, pagination, or asynchronous mechanisms rather than oversized synchronous requests.

Retries and idempotency

Coordinate retries with Dataiku job state so a transient HTTP failure does not launch duplicate processing. Use source event IDs, business keys, or execution IDs to prevent duplicate Scenario runs and downstream writes.

Rate and workload control

An API request may be lightweight while the resulting Dataiku job consumes substantial compute and storage. Limit concurrency and avoid repeatedly starting equivalent Scenarios.

Schema and freshness

Projects, Datasets, Recipes, and model outputs can evolve. Use explicit mappings, validate required fields and output freshness, and avoid relying on undocumented fields or column order.

Testing and observability

Test against the intended DSS version and deployment component. Capture correlation IDs, Dataiku execution IDs, response status, and sanitized error details in Martini logs without exposing credentials.

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

Reusable orchestration

Martini provides a workflow layer for receiving events, calling Dataiku APIs, coordinating asynchronous execution, applying business rules, and publishing results to multiple enterprise systems.

Controlled API exposure

Martini can expose a governed business-level API so applications do not need direct access to Dataiku credentials, project identifiers, or internal deployment details.

Explicit transformation

Mappings and validation keep Dataiku Dataset structures, model outputs, and Scenario results separate from target application schemas. This reduces coupling as projects and downstream systems change.

Operational reliability

Centralized retries, timeout handling, duplicate prevention, error routing, logging, and environment-specific configuration are easier to maintain than scattered scripts or point-to-point calls.

Flexible integration boundaries

Martini can consume REST APIs, invoke selected webhook triggers, connect to supported databases or files when appropriate, and add custom JVM-compatible logic when a specialized transformation is required.

Frequently asked questions

How can Dataiku be integrated with enterprise systems?

Dataiku DSS can be integrated through its documented REST APIs, selected Scenario webhook-style triggers, asynchronous job and dataset operations, and configured connections to databases or analytical platforms. Martini can orchestrate these calls, transform data, monitor execution, and expose controlled APIs around Dataiku operations.

Can Martini integrate with Dataiku?

Yes. Martini can integrate with Dataiku by consuming the Dataiku DSS REST API, invoking selected Scenario webhook endpoints, monitoring asynchronous jobs, handling supported dataset or file operations, and exposing APIs that wrap Dataiku services. A dedicated native Martini Dataiku connector was not confirmed.

Do I need a connector to integrate Dataiku with Martini?

No. A dedicated Dataiku connector is not required. Martini can use Dataiku's confirmed native integration mechanisms, including REST APIs, selected Scenario triggers, API-key authentication, asynchronous execution, and supported data or file operations.

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

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

Which Dataiku integration methods should architects use?

The primary approach is the documented Dataiku DSS REST API. Selected Scenario webhook triggers are useful for initiating automation, while asynchronous job and dataset operations should be used when the Dataiku endpoint supports them. Dataiku GraphQL and SOAP APIs were not confirmed, so REST should be preferred.

Does Dataiku provide webhooks or outbound events?

Dataiku supports webhook-style HTTP triggers for selected Scenario automation use cases. This is limited coverage rather than a universal outbound event stream for every Project, Dataset, Model, or other object. Martini can also expose an inbound REST API for custom callbacks.

How does synchronization with Dataiku work?

Martini can run event-driven or scheduled workflows that call Dataiku, start a Scenario or job, store the execution identifier, poll status, and publish results after confirmed completion. Pagination, dataset freshness, schema validation, duplicate prevention, and downstream idempotency should be designed for each flow.

How are Dataiku data mapping and errors handled?

Martini maps Dataiku objects and model outputs to canonical and target schemas, validates required fields, and applies business rules before writes. Workflows can distinguish transport, authentication, permission, validation, Dataiku execution, and downstream errors, with controlled retries and correlation identifiers.

Related Martini documentation

Dataiku APIs

Workflows

Mapping

Security

Operations

Coordinate Dataiku integrations with Martini

Use Martini to connect Dataiku DSS with enterprise applications, orchestrate asynchronous analytics workflows, and expose governed APIs for downstream consumers.

EXPLORE MARTINI
BOOK A DEMO