.png)
DataRobot Integration Guide
Integrate DataRobot with enterprise systems through REST APIs, batch prediction workflows, file exchange, and controlled model-operations orchestration.
DataRobot integration options at a glance
DataRobot’s primary integration mechanism is its REST API, which supports projects, datasets, models, deployments, prediction jobs, and other platform resources. DataRobot also supports asynchronous and batch prediction workflows, while dataset and scoring processes can use uploaded files or external data locations depending on the product and deployment configuration. Notification or webhook-style capabilities may be available for selected events, but broad coverage is not confirmed. Martini can consume these APIs, manage API-key authentication, orchestrate long-running jobs, validate and transform data, poll statuses, exchange files, and expose a normalized API for downstream applications.
| Integration point | Supported by DataRobot? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage Projects, Datasets, Models, Deployments, Prediction jobs, users, and other DataRobot platform resources; invoke real-time predictions and retrieve operational information. | Martini can consume documented DataRobot REST endpoints from workflows, map requests and responses, and expose a controlled API façade. |
| Bulk / async / batch APIs | Yes | Submit large-scale or decoupled batch prediction jobs, poll job status, and retrieve prediction outputs. | Martini can persist job identifiers, poll with bounded intervals and timeouts, and route success, failure, cancellation, and timeout outcomes. |
| File / attachment APIs | Limited | Use uploaded files or externally stored data in dataset and batch-prediction workflows; supported formats and storage options vary by environment. | Martini can receive, validate, transform, upload, register, and forward files where the target DataRobot product supports the selected exchange pattern. |
| Webhooks / outbound callbacks | Limited | Use notification or monitoring capabilities for selected supported events or product areas; universal lifecycle coverage is not confirmed. | Martini can receive confirmed notifications, but should use scheduled polling and reconciliation for events without reliable callback coverage. |
| Database / analytics access | Limited | Connect DataRobot to selected external data sources or cloud storage where enabled by the product and deployment configuration. | Martini can orchestrate database or storage endpoints separately from DataRobot and should not assume a general-purpose DataRobot database API. |
| Authentication | Yes | Authenticate REST requests with an API key in the X-DataRobot-API-Key header, subject to user, service-account, organization, project, and deployment permissions. | Martini can store keys in secrets or protected environment configuration and inject them into outbound requests without embedding credentials in workflows. |
| SDKs | Yes | Use DataRobot client libraries, including the commonly used Python client, for product-specific programmatic behavior. | Martini integrations should generally prefer REST for interoperability; custom JVM-compatible code can be considered when a client-library-specific behavior is required. |
| GraphQL APIs | Not confirmed | No general-purpose DataRobot GraphQL API was confirmed in the supplied research. | Martini should use the documented REST API rather than assume GraphQL support. |
| SOAP APIs | Not confirmed | No DataRobot SOAP API was confirmed; new integrations should use REST APIs. | Martini should not design a SOAP-based DataRobot integration without product-specific confirmation. |
How DataRobot exposes data and business events
DataRobot REST APIs
DataRobot’s REST APIs are the principal programmatic mechanism for managing Projects, Datasets, Models, Deployments, Prediction jobs, and related platform resources. They also support prediction invocation and retrieval of operational information.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with the DataRobot API-key header, calls the required endpoint, validates and transforms the response, applies business rules, and writes or returns the result to the consuming system.
Implementation sequence
DataRobot Batch Prediction
DataRobot supports asynchronous and batch prediction patterns for large-scale or decoupled scoring. A typical process prepares or references input data, submits a prediction job, polls its status, and retrieves or processes the output.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow validates input data, submits the batch job, stores its identifier, polls at a controlled interval, and routes completed results or failure states independently.
Implementation sequence
DataRobot Files and Data Connections
Dataset and batch-prediction workflows can use uploaded files or external data locations, with exact formats and storage options depending on the DataRobot product and deployment configuration.
Martini implementation pattern
Martini implementation pattern: a workflow receives or locates the source file, validates encoding and structure, transfers or registers it through the supported DataRobot path, and preserves source and job lineage for recovery.
Implementation sequence
DataRobot Notifications and Polling
DataRobot notification or webhook-style capabilities may cover selected events or product areas, but broad webhook coverage is not confirmed. Reliable synchronization should use REST polling and reconciliation where necessary.
Martini implementation pattern
Martini implementation pattern: Martini receives confirmed notifications where available and otherwise schedules REST queries using timestamps, status fields, identifiers, and idempotent reconciliation logic.
Implementation sequence
Common DataRobot integration patterns
Pattern 1: Run scheduled batch scoring
When to use this pattern
Use this pattern for periodic risk scoring, churn scoring, demand forecasting, or other large-volume use cases. It separates input preparation, DataRobot job execution, and downstream result delivery so each stage can be retried independently.
Integration direction
Example Mapping
| DataRobot Field | Canonical Field | Target Field |
|---|---|---|
| customer_id | subjectId | predictionInput.customerId |
| as_of_date | scoringDate | predictionInput.asOfDate |
| risk_score | predictionValue | predictionOutput.riskScore |
Martini implementation pattern
A scheduler-triggered Martini workflow retrieves new data, validates the deployment schema, submits one batch prediction job with a deterministic processing key, polls until completion, and writes normalized results to the target warehouse. Transport failures and downstream write failures use separate retry paths.
Martini capabilities used
- workflow scheduling
- API consumption
- file and data handling
- data mapping
- business rules
- error handling
- monitoring
Pattern 2: Expose a real-time prediction façade
When to use this pattern
Use this pattern when applications need a stable business API instead of direct dependency on a DataRobot deployment contract. Martini centralizes validation, authorization, correlation, response mapping, and operational logging.
Integration direction
Example Mapping
| DataRobot Field | Canonical Field | Target Field |
|---|---|---|
| customerId | subjectId | deploymentInput.customer_id |
| annualSpend | customerValue | deploymentInput.annual_spend |
| prediction | score | response.score |
Martini implementation pattern
Martini exposes a REST API, validates the request, maps it to the DataRobot deployment input schema, invokes the prediction endpoint, and returns a normalized response. Invalid input is rejected before the DataRobot call, while transient failures receive bounded retries and a correlation-aware error response.
Martini capabilities used
- API exposure
- API consumption
- authentication and authorization
- data mapping
- validation
- business rules
- error handling
Pattern 3: Orchestrate model and deployment lifecycle
When to use this pattern
Use this pattern to coordinate DataRobot model or deployment metadata with enterprise release approvals and environment promotion processes. Exact lifecycle operations must match the documented API available in the target DataRobot environment.
Integration direction
Example Mapping
| DataRobot Field | Canonical Field | Target Field |
|---|---|---|
| deploymentId | modelDeploymentId | ServiceNow configuration reference |
| deploymentStatus | releaseState | ServiceNow approval state |
| modelVersionId | modelVersion | release record.modelVersion |
Martini implementation pattern
A Martini workflow retrieves model and deployment metadata, verifies required identifiers and configuration, applies approval rules, and creates or updates the corresponding ServiceNow record. Stable IDs and environment mappings prevent display-name collisions, while failed API calls are retried without duplicating approval records.
Martini capabilities used
- workflow orchestration
- REST API consumption
- data mapping
- business rules
- idempotent upsert
- error handling
Pattern 4: Reconcile monitoring exceptions
When to use this pattern
Use this pattern when monitoring or operational metrics must trigger incidents, notifications, or model review actions. Polling is appropriate where a reliable callback is not confirmed.
Integration direction
Example Mapping
| DataRobot Field | Canonical Field | Target Field |
|---|---|---|
| deploymentId | assetId | incident.configurationItem |
| metricValue | observedValue | incident.description |
| threshold | approvedLimit | incident.customFields.threshold |
Martini implementation pattern
A scheduled workflow queries supported monitoring information, compares values with approved thresholds, and creates or updates a ServiceNow incident while notifying Slack for material exceptions. The workflow stores the last observation and uses an idempotency key so repeated polls do not create duplicate incidents.
Martini capabilities used
- scheduled workflows
- REST API consumption
- threshold rules
- data transformation
- idempotency
- notifications
- monitoring
Applications commonly integrated with DataRobot
DataRobot is commonly positioned alongside enterprise data platforms, storage services, operational applications, and notification tools. Martini can coordinate these systems with DataRobot through their respective APIs, files, or supported storage interfaces while keeping mappings, credentials, retries, and business rules in reusable workflows.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Snowflake | Supply training, analytical, and scoring data to DataRobot or store prediction outputs for downstream analytics. | Snowflake → Martini → DataRobot | Use a scheduled workflow to retrieve or stage data, validate the DataRobot input contract, submit a dataset or prediction job, and write results or metadata back to Snowflake. |
| Amazon S3 | Exchange training files, batch-prediction inputs, and prediction outputs at scale. | Amazon S3 → Martini → DataRobot | Coordinate object discovery, file validation, DataRobot job submission, status polling, and result delivery while using deterministic object keys to avoid duplicate processing. |
| Microsoft Azure Blob Storage | Store datasets and batch-scoring files for DataRobot workflows hosted in Azure environments. | Microsoft Azure Blob Storage → Martini → DataRobot | Use environment-specific storage configuration, transform or validate files in a workflow, submit them through the supported DataRobot path, and route outputs to downstream storage. |
| Databricks | Use lakehouse data for model development or return predictions to analytical and operational pipelines. | Databricks → Martini → DataRobot | Read prepared data through the available Databricks interface, map it to the deployment schema, invoke DataRobot processing, and persist prediction results with job lineage. |
| Salesforce | Enrich customer, account, or lead workflows with predictions such as propensity, churn, or lead scoring. | Salesforce → Martini → DataRobot | Expose or schedule a workflow that retrieves Salesforce data, calls a DataRobot deployment, maps prediction values, and updates Salesforce with correlation and error handling. |
| ServiceNow | Create incidents or operational tasks from model-monitoring exceptions and coordinate operational responses. | DataRobot → Martini → ServiceNow | Poll monitoring information, apply threshold rules, and create or update ServiceNow incidents idempotently, with retries for transient API failures. |
| Slack | Notify data-science or operations teams about completed jobs, deployment changes, or monitoring exceptions. | DataRobot → Martini → Slack | Use a workflow to classify terminal job or monitoring states, format a concise notification, and send it through the relevant Slack API or webhook. |
| Tableau | Publish prediction results or monitoring data for business dashboards and operational reporting. | DataRobot → Martini → Tableau | Persist normalized predictions or monitoring results in a shared warehouse, database, or file exchange and expose a stable dataset for Tableau consumption. |
How to build a DataRobot integration in Martini
Objective
Configure the DataRobot base URL and authenticate requests with an API key associated with an appropriately permissioned user or service account.
Instructions in Martini
- Store the base URL by environment.
- Store the X-DataRobot-API-Key value in Martini secrets or protected configuration.
- Keep credentials out of mappings, logs, source control, and error payloads.
- Confirm organization, project, deployment, and service permissions.
Objective
Select a trigger that matches the integration’s timing and reliability requirements, such as an API request, scheduler, confirmed notification, or reconciliation workflow.
Instructions in Martini
- Use a REST API trigger for real-time façade requests.
- Use a scheduler for batch scoring and reconciliation.
- Treat webhook-style notifications as selected-event capabilities only.
- Define correlation and idempotency keys before processing.
Objective
Receive or retrieve the source payload, file, dataset, model metadata, deployment metadata, or prediction-job state required by the workflow.
Instructions in Martini
- Call the documented DataRobot REST endpoint.
- Handle pagination for collection resources.
- Persist DataRobot object and job identifiers.
- Validate that the resource belongs to the expected environment.
Objective
Coordinate DataRobot operations and downstream systems as a stateful workflow, especially for asynchronous jobs and multi-step lifecycle operations.
Instructions in Martini
- Submit long-running jobs once.
- Persist the returned job identifier.
- Poll with a controlled interval and timeout.
- Route success, failure, cancellation, and timeout states separately.
Objective
Transform source data into the DataRobot deployment or batch input contract and normalize DataRobot responses for downstream consumers.
Instructions in Martini
- Validate required fields, types, nullability, and categorical values.
- Map only the response fields required downstream.
- Version mappings when model input contracts change.
- Preserve original responses when auditability is required.
Objective
Apply thresholds, approval requirements, duplicate checks, environment mappings, and routing decisions before writing results or raising operational actions.
Instructions in Martini
- Use deterministic business keys for duplicate prevention.
- Do not identify models or deployments only by display name.
- Separate validation errors from DataRobot job failures.
- Apply monitoring thresholds before creating incidents or notifications.
Common DataRobot data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Projects | Contain datasets, modeling configuration, experiments, and generated models. | Data warehouses, release systems, operational databases | Martini retrieves project metadata through REST APIs, stores stable identifiers, and maps project state into internal lifecycle or reporting models. |
| Models | Represent trained or imported machine-learning models associated with projects or deployments. | Release-management systems, data catalogs, monitoring stores | Martini synchronizes model metadata using documented identifiers and applies environment-specific business rules before downstream publication. |
| Deployments | Provide production or operational endpoints used to generate predictions and monitor model behavior. | Salesforce, ServiceNow, APIs, operational databases | Martini invokes deployment endpoints, validates input contracts, maps prediction responses, and records deployment identifiers by environment. |
| Datasets | Provide training, scoring, or analytical data uploaded to or referenced by DataRobot. | Snowflake, Amazon S3, Azure Blob Storage, Databricks | Martini validates schemas and file characteristics, transfers or registers data through supported paths, and records processing lineage. |
| Prediction jobs | Represent batch or asynchronous scoring operations submitted to DataRobot. | Data warehouses, object storage, CRM platforms, operational applications | Martini submits jobs once, persists job IDs, polls controlled intervals, handles terminal states, and delivers outputs idempotently. |
| Use Cases | Group related AI assets within the DataRobot platform for organizational management. | Governance systems, catalogs, reporting databases | Martini can query and synchronize Use Case metadata where supported by the target API version, using pagination and stable identifiers. |
Authentication and security considerations
API-key authentication
DataRobot REST access commonly uses an API key in the X-DataRobot-API-Key request header. The key is associated with a user or service account and is constrained by DataRobot permissions.
Secret storage
Store API keys and environment-specific base URLs in Martini secrets or protected configuration. Do not embed credentials in workflow definitions, mappings, source control, logs, or error payloads.
Authorization and environments
- Use separate configuration for development, staging, and production DataRobot environments.
- Confirm organization, project, deployment, and service-account permissions.
- Use stable DataRobot identifiers and explicit environment mappings.
- Protect any file or object-storage credentials used by the workflow.
Operational considerations for DataRobot integrations
Reliable execution
- Follow documented pagination for collection endpoints.
- Use controlled polling intervals, bounded retries, timeouts, and backoff for long-running jobs.
- Persist prediction job identifiers and distinguish success, failure, cancellation, and timeout.
- Use correlation IDs and deterministic business keys to prevent duplicate jobs and writes.
Data and schema controls
- Validate input fields, types, nullability, categorical values, encoding, delimiters, and file size before submission.
- Version mappings when model or deployment input contracts change.
- Do not rely on display names when identifying models or deployments.
- Pin workflows to documented API behavior and test against the target DataRobot environment.
Observability
Separate authentication, validation, DataRobot processing, transport, and downstream errors so that each class can be monitored and recovered appropriately. Preserve relevant request, job, deployment, and result identifiers without exposing secrets.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than an API call
Scripts often combine authentication, transformation, polling, retries, and downstream writes in code that is difficult to reuse and operate. Martini models these concerns as maintainable workflows and APIs.
Centralize enterprise controls
Martini can provide a controlled API façade, environment-specific configuration, validation, business rules, idempotency, and consistent error handling around DataRobot operations.
Support multiple integration modes
The same integration platform can coordinate real-time predictions, scheduled batch scoring, file exchange, monitoring reconciliation, and downstream application updates without assuming a dedicated DataRobot connector.
Frequently asked questions
DataRobot can be integrated primarily through its REST APIs for Projects, Datasets, Models, Deployments, Prediction jobs, and related platform resources. Enterprise workflows can also use batch and asynchronous prediction, supported file or external data-location patterns, and selected notification capabilities. Scheduled polling and reconciliation are appropriate where universal event coverage is not confirmed.
Yes. Martini can consume DataRobot REST APIs, authenticate with the X-DataRobot-API-Key header, orchestrate real-time and batch prediction workflows, exchange supported files, transform data, and expose a normalized API for downstream applications.
No. A dedicated DataRobot connector is not required. Martini can integrate with DataRobot using its confirmed native REST APIs, API-key authentication, batch-processing endpoints, and supported file or external data exchange mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate DataRobot. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from DataRobot, cloud infrastructure, storage, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are DataRobot’s primary integration mechanism and should be the default for platform interoperability. Batch and asynchronous prediction are appropriate for large or decoupled scoring workloads, while file or external data exchange can be used where supported by the target product and deployment configuration. GraphQL and SOAP are not confirmed.
DataRobot has notification and monitoring capabilities, but broad webhook coverage for every object or lifecycle event is not confirmed. Martini can receive confirmed notifications for supported areas; for reliable synchronization, it should use scheduled REST polling, job-status polling, timestamps, identifiers, and idempotent reconciliation.
Martini can query DataRobot resources, follow pagination, persist stable object identifiers, and map DataRobot fields into canonical or downstream models. For prediction inputs it can validate types, required fields, nullability, and categorical values before invocation, while response mappings can preserve selected prediction, probability, explanation, metadata, or status fields.
Martini can distinguish transport, authentication, validation, DataRobot job, timeout, and downstream-write failures. Workflows can use bounded retries and controlled polling intervals, while deterministic business keys, correlation IDs, persisted job identifiers, and idempotent upserts reduce duplicate submissions and downstream records.
Yes. Martini can expose a REST API that validates a business-oriented request, maps it to a DataRobot deployment schema, invokes the prediction endpoint, and returns a normalized response. The façade can also centralize authorization, correlation IDs, response mapping, auditing, and error handling.
Related Martini documentation
API Integration
Operations
Connect DataRobot to your enterprise workflows
Use Martini to build secure, maintainable DataRobot integrations for prediction, data synchronization, lifecycle orchestration, and operational monitoring.