Delta Sharing

Delta Sharing is the lowest-effort way to get Neurolabs image recognition data into your own data platform. Instead of building and maintaining an integration against our REST API, we share our tables directly with you and you query them where they land.

The advantage is that there is nothing to keep in step. New modalities, new metrics and schema additions appear in the shared tables without an integration change on your side, and without waiting on a release from us or from a third party in the middle.

Which mode you need

Delta Sharing has two modes. They deliver the same data — the difference is purely how your side authenticates and connects.

	Delta Share (Databricks-to-Databricks)	Open Sharing
Use when	You have Databricks	You don't have Databricks
You give us	Your Databricks sharing identifier	Nothing — we issue you a credential
We give you	Access to the share	A recipient credential file
Access from	Your Databricks workspace	Any client implementing the Delta Sharing protocol

tip

If you already have Databricks, use Delta Share rather than Open Sharing. It's simpler to set up, avoids credential files, and access is managed natively on both sides.

What is shared

Our data is organised in a medallion architecture, and we can share any layer with you depending on how much you want to do yourself.

Bronze — raw

Data straight from our operational database, largely unprocessed:

• Catalogue items
• Annotations, including bounding boxes, predictions and result UUIDs

Choose bronze if your team wants full fidelity and intends to do its own modelling.

Silver — cleaned

The same data cleaned and joined into usable tables. This is the sensible default for most BI work.

Gold — enriched

Cleaned data plus precalculated metrics such as share of shelf. Because the aggregation is already done, dashboards built on gold are considerably faster than ones that compute metrics at query time.

note

Most teams end up joining our data to their own operational data — store, visit, rep, or route information from an SFA or CRM system. The result UUID is the key to do it with: each result corresponds to one image from one visit, so it gives you lineage from an individual annotation back to the visit and store it came from.

Setting up Delta Share (Databricks-to-Databricks)

1. Find your sharing identifier. In your Databricks workspace, this is the identifier that uniquely names your metastore for sharing purposes, in the form <cloud>:<region>:<metastore-uuid>.
2. Send it to Neurolabs, along with which layer you want (bronze, silver or gold).
3. We create the share and grant your identifier access to it.
4. Accept the share in your workspace. The shared tables then appear as a catalog you can query like any other.
5. Connect your BI tool. Power BI connects to Databricks natively, so shared tables are available to existing reporting with no intermediate copy.

Setting up a share on our side is quick — the lead time is usually in getting the identifier from your platform team, not in the provisioning.

Setting up Open Sharing

Open Sharing uses the open Delta Sharing protocol, so your platform does not need to be Databricks. Any client that implements the protocol can read the tables — including Python, Spark, and a range of BI and warehouse tools.

1. Tell Neurolabs that you need open sharing, and which layer you want.
2. We create a recipient for you and issue a credential file. This contains an endpoint and a bearer token.
3. Load the credential into your Delta Sharing client.
4. Query the shared tables.

warning

The credential file is a secret — it grants read access to your shared data. Store it in a secrets manager rather than in source control or a shared drive, and share it only over a secure channel. If it may have been exposed, ask us to rotate it. The same practices apply as for API keys.

A note on platform support

Because Open Sharing is an open protocol, support depends on the client you use rather than on us. Most modern data platforms either have a native connector or can use the open-source delta-sharing Python or Spark client.

Coverage is uneven in places, though — some platforms implement the protocol in one component but not another, so "our warehouse supports Delta Sharing" is worth verifying against the specific service you plan to query from. If you tell us your target platform we can confirm what we've seen work.

Choosing between Delta Sharing and the API

Delta Sharing is not a replacement for the API in every case. They suit different jobs:

• Delta Sharing — analytics and BI. Bulk data, historical trends, dashboards, joins against your own data warehouse.
• REST API and SDK — operational workflows. Submitting images, reacting to an individual result, driving an app or a rep workflow in near real time.

A common end state uses both: images and per-result reactions go through the API, while the analytical layer is fed by a share.

info

Sharing data into Neurolabs via Delta Sharing — for example supplying your own catalogue or store master data as a share rather than through the API — is not an established route today. It has been discussed for specific cases, so raise it with your Neurolabs contact rather than assuming either way.

Related

• Databricks Integration — building against the API from Databricks with the ZIA SDK
• Generate an API Key — for the operational, per-result integration path

Getting started

Delta Sharing is enabled per organisation. Contact your Neurolabs point of contact or support@neurolabs.ai with:

• Whether you want Delta Share or Open Sharing
• Your Databricks sharing identifier, if applicable
• Which layer you want to consume (bronze, silver or gold)