Putting your Qlik data product to work - Part 4

In the three previous blogs in this series, we discussed the concept of data products, how to build one in Qlik and how to make the data inside it trustworthy. But a data product nobody uses is just a very well-organised shelf. This final blog puts the consumer centre stage: how do users discover your data product, how do they build with it and how do you make your data available as an API endpoint for applications outside Qlik?

The Data Marketplace

Think of the Data Marketplace as the shop window of your data product ecosystem. It is a self-service discovery layer within Qlik Cloud where business users and analysts can browse available data products, assess their quality and relevance and get started right away, without having to consult the data team or navigate the technical complexity of the catalog.

When users open the Marketplace, they see a searchable, filterable overview of all data products they have access to. For each product, they can see the name, description and domain, the associated datasets and their Trust Scores, lineage information, the documentation from the data product manager and the owner's contact details. From there, users can take action directly, including creating an analytics app straight from the product. The search and filter options let users narrow down by domain, quality score, data type and more. This is where the investments from part 2 and part 3 pay off immediately: well-documented, high-quality products are much easier to find and far more likely to be chosen.

Publishing to the Marketplace

Publishing a data product to the Marketplace requires you to activate it from the Data Product management interface. During activation, you select the managed space where the published copy will appear, and users with the ‘Can Consume’ role in that space can then see the product. It's important to understand that activating publishes a copy to the selected managed space, but the underlying datasets stay in their original location. The Marketplace is a discovery and access layer, not a mechanism for moving data.

Publishing a data product requires the Data Product Manager role, and the Marketplace feature is available on Qlik Cloud Analytics Premium and Enterprise subscriptions, as well as on Qlik Talend Cloud Premium and Enterprise. Not sure what applies to your environment? Ask your Qlik administrator.

Creating a Qlik Sense app from a data product

This is where the average Qlik analyst sees the value straight away. From the Marketplace, a user can create a new Qlik Sense app based on a data product with a single click. Qlik then loads the datasets into the app, automatically resolves the associations between tables based on the relationships defined in the product, and drops the user straight into the familiar app development environment, ready to start building visualisations.

For teams that previously had to request data from a data engineer, set up a connection, figure out which QVDs to load and define associations manually, this is a meaningful step forward. Users with the ‘Can Consume’ role can do all of this without scripting skills or knowledge of the underlying data architecture. The quality metrics they saw in the Marketplace are visible in the data they work with. So they start with confidence instead of doubt.

A practical tip for data product managers: make sure the associations between datasets are properly defined before you publish. An analyst who creates an app and finds that the tables don't link up as expected will quickly lose confidence in the product, even if the data itself is perfectly fine. If the relationships aren't obvious from the column names, document them in the product description.

API endpoints: beyond Qlik

This is a feature that often surprises Qlik users: data products can expose datasets as API endpoints. That means the data you have carefully curated, documented and quality-checked can be used not only by Qlik Sense apps, but by any application that can send an HTTP request. Think of custom applications built by developers, Python or R scripts from data scientists, operational systems that periodically need data, or other BI tools. Your QVDs and datasets become a service.

Creating an endpoint

Enabling an API endpoint is simple: within the data product, navigate to Edit > API endpoints, select the datasets you want to expose and save. That is the entire configuration in the interface. Qlik then generates an OData endpoint for each selected dataset and automatically produces an OpenAPI-compliant specification based on the dataset metadata, so developers can immediately see what the endpoint returns and how to call it, without having to ask anyone. If you invested in good column descriptions and semantic types in part 3, that investment pays off here too.

Because the endpoints use the OData protocol, consumers can add filter expressions directly to the query URL when calling the API. For example, you can filter a Sales Transactions dataset by date range or region without retrieving the entire dataset. Below you can see what such a call looks like, filtered on records where the region is Europe and the order date falls within 2025:

OData uses standard comparison operators: eq (equal to), ge (greater than or equal to), lt (less than). Multiple conditions are combined with and. Dates follow the ISO 8601 format. String values are enclosed in single quotes. This filtering is handled entirely on the consumer side at the time of the call and is not preconfigured in the data product. It pays to note in the endpoint documentation which fields are most useful to filter on, so consumers can query efficiently.

What you need to know before publishing an endpoint

Access to API endpoints is governed by the same space-based permissions as the rest of Qlik Cloud. Every call must be authenticated, and there are no public or anonymous endpoints. The API returns data as it was loaded during the last reload. If freshness matters to your consumers, make sure your reload schedule meets their expectations and state that refresh frequency clearly in your endpoint documentation.

It's also good to be clear about what the API does and does not enforce. Row-level security in Qlik is applied at the level of an app's load script through Section Access, not at dataset or data product level. This means the API endpoint does not enforce any row-level restrictions. All authenticated users with access to the endpoint see the full dataset as stored. If row-level filtering is a requirement for your API use case, that logic has to be handled outside the data product.

Finally, treat creating an API endpoint with the same care as publishing an external API. Define a clear contract, document it well, limit the exposed columns to what consumers actually need and communicate changes well in advance.

Bringing it all together

Across these four blogs, we have covered a lot of ground: from the abstract concept of a data product and the Data Mesh philosophy, through building and managing a data product in Qlik, to opening it up to consumers via the Marketplace and as an API. What I find most inspiring about where we have ended up is who this now reaches. Data products in Qlik are no longer reserved for organisations with large Talend Cloud implementations and dedicated data engineering teams. If you have a Qlik Cloud Analytics environment and a QVD layer, you have everything you need to get started.

Have you read this series and are you wondering where exactly to start? Here is a short roadmap:

1. Check whether your Qlik environment includes the Data Products functionality and which capabilities are available on your subscription type. A conversation with your Qlik administrator will answer this quickly.
2. Identify one business domain where data quality and discoverability are causing friction. That's your pilot.
3. Register the key datasets for that domain in the Qlik Catalog. Even without a full data product, the cataloguing and quality metrics are immediately valuable.
4. Build the data product using the steps in part 2. Start simple: three to five datasets, good documentation, clear ownership.
5. Assign semantic types, run the AI rule suggestions and set up the required quality dimensions as described in part 3.
6. Activate the product on the Marketplace and pay close attention to what happens. Who is using it? What questions come in? What is missing?
7. Keep iterating. A data product is a living thing, not a one-off deliverable.

When it comes to data products, the investment is real. Good data products take time and organisational commitment to build properly. But so is the return: faster insight, greater trust in data, less duplication and a data foundation that is truly ready for whatever AI initiative comes next.