Ellipse Gradient for Header

Martini vs Tray.ai

Which integration and AI orchestration platform fits your architecture?

Quick Verdict

Martini and Tray.ai are enterprise integration and automation platforms that can connect applications, orchestrate workflows, expose APIs, process data, and increasingly coordinate AI agents and MCP tools.

Martini is designed primarily for enterprise developers who want low-code productivity without giving up Git, Java libraries, custom code, native REST and GraphQL API development, event-driven architecture, or control over where the complete runtime executes.

Tray.ai combines visual workflow automation with more than 700 connectors, API management, data integration, AI-assisted development, Merlin Agent Builder, Agent Gateway for MCP, Tray Headless, and enterprise governance.

Consider Martini when

You want integration, API development, and backend automation to operate as part of your conventional software-development architecture.

  • Build REST and GraphQL APIs, integrations, workflows, event-driven services, and backend processes in one environment.
  • Use visual development while retaining direct access to Groovy, Java libraries, JAR files, Spring libraries, custom functions, and script nodes.
  • Keep Martini packages directly in Git and use standard branch, pull-request, build, test, and deployment workflows.
  • Deploy the complete Martini Runtime in Lonti-managed infrastructure, your own cloud account, or on-premises.
  • Use REST, GraphQL, SOAP, AsyncAPI, databases, files, webhooks, WebSockets, and message brokers as first-class integration building blocks.
  • Connect APIs and applications without connector-specific licensing fees.
  • Use published pricing with either a transaction allowance or fixed-price unlimited-transaction plans.

Consider Tray.ai when

You want a cloud integration and AI orchestration platform with a large packaged connector ecosystem and strong agentic-AI capabilities.

  • Use more than 700 packaged connectors for SaaS applications, APIs, databases, data platforms, and AI services.
  • Build integrations visually using Tray Build and reusable callable workflows.
  • Use JavaScript, Python, JSONata, HTTP, GraphQL, and custom TypeScript connectors when packaged connectors are insufficient.
  • Build workflows through AI coding environments such as Claude Code and Codex using Tray Headless.
  • Build AI agents using Merlin Agent Builder and expose governed workflows or connector operations as MCP tools through Agent Gateway.
  • Use Tray API Management to turn workflow projects into managed REST-style API endpoints.
  • Connect Tray to private applications and databases through an On-prem Agent, VPN, PrivateLink, VPC peering, or other private-network options.
  • Use a SaaS platform with centralised governance, workspaces, observability, RBAC, and regional hosting.

Tray currently advertises more than 700 connectors and includes integration, automation, API management, Tray Build, Tray Headless, and core AI capabilities across its iPaaS plans.

Martini vs Tray.ai at a Glance

DimensionMartiniTray.ai
Product orientationDeveloper-centric integration, API, workflow, and backend automation platformCloud integration, automation, API, data, and AI orchestration platform
Primary development modelVisual low-code + pro-codeVisual workflow canvas + Tray Headless + connectors + scripts
Typical userEnterprise developer, integration developer, solution architectIntegration developer, automation team, enterprise IT, AI/automation teams
Major strengthDeveloper control, code extensibility, API development, runtime flexibility, and published commercial modelLarge packaged connector ecosystem and broad AI-agent/MCP orchestration capabilities
Packaged connectivityMarketplace packages plus standards-based API and protocol connectivity700+ connectors
REST API developmentYesYes
Native GraphQL API server developmentYesNo equivalent native GraphQL server-authoring model identified in current public documentation
GraphQL consumptionYesYes, through GraphQL Client
Customer-hosted full integration runtimeYesNo equivalent full self-hosted Tray platform runtime identified
Private-system connectivityFull Martini Runtime can operate inside the private networkOn-prem Agent, VPN, PrivateLink, VPC peering, and related connectivity options
Source controlMartini package assets stored and managed directly through GitTray Sync CLI materialises Tray projects locally so they can be tracked in version control
CI/CDStandard Git and CI/CD pipelinesProject APIs and Tray Sync CLI support automated environment promotion
Commercial modelPublished transaction allowance or unlimited-transaction plansCustom plan price plus usage entitlement, primarily measured through Tasks

Tray.ai and Martini overlap substantially across application integration, workflow automation, APIs, data processing, custom connectivity, AI-assisted development, and enterprise operations.

The biggest architectural differences are Tray's cloud-first control and execution model, step-oriented Task consumption, large packaged connector ecosystem, and dedicated agentic-AI products versus Martini's direct Java extensibility, native GraphQL API development, Git-oriented project model, full self-hostable runtime, and transaction-oriented commercial model.

Integration and Workflow Development

CapabilityMartiniTray.ai
Visual workflow builderYesYes
Conditional logicYesYes
Loops and branchingYesYes
Reusable workflowsYesYes, callable workflows
Reusable backend services/functionsYesCallable workflows and connector operations
Error handlingYesYes
Automatic retriesYesYes
Scheduled workflowsYesYes
Webhook triggersYesYes
Application event triggersYesYes
Visual data mappingYesYes
Database operationsYesYes
File processingYesYes
Custom JavaScriptYesYes
Custom PythonSupported through scripting optionsYes
Event-driven integrationYesYes

Tray workflows consist of a trigger followed by connector, core, helper, script, loop, callable-workflow, and other processing steps. Projects group related workflows and callable workflows provide reusable processing functions.

Martini similarly provides visual workflow orchestration, but reusable services, API handlers, database services, event consumers, functions, Java classes, and custom libraries are also first-class project assets.

APIs and Connectivity

CapabilityMartiniTray.ai
Consume REST APIsYesYes
Generic HTTP clientYesYes
Consume GraphQL APIsYesYes, GraphQL Client
Consume SOAP servicesYesYes
Consume AsyncAPI definitionsYesNo equivalent AsyncAPI import workflow identified in current public documentation
Create REST APIsYesYes, workflow-backed API Management endpoints
Create native GraphQL APIsYesNo equivalent native GraphQL API server-authoring model identified in current public documentation
OpenAPI exportYesYes
API gateway / managementAPI publishing, security, documentation, and management capabilitiesYes, Tray API Management
Authentication policiesYesYes
Rate limitingSupportedYes
Role-based API accessSupportedYes
IP restrictionsSupported through deployment/security architectureYes
WebhooksYesYes
Pre-built connectorsMarketplace packages plus universal API/protocol connectivity700+ connectors
Custom connector developmentJava/services/packages/custom librariesYes, Tray Connector Development Kit

Tray API Management can expose workflow-backed operations as managed endpoints. APIs can use authentication, role policies, rate limits, header rules, IP controls, and OpenAPI exports.

Tray also provides a dedicated GraphQL Client for consuming external GraphQL APIs, but the current API Management documentation is centred on exposing workflow-backed REST-style operations rather than authoring native GraphQL schemas and resolvers.

Martini supports both REST and GraphQL as native API-development models and can connect API operations directly to workflows, services, database logic, events, and custom code.

Extensibility and Custom Development

CapabilityMartiniTray.ai
Custom code inside workflowsYesYes
JavaScriptYesYes, ES6 Script connector
PythonSupported through scripting optionsYes, Python connector
Java ecosystem integrationYesNo equivalent direct Java-library model identified
Arbitrary JAR librariesYesNo equivalent normal workflow capability identified
Spring librariesYesNo equivalent normal workflow capability identified
Custom reusable functionsYesScripts, callable workflows, connectors, and helper operations
Custom connectorsYesYes
Custom connector languageJava ecosystem and Martini package/service abstractionsTypeScript through Tray CDK
Connector unit testsSupported through development workflowYes, CDK uses npm/Jest tooling
Generic custom service authenticationYesYes
Universal HTTP integrationYesYes

Tray offers multiple paths beyond its pre-built connector catalogue. The HTTP Client can connect to arbitrary APIs, custom services can define authentication, JavaScript and Python scripts can run inside workflows, and the Tray Connector Development Kit can create reusable custom connectors.

Tray's current CDK is based on Node.js and TypeScript. Custom connectors are developed as npm projects and can be tested locally before deployment.

Martini exposes the Java ecosystem more directly. Developers can use Groovy, Java classes, existing JAR libraries, Spring libraries, custom functions, and script nodes inside normal integration projects rather than packaging every custom capability as a connector.

Development Lifecycle

CapabilityMartiniTray.ai
Git-compatible source controlYesYes
Project assets live natively in GitYesTray projects are primarily SaaS assets; Tray Sync CLI materialises them locally for version control
Git branchesStandard Git workflowAvailable through the external repository used with locally synchronised Tray projects
Pull requestsStandard Git provider workflowAvailable through the external version-control provider
Built-in project versionsGit history plus package versionsYes
Environment promotionCI/CD deploymentProject export/import, Platform APIs, and Tray Sync CLI
DEV / staging / productionYesYes, typically represented by workspaces or organisations
CI/CDYesYes
Pre-deployment validationBuild/validation pipelinesYes, import requirements and import preview APIs
Drift detectionGit diff / repository stateYes, Tray Sync CLI local checksum comparison
Rollback/version restoreGit/version deploymentProject versions and controlled import/export workflows
AI IDE developmentMartini AI-assisted IDETray Headless for Claude Code, Codex, and MCP clients

Tray's development lifecycle changed materially in 2026. Tray Sync CLI can pull projects from Tray into a local directory, allowing those project files to be tracked in an external version-control system and promoted into other Tray environments.

Tray also exposes Platform APIs for creating project versions, exporting and importing projects, previewing imports, resolving dependencies, and automating deployment pipelines.

Tray Headless adds another developer surface. Claude Code, Codex, Cursor, Windsurf, or other MCP-compatible AI development environments can build and validate Tray workflows against the hosted Tray platform.

Martini's approach remains different because Martini package assets are designed to participate directly in Git repositories as the normal development model, rather than being SaaS-hosted assets that are synchronised to local storage for external version control.

Deployment and Infrastructure

Deployment requirementMartiniTray.ai
Vendor-managed cloud platformYesYes
Regional hostingAvailable according to Lonti deploymentUS, EU, and APAC; availability depends on Tray package
Full runtime in customer cloudYesNo equivalent full Tray workflow runtime identified in current public documentation
Full runtime on premisesYesNo equivalent full self-hosted Tray platform identified
On-premises connectivity agentNot required when Martini Runtime itself is localYes
Private IP connectivityYesYes through On-prem Agent and private-network options
Site-to-site VPNSupported through customer infrastructureYes
AWS PrivateLinkCan be implemented in customer cloud architectureYes
AWS Transit Gateway / VPC peeringCan be implemented in customer cloud architectureYes
On-prem agent high availabilityFull runtime clustering/load balancingYes, agents can run in groups
Customer controls complete integration execution stackYes with Customer CloudCustomer controls connectivity agent hosts, while Tray workflows remain managed by the Tray platform

Tray is fundamentally a managed cloud platform. Its On-prem Agent creates a secure connection between Tray and private services or databases, allowing supported Tray connectors to communicate with resources that are not internet-accessible.

Agents can run on Windows or Linux, on physical infrastructure or public-cloud virtual machines, and can be grouped for load balancing and high availability.

Tray also provides private-network alternatives including site-to-site VPN, AWS PrivateLink, Transit Gateway, and VPC peering.

The On-prem Agent should not be confused with a self-hosted Tray workflow runtime. Current documentation describes the agent as securely routing supported connector communication between Tray and private resources. The list of connectors supported through the agent is also a subset of Tray's overall connector library.

Martini Customer Cloud instead deploys the complete Martini Runtime into customer-controlled cloud or on-premises infrastructure.

Monitoring and Operations

CapabilityMartiniTray.ai
Workflow execution historyTrackerYes
Step-level logsYesYes
Inspect step input/outputYesYes
Search logsYesYes
Rerun failed workflowYesYes
Rerun individual stepWorkflow-specific recoveryYes
Persistent transaction storeTrackerWorkflow logs with package-dependent retention
Configurable log retentionYesYes
Log maskingSupported through platform controlsYes
Log streamingMetrics/log integrationsTeam add-on; included with Enterprise
Operational dashboardsMetrics API / external toolingInsights Hub
External observabilityMetrics APILog streaming to systems such as Datadog, Sentry, Redshift, New Relic, or Kibana
Usage analyticsTransaction and runtime metricsTask usage dashboard and Insights Hub

Tray provides detailed workflow logs with the status, input, and output of individual workflow steps. Developers can replay entire workflow runs or individual steps after correcting an error.

Log retention depends on package. Current documentation lists seven-day replay/log access for Pro, seven days for Team with a 30-day option, and 30 days for Enterprise. Insights retention is longer: seven days for Pro, 30 days for Team, and 180 days for Enterprise.

Tray also supports log streaming to external observability platforms for Team customers with the relevant add-on and for Enterprise customers.

Martini Tracker is more explicitly transaction-centric. Tracker can persist business transaction payloads, requests, responses, metadata, errors, and execution state and lets operations teams search and resubmit selected transactions.

AI-Assisted Development and Agents

AI capabilityMartiniTray.ai
Natural-language workflow developmentYesYes, Merlin Build and Tray Headless
AI-assisted workflow generationYesYes
AI-assisted mapping / transformationYesYes
AI coding environment supportBuilt into Martini DesignerClaude Code, Codex, Cursor, Windsurf, and other MCP clients through Tray Headless
Build AI agentsYesYes, Merlin Agent Builder
Agent knowledge sources / RAGSupportedYes
Workflows as agent toolsYesYes
Connector operations as agent toolsYes through tool/service exposureYes through Agent Gateway
MCP server / gatewaySupported within Martini's agent architectureYes, Agent Gateway for MCP
MCP governanceGovernance and audit controlsYes
Dynamic end-user authentication for MCP toolsGoverned identities/scopes architectureYes
Agent observabilityGovernance and Tracker/runtime visibilityYes
AI token usage meteringDepends on selected model/provider and Lonti configurationNative AI token use converts into Tray Tasks according to customer-specific conversion rates
Intelligent document processingCan be implemented through AI/workflow integrationMerlin IDP with page-based entitlement

Tray has made AI orchestration a major part of its current platform strategy. Merlin Agent Builder creates agents that combine a behavioural scope, data sources, AI models, workflows as tools, and an agent orchestration workflow.

Agent Gateway for MCP can expose complete Tray workflows or individual connector operations as governed MCP tools. Access controls, user authentication, audit logging, rate limiting, and execution visibility are applied centrally.

Tray Headless brings Tray workflow development into AI development environments. Its guided plugins currently support Claude Code and Codex, while the hosted Headless MCP interface can be used from other MCP-compatible environments.

Martini's AI strategy similarly treats AI agents as part of the same orchestration environment used for APIs, integrations, automation, events, and custom code, with developer control over the resulting assets.

Martini vs Tray.ai Pricing

Martini and Tray use materially different usage models.

Martini primarily counts one distinct workflow or service execution as one Martini transaction. Multiple workflow steps, database operations, transformations, and API calls performed inside that execution remain part of that transaction.

Tray's primary workflow consumption unit is a Task. Tray describes a Task as roughly equivalent to an executed workflow step. A workflow trigger is itself a Task, and connector, helper, script, loop, and other processing steps can generate additional Tasks as they execute.

Martini pricing

FeatureEssentialsElasticCustomer Cloud
Starting price$495/month$3,995/month$4,500/month
Martini transactions100,000/monthUnlimitedUnlimited
API connector feesNoneNoneNone
Development workspace111
Staging workspace111
Production1 production server3 load-balanced production serversConfigurable production servers
Included production capacityDefined production server12 vCPUs total12 vCPUs total
DeploymentLonti-managedIsolated Lonti-managed environmentCustomer cloud or on-premises

Essentials includes 100,000 Martini transactions per month. Elastic and Customer Cloud are not capped or priced according to Martini transaction volume.

Tray.ai pricing

FeatureProTeamEnterprise
Published priceCustom quoteCustom quoteCustom quote
Workspaces320Unlimited
Insights history7 days30 days180 days
Standard log retention7 days7 days, expandable30 days
Connectors700+700+700+
Process automationIncludedIncludedIncluded
Data integrationIncludedIncludedIncluded
API ManagementIncludedIncludedIncluded
Tray BuildIncludedIncludedIncluded
Tray HeadlessIncludedIncludedIncluded
Connector developmentIncludedIncludedIncluded
Advanced on-premises optionsNot listed as standardAvailable through applicable add-onsIncluded as an advanced capability
Regional hostingNot listed as standardOptional add-onIncluded
Log streamingNot listed as standardOptional add-onIncluded
Agent DevelopmentAdd-onAdd-onAdd-on

Tray does not publish dollar prices or standard included Task quantities for Pro, Team, or Enterprise. Its pricing page states that pricing is based on usage and required features and that customers receive a customised quote.

Tray's usage dashboard tracks Task entitlements. AI connectors can also generate Task consumption based on token usage using a customer-specific token-to-task conversion ratio, while Merlin Intelligent Document Processing is measured in pages.

Martini Transactions vs Tray Tasks

How Martini counts a transaction

A Martini transaction is one distinct execution of a workflow or service.

  • Workflow steps
  • Transformations
  • Database operations
  • Internal service calls
  • External API calls
  • Message operations
  • Custom code executed inside the workflow

Those operations remain part of the same Martini transaction when they occur within one workflow or service execution.

Martini example

An order workflow receives an order, looks up a customer, transforms the payload, calls an ERP, updates a CRM, and sends a notification. If the process executes as one Martini workflow, it is one Martini transaction.

How Tray counts Tasks

Tray describes a Task as approximately equivalent to an executed workflow step.

A webhook or HTTP trigger contributes a Task, and each executed connector, helper, script, or other workflow step can contribute another Task. Steps inside loops can execute repeatedly and therefore generate repeated Task usage.

A connector step does not necessarily equal a single third-party API request. Tray notes that a connector operation may make several underlying API calls while still counting as a single Task.

Tray example

If a workflow receives an order through a webhook and then executes customer lookup, ERP create, CRM update, and notification steps, the simplified execution contains five Tray Tasks: one trigger plus four executed processing steps.

Automatic platform retries are not charged as additional Tasks according to Tray's current usage documentation.

What happens when workflows become more complex?

For Martini, adding more internal operations does not by itself increase the transaction count if the process still runs as one workflow execution.

For Tray, adding additional executed workflow steps can increase Task usage. Tray's own optimisation documentation recommends consolidating excessive helper, loop, boolean, and transformation steps because reducing step count can materially reduce monthly Task consumption and billing.

Do Martini and Tray.ai Offer Unlimited Usage?

Martini

Yes. Lonti Elastic, from $3,995/month, and Customer Cloud, from $4,500/month, include unlimited Martini transactions.

Unlimited transactions means the subscription is not capped or priced according to the number of Martini transactions. Runtime compute capacity remains finite.

Tray.ai

No publicly advertised unlimited-Task plan was identified in Tray's current pricing or usage documentation.

Tray states that customers choose a plan and add-ons and scale on demand with Tasks. Pricing is based on usage and the features required, and customers receive a customised quote.

The Usage dashboard compares actual Task consumption with the customer's contracted entitlement, and workspace administrators can configure monthly Task limits.

Individual enterprise agreements may differ, so the absence of a publicly advertised unlimited-Task plan should not be interpreted as confirmation that Tray would never negotiate a different commercial arrangement.

Which Platform Fits Your Use Case?

Both

Complex enterprise integration

Both platforms can implement complex integrations involving APIs, SaaS applications, databases, transformations, workflows, custom code, and event-driven processing.

Tray.ai

Large packaged SaaS connector catalogue

Consider Tray when packaged application connectivity is a major requirement. Tray currently advertises more than 700 connectors and can also create custom connectors through its TypeScript-based CDK.

Martini

Direct reuse of Java and Spring libraries

Consider Martini when integrations need to directly reuse existing Java code, Spring libraries, or arbitrary JAR files. Tray provides JavaScript, Python, HTTP integration, and TypeScript custom connectors but does not document an equivalent general-purpose Java-library development model.

Martini

Native GraphQL backend development

Consider Martini when teams need to build and host GraphQL schemas, queries, mutations, resolvers, and subscriptions. Tray provides a GraphQL Client for consuming GraphQL APIs but no equivalent native GraphQL server-authoring model was identified in current documentation.

Tray.ai

AI-agent and MCP governance

Consider Tray when enterprise AI-agent development and MCP governance are central requirements. Merlin Agent Builder, Agent Gateway, workflow tools, connector tools, dynamic authentication, and Tray Headless form a broad agentic integration environment.

Both

AI-assisted developer workflow

Both platforms now invest heavily in AI-assisted development. Martini integrates AI into its developer IDE, while Tray provides visual Merlin Build plus Tray Headless for Claude Code, Codex, and other MCP-compatible development environments.

Martini

Customer-controlled full runtime

Consider Martini when the integration runtime itself must execute inside customer infrastructure. Tray can securely reach private systems using an On-prem Agent and private networking, but the current architecture remains a Tray-managed cloud orchestration platform.

Tray.ai

Private connectivity to selected internal systems

Consider Tray when a cloud-managed integration platform is acceptable but selected private databases, SAP systems, APIs, JDBC endpoints, SOAP services, or other supported endpoints must remain inside a private network. Tray provides On-prem Agent and advanced private-network options.

Martini

Published high-volume pricing

Consider Martini when the ability to model production cost from public pricing is important. Lonti publicly lists its transaction allowance and fixed-price unlimited-transaction plans. Tray requires a customised quote for both plan pricing and Task entitlements.

Martini

Workflows with many internal processing steps

Consider the pricing implications carefully when workflows contain many transformations, helper operations, loops, and service calls. Martini continues to count one workflow execution as one transaction, while Tray can consume Tasks for each executed workflow step.

Martini

Persistent business-transaction replay

Consider Martini when operations teams need a persistent transaction store designed for searching business payloads and resubmitting selected transactions. Tray can replay workflow runs and individual steps while those logs remain available.

The Bottom Line

Martini and Tray.ai overlap substantially across integration, automation, APIs, visual development, scripting, AI-assisted development, event processing, observability, and enterprise governance.

Tray's centre of gravity is cloud-based enterprise orchestration. Its strongest differentiators include more than 700 packaged connectors, Tray Build, Tray Headless, API Management, Merlin Agent Builder, Agent Gateway for MCP, and a mature cloud governance model.

Martini's centre of gravity is developer-first low-code backend and integration development. It combines workflows, REST and GraphQL APIs, databases, events, Java extensibility, Git, CI/CD, and customer-controlled runtimes while allowing developers to move beyond platform-specific abstractions when necessary.

The pricing models also differ substantially. Tray primarily meters executed workflow steps as Tasks and does not publish plan prices or Task allowances. Martini counts the complete workflow or service execution as a transaction and publishes fixed-price unlimited-transaction plans for higher-scale deployments.

Do we value Tray's broad cloud connector and agentic-AI ecosystem more highly, or do we want a developer-centric integration platform with direct Java extensibility, full runtime control, native GraphQL development, and a simpler published consumption model?

Evaluate Martini and Tray.ai with the Same Project

Because both platforms are capable enterprise integration products, a useful evaluation should test architecture, extensibility, operations, and commercial consumption rather than simply configuring a SaaS connector.

  1. Use a packaged connector for a major SaaS application.
  2. Consume an external REST API using a generic HTTP client.
  3. Consume a GraphQL API.
  4. Build and publish a REST API.
  5. Implement a GraphQL API server requirement.
  6. Connect to a relational database.
  7. Transform a complex nested payload.
  8. Build an event-driven integration.
  9. Implement custom JavaScript or scripting logic.
  10. Reuse an existing enterprise Java library or implement the closest Tray equivalent.
  11. Create a custom connector when a packaged connector is unavailable.
  12. Create reusable child workflows or services.
  13. Track the project through source control.
  14. Promote the project from development to production using CI/CD.
  15. Connect to a system that exists only inside a private network.
  16. Intentionally cause a production processing failure.
  17. Inspect the failed request and intermediate step data.
  18. Replay the failed workflow or transaction.
  19. Expose integration logic as an MCP tool.
  20. Compare the number of Martini transactions and Tray Tasks generated by the same production workload.

Compare developer effort, connector coverage, custom-code flexibility, API capabilities, source-control workflow, deployment architecture, private-network model, operational recovery, AI-agent capabilities, measured usage, and expected production cost.

Worked pricing scenarios

5,000 Straightforward SaaS Transactions per Month

A workflow receives 5,000 orders per month and then performs four application operations.

Martini

Calculation
5,000 workflow executions × 1 Martini transaction = 5,000 transactions per month
Plan
Essentials
Price
$495/month

Tray.ai

MetricMartiniTray.ai
Business events5,0005,000
Processing operations shownIncluded in workflow transaction5 executed Tasks per run
Metered usage5,000 transactions25,000 Tasks
Published applicable price$495/monthNot publicly listed

Tray's Task model reflects the number of executed workflow steps. Martini counts the complete workflow execution as one transaction.

25,000 Complex Enterprise Transactions per Month

Each business event executes a trigger plus six processing steps.

Martini

Calculation
25,000 workflow executions = 25,000 Martini transactions
Plan
Essentials
Price
$495/month

Tray.ai

MetricMartiniTray.ai
Business transactions25,00025,000
Executed operationsIncluded inside each transaction7 Tasks per run
Metered usage25,000 transactions175,000 Tasks
Published monthly price$495Not publicly listed

The difference grows as workflow step count increases, even though both platforms process the same 25,000 business events.

100,000 API Requests per Month

A managed API receives 100,000 requests. Each API invocation executes four additional workflow-processing steps.

Martini

Calculation
100,000 API service invocations = 100,000 Martini transactions
Plan
Essentials
Price
$495/month

Tray.ai

Calculation
100,000 API workflow executions × 5 Tasks = 500,000 Tasks
Price
Custom quote
MetricMartiniTray.ai
API requests100,000100,000
Internal processing stepsIncluded in transaction4 additional Tasks
Metered usage100,000 transactions500,000 Tasks
Published monthly price$495Not publicly listed

Tray's API Management documentation explicitly states that the workflows underpinning managed API endpoints consume the customer's Task allowance.

1 Million Business Transactions per Month

A production integration processes one million business events. Each run contains one trigger and four processing steps.

Martini

Calculation
1,000,000 workflow executions are covered by Elastic's unlimited transaction allowance
Plan
Elastic
Price
$3,995/month

Tray.ai

Calculation
1,000,000 workflow runs × 5 Tasks = 5,000,000 Tasks
Plan
Commercial entitlement must be sized for the workload
Price
Custom quote
MetricMartiniTray.ai
Business transactions1,000,0001,000,000
Metered usageUnlimited transactions on Elastic5,000,000 Tasks
Pricing modelFixed-price unlimited transaction allowanceContracted Task entitlement
Published monthly price$3,995Not publicly listed

At high business-event volume, Martini's published unlimited-transaction model can be directly costed. Tray Task consumption can also be calculated, but its dollar effect cannot be determined without the customer's quote.

Workflow Complexity Increases Without Increasing Business Volume

The integration continues processing 50,000 business events each month but expands from four total executed workflow steps to ten.

Martini

Plan
Essentials
Price
$495/month
Before
50,000 transactions
After
50,000 transactions
What changes
Internal workflow complexity does not create additional Martini transactions.

Tray.ai

Price
Dollar effect depends on the customer's contracted entitlement
Before
50,000 × 4 Tasks = 200,000 Tasks
After
50,000 × 10 Tasks = 500,000 Tasks
MetricBeforeAfter
Business events50,00050,000
Martini transactions50,00050,000
Tray Tasks200,000500,000

This is the most important commercial difference between the two usage models. The underlying business volume has not changed, but Tray Task consumption increases as more executed steps are added.

10,000 Transactions with a 20-Item Loop

Each business event receives an array of 20 records and executes two workflow steps for each record inside a loop.

Martini

Calculation
10,000 workflow executions = 10,000 Martini transactions
Plan
Essentials
Price
$495/month

Tray.ai

Calculation
At minimum, repeated steps inside the 20-item loop can generate hundreds of thousands of Tasks. Using one trigger plus a loop step and two processing steps per item gives an illustrative 610,000 Tasks: 10,000 trigger Tasks + 10,000 × 20 × 3 repeated Tasks.
Price
Custom quote

Tray specifically advises customers to avoid unnecessarily complex nested looping because repeated logical operations can materially increase Task consumption. Martini's transaction count remains tied to workflow execution rather than loop iteration count, although compute requirements can still increase substantially.

Consolidating 30 Processing Steps into 4

A workflow processes 20,000 business events per month. Developers consolidate excessive helper and transformation steps from 30 executed steps per run to four.

Martini

Before
20,000 transactions
After
20,000 transactions
What changes
The transaction count does not change, although the optimised workflow may require less compute.

Tray.ai

Price
Dollar savings depend on the commercial Task entitlement
Before
20,000 × 30 = 600,000 Tasks
After
20,000 × 4 = 80,000 Tasks

This mirrors Tray's own optimisation guidance, which recommends consolidating excessive helper and transformation steps because workflow design can directly affect Task usage and monthly billing.

What these scenarios show

The scenarios should not be interpreted as claiming that Martini is always less expensive than Tray.ai. Tray does not publish sufficient dollar pricing to make that conclusion from public information.

Martini cost drivers

  • Workflow or service execution volume on Essentials.
  • Selected Lonti plan.
  • Runtime infrastructure capacity.
  • Managed versus customer-controlled deployment.
  • Optional infrastructure services.

Tray.ai cost drivers

  • Contracted Task entitlement.
  • Number of executed workflow steps.
  • Loop iterations and repeated processing.
  • Workflow architecture and optimisation.
  • AI token usage converted to Tasks under customer-specific rates.
  • Merlin IDP page usage where applicable.
  • Pro, Team, or Enterprise package.
  • Add-ons such as Agent Development, regional hosting, extended observability, and other enterprise capabilities.
  • Negotiated commercial terms.

Tray's usage model creates a direct relationship between workflow design and consumption because Tasks are approximately equivalent to executed workflow steps. Martini instead meters the overall workflow or service execution and then removes transaction metering on Elastic and Customer Cloud. Tray provides substantially more packaged connectivity and a broad AI-agent ecosystem, while Martini provides a simpler published commercial model and reduces the pricing impact of internal workflow complexity.

Frequently asked questions

What is the main difference between Martini and Tray.ai?

Both are enterprise integration and automation platforms. Tray.ai is a cloud-first orchestration platform with more than 700 connectors, API Management, Tray Headless, Merlin Agent Builder, and Agent Gateway for MCP. Martini is more explicitly developer-centric and combines workflows, REST and GraphQL APIs, databases, messaging, Java extensibility, Git, CI/CD, and a self-hostable runtime in one development platform.

How much does Tray.ai cost?

Tray does not currently publish dollar pricing for its Pro, Team, or Enterprise plans. Tray states that pricing is based on the features and usage required and provides customised quotes.

How much does Martini cost?

Lonti Essentials starts at $495/month and includes 100,000 Martini transactions. Elastic starts at $3,995/month and includes unlimited Martini transactions. Customer Cloud starts at $4,500/month and includes unlimited Martini transactions with deployment inside customer-controlled cloud or on-premises infrastructure.

What counts as a Martini transaction?

A Martini transaction is one distinct workflow or service execution. Multiple workflow steps, transformations, database operations, integrations, API calls, message operations, and custom logic performed inside that execution do not each create another Martini transaction.

What is a Tray Task?

Tray describes a Task as approximately equivalent to an executed workflow step. A trigger can count as a Task, and subsequent connector, helper, script, loop, and processing steps can each contribute Tasks as they execute.

Does a Tray connector Task equal one external API request?

Not necessarily. Tray states that a connector may make several underlying API calls during one connector execution while the connector step still counts as a single Task.

Do loops increase Tray Task usage?

Yes. Steps executed repeatedly inside loops can generate Tasks for each iteration. Tray's own optimisation guidance recommends avoiding unnecessary nested loops and consolidating workflow steps where practical to reduce Task consumption.

Does Martini offer unlimited transactions?

Yes. Lonti's Elastic and Customer Cloud plans include unlimited Martini transactions.

Does Tray.ai offer unlimited Tasks?

No publicly advertised unlimited-Task plan was identified in Tray's current pricing or usage documentation. Tray uses contracted Task entitlements and states that pricing depends on expected usage and required features. Individual enterprise agreements may differ.

Does Martini have connectors like Tray.ai?

Yes, but Tray has a major packaged-connectivity advantage with more than 700 published connectors. Martini provides Marketplace packages and native endpoint support but emphasises open connectivity through REST, GraphQL, SOAP, AsyncAPI, webhooks, databases, files, message brokers, and custom code. Lonti does not charge additional fees according to which API or vendor is connected.

Can Tray.ai connect to on-premises systems?

Yes. Tray provides an On-prem Agent that creates a secure connection between Tray and supported private services and databases. Tray also supports private-network options such as site-to-site VPN and AWS-specific approaches including PrivateLink, Transit Gateway, and VPC peering.

Can Tray.ai run fully on premises?

A full customer-operated Tray platform runtime equivalent to Martini Customer Cloud was not identified in current public documentation. Tray's On-prem Agent provides private connectivity for supported connectors while the broader Tray orchestration platform remains cloud-managed.

Can Martini run fully on premises?

Yes. The complete Martini Runtime can be deployed within customer-controlled cloud or on-premises infrastructure.

Does Tray.ai support Git?

Yes, through its current developer tooling. Tray Sync CLI can pull Tray projects into a local directory so they can be tracked in a version-control system and promoted between Tray environments. Tray projects themselves remain managed platform assets rather than natively repository-resident source projects.

Do both Martini and Tray.ai support CI/CD?

Yes. Martini integrates Git-managed packages directly with common CI/CD systems. Tray provides Platform APIs and Tray Sync CLI for project versioning, export/import, validation, drift detection, and automated environment promotion.

What is Tray Headless?

Tray Headless exposes Tray workflow development to AI coding environments. Tray provides guided plugins for Claude Code and Codex and a hosted MCP interface that can be used from other MCP-compatible tools such as Cursor and Windsurf. Workflows built headlessly are stored in the same Tray platform and can be opened in the visual builder.

Can Tray.ai use custom code?

Yes. Tray provides JavaScript and Python script connectors, JSONata capabilities, generic HTTP connectivity, custom services, and a TypeScript-based Connector Development Kit for building custom connectors.

Can Martini use custom Java libraries?

Yes. Martini can directly use Java libraries, arbitrary JAR files, Spring libraries, Groovy methods, custom functions, and script nodes within normal Martini projects.

Can both platforms consume GraphQL APIs?

Yes. Martini can consume GraphQL schemas and generate reusable services. Tray provides a dedicated GraphQL Client connector for issuing queries to GraphQL APIs.

Can both platforms create GraphQL APIs?

Martini natively creates GraphQL APIs including schemas, queries, mutations, resolvers, and subscriptions. Tray can consume GraphQL and expose workflow-backed managed APIs, but an equivalent native GraphQL server-authoring model was not identified in the current public documentation reviewed.

Can Tray.ai replay failed integrations?

Yes. Tray workflow logs allow developers to replay entire workflow runs and, where applicable, individual workflow steps. Replay availability depends on the package's log-retention window.

Does Tray.ai support AI agents?

Yes. Merlin Agent Builder builds agents that use AI models, knowledge sources, and Tray workflows as tools. Tray also provides Agent Gateway for MCP to expose workflows and individual connector operations as governed tools for external AI agents.

Does Tray.ai support MCP?

Yes. Agent Gateway provides managed MCP services with access controls, authentication, audit logging, observability, connector tools, and complete workflows exposed as composite tools. Tray Headless also uses MCP to expose the Tray development platform to external AI coding environments.

Which platform is designed around professional software-development practices?

Both increasingly support professional development workflows, but their architectures differ. Martini uses Git-managed package assets, Java extensibility, CI/CD, deployable runtimes, and developer-oriented API development. Tray now provides Tray Sync CLI, Platform APIs, Tray Headless, TypeScript connector development, project versions, and automated environment promotion around its cloud-hosted platform.

Is Martini an alternative to Tray.ai?

Yes. There is substantial overlap across enterprise integration, automation, APIs, data processing, custom connectivity, monitoring, AI-assisted development, agents, and MCP. The main differences are packaged connector breadth, code extensibility model, GraphQL development, runtime deployment, source-control architecture, AI product breadth, and Task-versus-transaction pricing.

Methodology

This comparison is based primarily on current first-party documentation from Lonti and Tray.ai.

  • Identify the date on which the comparison was last reviewed.
  • Use current Tray.ai pricing, platform, developer, and product documentation for material Tray claims.
  • Use current Lonti product documentation and pricing for Martini claims.
  • Distinguish 'not publicly documented' from 'not supported'.
  • Reflect the August 2026 Tray Sync CLI rather than relying on older descriptions of Tray's source-control model.
  • Distinguish local version-control compatibility through Tray Sync CLI from Martini's Git-native package development model.
  • Distinguish Tray's On-prem Agent and private-network connectivity from deployment of the complete Tray orchestration platform on customer infrastructure.
  • Distinguish GraphQL consumption from native GraphQL API-server development.
  • Do not invent Tray plan prices or included Task quantities because current pricing is quote-based.
  • Calculate Tray Tasks only where the workflow structure and assumptions are explicitly stated.
  • Account for the workflow trigger when calculating illustrative Tray Task usage.
  • Do not equate Tray Tasks directly with third-party API requests because one connector Task may perform multiple underlying API calls.
  • Acknowledge material Tray strengths including its connector ecosystem, Tray Headless, Agent Gateway, Merlin Agent Builder, API Management, and cloud governance.
  • Treat pricing, Task entitlements, AI token conversions, connector counts, add-ons, and product packaging as time-sensitive.

The objective is not to claim that Martini is universally better than Tray.ai. The objective is to show how two enterprise integration and AI orchestration platforms differ in development model, connectivity, API architecture, extensibility, source control, deployment, operations, AI capabilities, and commercial consumption.

Sources

Disclosure and Disclaimer

This comparison has been prepared by Lonti, the developer of Martini. It is intended to provide general information to organisations evaluating integration and automation platforms and should not be regarded as an independent or impartial product review.

Information about Tray.ai is based primarily on publicly available information published by Tray.ai, including its product documentation, pricing pages, developer documentation, release notes, and other official materials, as identified in the sources above. Information about Martini is based on Lonti's own product documentation and pricing.

We aim to keep this comparison accurate and current, but products, features, pricing, usage limits, licensing terms, packaging, and commercial arrangements may change without notice. Public documentation may also be incomplete or may not reflect individually negotiated enterprise agreements. Readers should verify important information directly with the relevant vendor before making purchasing, architectural, or commercial decisions.

Where public information does not provide enough detail to make an exact comparison, this page may use stated assumptions or illustrative calculations. These are clearly identified where applicable and should not be interpreted as Tray.ai's official pricing, performance, or contractual terms.

Tray.ai does not currently publish dollar pricing or standard Task entitlements for its Pro, Team, or Enterprise plans. Pricing scenarios on this page therefore calculate illustrative Task consumption using Tray's publicly documented Task model but do not estimate a Tray subscription price and should not be interpreted as a Tray.ai quotation.

Illustrative Tray Task calculations assume that each explicitly identified workflow step executes once unless otherwise stated. Actual Task consumption can differ because of branching, looping, conditional execution, callable workflows, connector behaviour, AI token consumption, retries, and other implementation details.

Feature comparisons describe capabilities identified in publicly available documentation at the date shown on this page. The absence of a documented capability should not necessarily be interpreted as confirmation that the capability is unavailable.

This content is provided for general informational purposes only. Lonti makes no representation or warranty that the information is complete, error-free, or suitable for any particular organisation or use case. To the extent permitted by applicable law, Lonti accepts no liability for decisions or losses arising from reliance on this comparison. Nothing in this disclaimer excludes or limits any rights or remedies that cannot lawfully be excluded or limited.

All third-party product names, company names, logos, and trademarks are the property of their respective owners. Unless expressly stated otherwise, Lonti is not affiliated with, endorsed by, sponsored by, or associated with Tray.ai.

Last reviewed: September 2026