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. Engaging your Databricks account team early and following the best practices guide to build a complete, production-ready app is the fastest path through.

The onboarding process at a glance

Step	What happens	What you provide	Who owns it
1. Build	Build your app against the best practices guide.	A working, code-complete app.	Your Databricks account team
2. Business value 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.	Your Databricks account team, with the product and Partner Engineering teams
3. Apply and technical validation	Join the partner program as a Data Provider and go through the technical validation process, which includes a partner-initiated security scan.	Signed Data Partner Agreement — enter your email, click ISV, then choose Data. Once approved as a partner you get access to the partner portal, where you fill out the integration form.	Partner Engineering team
4. Partner Well Architected Review	A live call to go over the contents of your technical validation application.	Everything you submitted through the integration form.	Partner Engineering team
5. Draft Marketplace listing	The Databricks-run security review and your data partner status are completed.	Create a Marketplace listing with the proper metadata and attributes, then submit your app for Databricks-run security approval.	Marketplace and Partner Engineering teams
6. Publish	Your listing goes live in Marketplace.	Approved listing in Databricks Marketplace.	Marketplace team
7. Ongoing	Continuous security monitoring, updates, and compliance.	SLA adherence, incident reporting, and version updates. Each new version undergoes a security scan before going live.	Everyone

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. Have your Databricks account team help schedule it. 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 an automated scan built from several tools:

• Static code analysis — source vulnerabilities and code logic flaws.
• Software composition analysis — known CVEs in Python, npm, and any other third-party or open-source libraries you depend on.
• Secrets scanning — hardcoded API keys and token strings.
• Custom rules specific to apps deployed in Databricks — over-permissive Unity Catalog grants and OBO abuse flaws.
• LLM-assisted security review — true/false positive parsing and manifest audits.

Two further checks run alongside the scan:

• Manifest review. Declared external endpoints are checked against domain and IP reputation, and Databricks detects mismatches between your declared capabilities and your app's actual behavior.
• Per-app network request logging tied to your listing, for abuse detection and blast-radius analysis.

Scans re-run every time you submit a new version.

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

Legal and compliance

Data Partner Agreement

Signed first, this is the gate to enter the program. Apply at partners.databricks.com and select Data Provider. You cannot be a public Marketplace provider without this status.

Apps-specific amendment

Signed before your listing is published. It covers:

• A vulnerability remediation SLA — for example, critical vulnerabilities within a defined window.
• Incident notification obligations.
• Databricks' right to suspend or remove a listing without partner consent in defined scenarios.
• Liability allocation for customer breaches caused by the app.
• IP and code ownership — your closed-source code stays yours, and the consumer never sees it.
• Data handling, including PII, GDPR and CCPA obligations, and regional residency.

Ongoing compliance

Incident reports, SLA adherence, and publication of security advisories as required.

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