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 in it trustworthy. But a data product nobody uses is just a very well-organized shelf. This final blog puts the consumer center stage: how do users discover your data product, how do they build with it, and how do you expose your data as an API endpoint for applications outside Qlik?

The Data Marketplace

Think of the Data Marketplace as the storefront of your data product ecosystem. It's 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 to work right away, without needing to consult the data team or navigate the technical complexity of the catalog.

When a user opens the Marketplace, they see a searchable, filterable overview of all the 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 data product manager's documentation, and the owner's contact details. From there, the user can take action right away, including creating an analytics app directly from the product. The search and filter options let users refine by domain, quality score, data type, and more. This is where the investments from part 2 and part 3 pay off directly: well-documented, high-quality products are much easier to find and much more likely to be chosen.

Publishing to the Marketplace

Publishing a data product to the Marketplace requires activating 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. Important to understand: activating publishes a copy to the selected managed space, but the underlying datasets remain in their original location. The Marketplace is a discovery and access layer, not a data movement mechanism.

Publishing a data product requires the Data Product Manager role, and the Marketplace feature is available on Qlik Cloud Analytics Premium and Enterprise plans, and 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 immediately sees the value. 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 visualizations.

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

A practical tip for data product managers: make sure the associations between datasets are well defined before you publish. An analyst who creates an app and finds that the tables don't join as expected quickly loses trust 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've carefully curated, documented, and quality-checked can be used not just by Qlik Sense apps, but by any application that can send an HTTP request. Think custom applications built by developers, Python or R scripts written by data scientists, operational systems that need data periodically, or other BI tools. Your QVDs and datasets become a service.

Creating an endpoint

Activating an API endpoint is simple: within the data product, navigate to Edit > API endpoints, select the datasets you want to expose, and save. That's the entire configuration in the interface. Qlik then generates an OData endpoint for each selected dataset and automatically produces an OpenAPI-compatible 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 in the query URL when calling the API. This means, 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's side at the time of the call and is not pre-configured in the data product. It's worth keeping track in the endpoint documentation of 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 make that refresh frequency visible in your endpoint documentation.

It's also good to be clear about what the API does and doesn't enforce. Row-level security in Qlik is applied at the app's load script level via Section Access, not at the dataset or data product level. This means the API endpoint doesn't enforce 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 needs 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've 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 exposing it to consumers via the Marketplace and as an API. What I find most exciting about where we've landed is who this now reaches. Data products in Qlik are no longer reserved only for organizations 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.

Read through this series and wondering exactly where to start now? Here's 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 findability cause friction. That's your pilot.
3. Register the key datasets for that domain in the Qlik Catalog. Even without a full data product, the cataloging and quality metrics are valuable right away.
4. Build the data product following 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 mandatory quality dimensions as described in part 3.
6. Activate the product on the Marketplace and pay close attention to what happens. Who's using it? What questions come in? What's missing?
7. Keep iterating. A data product is a living thing, not a one-time delivery.

When it comes to data products, the investment is real. Good data products take time and organizational effort to build properly. But the payoff is real too: faster insights, greater trust in data, less duplication, and a data foundation that's truly ready for whatever AI initiative comes next.