Becoming a Marketplace Apps Provider

Why build a Databricks Marketplace App?

Historically, adopting a third-party analytics tool or data application has been a security and engineering challenge for enterprise customers. The typical process requires moving sensitive data out of a secure environment to an external vendor, weeks of compliance reviews, and complex ETL pipelines and API integrations just to get started.

Apps on Databricks Marketplace flips this model. Instead of moving data to your application, your application runs where the data already lives — inside the customer's own Databricks workspace.

For partners, this means:

• Massive distribution with minimal overhead. Publish once and reach thousands of enterprise Databricks customers. There is no vendor infrastructure to maintain and no per-customer onboarding process.
• Shorter sales cycles. Because your app runs natively in the customer's environment, procurement and compliance hurdles drop sharply.
• IP protection by design. Apps ship as closed-source containers. Customers install and run your app, but never see your underlying code.
• Built-in governance. Your app automatically inherits the security, auditing, and fine-grained access controls of the customer's Unity Catalog environment — no extra compliance work required.
• AI-ready out of the box. Build on Databricks primitives like Model Serving, Lakebase, Genie, and Agent Bricks to deliver AI-powered experiences without wiring up external services.

Browse the current apps on Databricks Marketplace to see what partners are already building.

Why Marketplace apps are different

Marketplace apps are installed by consumers into their workspaces — workspaces you don't control. That changes the bar on auth, networking, configuration, supply chain, and packaging. This guide collects the practices that survive that constraint, grounded in Databricks public docs and field experience.

---

How validation works

Every Marketplace app clears three review tracks before it can be published. All three tracks continue after launch:

• Business quality — Is this a real, valuable, production-ready app for Databricks customers?
• Security — Is the app safe for a customer to install and run in their own workspace?
• Legal and partnership compliance — Are the right agreements in place?

Two principles to keep in mind:

• Validation is per app, not per partner. Each app you submit clears the bar on its own. Having one approved listing does not pre-approve your next submission.
• Plan for several weeks of review per app across the three tracks combined. Starting early and submitting a complete, production-ready app is the fastest path to approval.

The onboarding process at a glance

Step	What happens	What you provide
1. Build	Build your app following the best practices guide.	A working, code-complete app.
2. Demo review	A live walkthrough of your app and its configuration, as part of the Data Partner technical validation.	Schedule a demo call with the Databricks product team and be prepared to walk through your app end-to-end.
3. Apply	Join the partner program as a Data Provider.	Signed Data Partner Agreement. Go to the partner portal, enter your email, click ISV, then choose Data.
4. Pre-listing review	Security review and data partner status are completed.	Create a Marketplace listing with the proper metadata and attributes, then submit your app for security approval.
5. Publish	Your listing goes live in Marketplace.	Finalized listing in Databricks Marketplace.
6. Ongoing	Continuous security monitoring, updates, and compliance.	SLA adherence, incident reporting, and version updates. Each new version undergoes a security scan before going live.

Business quality

The production-quality bar

Your app must be production-quality and code-complete by the time of your demo review. It should have demonstrated customer demand and deliver clear business value — both to you and to Databricks.

What Databricks looks for

• Relevant use case. The app solves a real problem for Databricks customers, and you can identify target customers who would use it.
• Real, functional integration. The app integrates natively within the Databricks ecosystem, using products such as Lakebase, Unity Catalog, Model Serving, Lakeflow Jobs, Genie, and others.
• Supported framework. Python (Streamlit, Dash, Gradio, or other Python frameworks) or Node.js (React, Angular, Svelte, Express).
• Runs end-to-end locally via databricks apps run-local.
• Clean critical user journey (CUJ) with a simple, intuitive user experience.
• Adherence to the best practices guide. In particular:
  • All app code must be un-obfuscated and human-readable. No pre-compiled wheels, binaries, or packaged executables.
  • Deployed from Git, with no personal access tokens (PATs) anywhere in the app.
  • Network egress restricted to precisely declared domains.
  • Correct authentication model: the app service principal for app-owned operations, and on-behalf-of (OBO) for accessing consumer data.
  • Consumer-owned secret scopes for any API or license keys.
  • All required resources and scopes declared in app.yaml.

The demo review

The demo review is a short live session (approximately 30 minutes) where you screen-share and walk the Databricks team through your app. Be prepared to cover:

• The problem and use case your app solves.
• Demonstrated business value and customer demand.
• A live walkthrough of the primary user flow.
• Your app configuration — declared resources, scopes, permissions, external domains, and any attached data assets (such as OpenShares).

What a high-quality listing looks like

A strong Marketplace listing includes:

• A decision on access model: request for access or instant access.
• A detailed listing description with use cases and a clear overview of your app.
• App screenshots.
• A README with setup instructions and any required notebooks.
• Declared external domains.
• A support email address.

Guest credentials

If your app depends on any external APIs or license keys, you must provide guest credentials so reviewers can exercise the full user journey. An app cannot be approved without a way to run it end-to-end.

Security

Your app installs and runs inside the customer's workspace, so the security bar is high. You commit to the standards below during development. Your app is scanned and reviewed before publishing and monitored continuously after launch.

What you build to

Requirement	Details
Correct auth model	App service principal for app-owned operations; OBO for consumer data access. No PATs.
Pinned dependencies	Include a lockfile in your repository.
Complete manifest	Declare all capabilities and every required outbound endpoint in app.yaml.
Allowlisted functionality only	No dynamic package installs at runtime, no crypto mining, and no unjustified binary blobs. Your app must behave exactly as advertised.
Readable source	You may ship closed-source apps, but code must not be obfuscated so it can be reviewed. Your code and intellectual property remain yours and are never exposed to consumers.

What Databricks reviews before publishing

Databricks runs automated security scans on every app submission, including:

• Static code analysis — scanning your source code for security vulnerabilities and anti-patterns.
• Software composition analysis — identifying known vulnerabilities in Python, npm, and other third-party libraries.
• Secrets scanning — detecting any accidentally committed credentials or tokens.
• LLM-assisted security review — additional review specific to apps deployed in Databricks.

For guidance on meeting the security bar, see the best practices guide.

Legal and compliance

Before your app can be published, the following must be in place:

• A signed Data Partner Agreement with Databricks.
• Acceptance of Databricks Marketplace terms of service.
• Ongoing compliance with Databricks security and SLA requirements.

Contact your Databricks partner representative to initiate the Data Partner Agreement or visit the Databricks Partner Portal.