Let me get something out of the way first.
This is a frustration post.
I have been working in software engineering for more than 13 years, and I have been building with and extending Qlik since Qlik Sense 2.2.
I don’t claim to know everything about Qlik. I don’t claim to speak for every customer, developer, partner or user. But after spending the better part of a decade building real software around the platform, maintaining it, upgrading it, breaking it, fixing it and occasionally swearing at it, I think I have earned the right to have an opinion.
And my opinion is that somewhere along the way, Qlik stopped feeling like a platform that wanted developers around.
The frustrating part?
It wasn’t always like this.
When building on Qlik was genuinely exciting
I started extending Qlik around the Qlik Sense 2.2 era, back in 2016.
And honestly, it was exciting.
Sense was still relatively young. The APIs weren’t perfect. Documentation was very patchy. There were things you learned because somebody had figured them out, written a blog post about them, uploaded something to Qlik Branch or answered a question buried three pages deep in the Community. But that was fine. We understood that we were early.
More importantly, the platform felt like it was ours to experiment with.
Nobody was writing love letters to AngularJS, but it was stable. RequireJS wasn’t exactly the future of frontend development either, but again: it worked. And once you understood the Capability APIs, extensions, mashups and the Engine API, you could do some ridiculous things.
Integrating D3?
Sure.
Building completely custom interfaces over the Qlik engine?
Absolutely.
Connecting Qlik to Amazon Alexa because somebody asked whether a dashboard could talk?
Why not?
There was a feeling that the Qlik engine was this incredibly powerful thing and the APIs were there to let you do whatever you could imagine with it.
The sky genuinely felt like the limit.
Qlik itself described Sense 2.2 as bringing “powerful new developer APIs and capabilities”, including new app integration and visualization APIs. That was the direction of travel at the time: give developers more ways into the platform.
And around that technology, a community was forming.
Qlik Branch actually felt like a community
Qlik Branch mattered.
Not because everything on it was production-ready. It wasn’t.
Not because every extension was brilliant. They weren’t.
It mattered because people were building things.
People were experimenting.
People shared extensions, libraries, techniques and ideas simply because they thought they were useful.
At the launch of the Trusted Extension Developer programme, Qlik itself described Branch as a community of around 30,000 members sharing and collaborating on open-source projects.
Think about that for a second.
Thirty thousand people around an analytics platform, many of them creating things that Qlik itself hadn’t thought to build.
That is incredibly valuable.
There was a sense that you were part of something bigger than whatever project you happened to be working on that week.
And the same Qlik also talked loudly about data literacy.
I loved that initiative. Maybe more than most.
I didn’t come from some prestigious data science background. I was fortunate enough to have mentors who took the time to teach me about data, analytics and software. People shared what they knew with me, and eventually I built a career from it.
So the idea that data literacy shouldn’t belong to some small group of specialists genuinely meant something to me.
Qlik made courses available for free through the Data Literacy Project and talked about making the ability to understand and challenge data accessible to everyone.
That was a version of Qlik I could believe in.
A great engine. An open developer ecosystem. Free educational initiatives. A growing community. It wasn’t perfect. But it felt like it was going somewhere.
Then something changed.
From community to programme
Qlik Branch eventually gave way to a much more controlled ecosystem.
The Trusted Extension Developer programme — TED — was supposed to provide confidence that extensions had been tested for quality, security and compatibility. On paper, that makes perfect sense.
Enterprise customers need governance. You cannot install arbitrary JavaScript into production environments and hope for the best.
My problem wasn’t the idea. My problem was the experience.
Getting through the process felt increasingly opaque. Applications appeared to disappear into a black hole. Waiting times could be ridiculous, and from where I was sitting it became much easier to find established vendors and partner-backed organisations in that ecosystem than the hobbyist developer who had built something interesting over a weekend.
Maybe that wasn’t intentional.
But intent doesn’t really matter when that is the experience your developer community has. The old feeling of:
“Build something cool and show us what you’ve made.”
started feeling more like:
“Who are you, who do you work for, and what commercial relationship do you have with us?”
That is a very different developer ecosystem. And somewhere around that period I started feeling that Qlik was becoming less interested in developers who simply wanted to learn, experiment and build.
Then Qlik Sense Desktop stopped being free
For me, this was one of the clearest signals. On 14 July 2020, free access to Qlik Sense Desktop ended. From that point onward you needed to authenticate it against an appropriate Qlik Sense Enterprise or SaaS environment.
I remember thinking:
Why would you put another barrier between developers and your technology?
A developer downloading your product, experimenting locally, breaking things and learning your APIs is not a cost centre. That person might be the reason your product gets introduced into their next company. That student might become a consultant. That hobbyist might build an extension thousands of customers eventually use.
Microsoft understands this. AWS understands this. Cloudflare understands this. Stripe understands this. GitHub understands this. Developers need somewhere inexpensive — ideally free — to play.
For a while Cloud still provided a reasonably accessible route in.
Then that changed too. Today, Qlik Cloud Analytics Starter begins at $300 per month, billed annually, for ten users. That might be perfectly reasonable pricing for a small business buying an analytics platform.
It is not a playground. There is a difference. And I think Qlik has increasingly forgotten it.
The Cloud-first era
Then came the aggressive push toward Qlik Cloud. This is where things really started becoming difficult for me. I understand SaaS. I build SaaS applications. I understand rolling releases. I understand why vendors don’t want dozens of supported versions running indefinitely. I understand CI/CD, feature flags, backwards compatibility and why sometimes things have to change.
What I don’t accept is treating production integrations like collateral damage. When I build an application against somebody else’s API, I am trusting them. If that application serves thousands of users, their API becomes infrastructure.
Changes matter.
And over the years I have seen Cloud changes break integrations, extensions and embedded applications in ways that have required urgent investigation from developers who changed absolutely nothing themselves.
To Qlik’s credit, the developer changelog today is much better than what we had historically. Deprecations are increasingly documented and newer API namespace migrations promise defined notice periods.
Good.
That is exactly what should happen. But developers remember the incidents that got us here.
And then there was qlik-embed
For years, a huge amount of custom Qlik development was built using the Capability APIs.
Were they modern? Absolutely not.
AngularJS and RequireJS should probably be displayed in a museum at this point. But the Capability APIs were known. We understood them.
We understood their limitations. We understood their weird behaviours. And importantly, we had years of production knowledge around them.
Then came the next answer: qlik-embed.
Qlik now explicitly describes qlik-embed as its primary embedding framework and recommends it for new integrations. Conceptually, I agree with the direction. Web components. Modern authentication.
Better compatibility with browser restrictions around third-party cookies. React and Svelte integrations. A path away from AngularJS and RequireJS.
All sensible.
The problem is that developers don’t build production applications from architecture diagrams.
We build them from APIs.
And especially during its earlier releases, trying to reproduce functionality that had become routine with the Capability APIs could become an exercise in figuring out whether something was unsupported, undocumented, broken or simply implemented completely differently.
Even today I regularly find things that should be straightforward turning into experimentation. Error handling remains one of my biggest frustrations. You shouldn’t need archaeological skills to figure out why an embedded image failed to render.
You shouldn’t need to experiment with three different approaches to perform something that sounds trivial.
And performance remains something I watch very carefully.
This is particularly frustrating because modern browser authentication is one of the strongest reasons to move. Qlik’s current guidance pushes OAuth2 SPA and OAuth2 Impersonation for embedded Qlik Cloud applications, with qlik-embed sitting at the centre of that experience.
So eventually you aren’t really deciding whether you like the new framework. You’re deciding how long you can avoid migrating.
The API-key incident that finally got me
Then we come to the change that pushed me into actually starting this account, although it took me a while to get to it.
API keys.
Qlik deprecated the old Developer role and moved API-key management into the new Manage API keys permission model. Security-wise? Fine. Actually, I agree with the principle.
API-key creation should be governed by explicit permissions.
The problem is what happened operationally.
In environments I was responsible for, integrations that had been happily working suddenly weren’t. Automations failed. Applications failed. Production systems that depended on API authentication needed intervention.
And while trying to work out what had happened, we eventually discovered that permissions needed to be changed.
Qlik’s own changelog now acknowledges that users and groups which weren’t migrated to the new Manage API keys permission may experience disruptions.
That sentence is doing quite a lot of work.
Because an “API disruption” isn’t an abstract inconvenience when somebody has built production software around your platform. It means engineers being pulled into incidents. It means customers asking why something stopped working. It means somebody explaining that nothing changed in our release, but something changed underneath us.
And every time this happens, trust gets slightly smaller.
The frustrating thing is that Qlik is still brilliant
This is where I probably confuse anyone expecting this account to simply be a Qlik hate blog.
I don’t hate Qlik. Quite the opposite. I think the Qlik engine is fantastic. The associative model remains one of the most interesting ideas in analytics. There are things I can do in Qlik that remain irritatingly difficult in competing products.
Even outside the Qlik community, you still see developers and BI practitioners saying exactly that. In one r/BusinessIntelligence discussion about moving from Tableau to Qlik, developers praised the associative engine and Qlik’s flexibility.
In another discussion comparing alternatives to Power BI, people specifically called out Qlik’s JavaScript embedding capabilities and Nebula as strengths.
So this isn’t nostalgia from somebody refusing to learn another tool. The technology has real strengths. Which makes watching the surrounding developer experience deteriorate even more frustrating.
And now, obviously, AI
Because apparently no software article written in 2026 can avoid AI. Qlik has Qlik Answers. Qlik has agents. Qlik has MCP.
And to be fair, giving external LLMs access to governed Qlik data through MCP is genuinely interesting. I like MCP. I like the idea of connecting my own model to my Qlik tenant.
But even here there is a Qlik-shaped catch. Your LLM costs money.
Fine. Then your Qlik MCP usage also consumes Qlik Answers capacity.
Qlik’s own MCP FAQ says that five MCP tool calls consume one Qlik question.
And your LLM subscription or API usage is separate. As of writing, Qlik Cloud Premium includes 1,000 Answers/MCP questions per month.
Which means developers building agents need to think very carefully about tool-call design.
An agent that wanders through tools unnecessarily isn’t merely inefficient. It is spending your Qlik capacity while it thinks.
Build an agent badly enough and you can burn through a resource shared by everyone else surprisingly quickly.
This is the kind of detail that disappears underneath the words AI-powered analytics on a pricing page. It is also exactly the kind of thing developers actually need to talk about.
I’m clearly not the only person wondering what happened
One thing that pushed me toward writing publicly was looking outside the traditional Qlik bubble.
There was a 2024 Reddit thread from someone moving from Power BI to Qlik who basically said:
Where is everybody?
They could find endless Power BI material, but struggled to find equivalent Qlik communities, YouTube channels and independent resources.
Another developer replied that the Microsoft ecosystem simply has far more people publicly advocating for and teaching the platform.
That matters.
Communities don’t die because somebody closes a forum. They die slowly. One person stops writing extensions. Another stops blogging. Someone else decides maintaining their open-source library isn’t worth it. A consultant stops recommending the platform.
A developer looking for something to learn picks Power BI instead because they can download it and find 5,000 tutorials.
Eventually somebody asks:
Where did all the developers go?
Perhaps the better question is:
What reasons did we give them to stay?
So what is The State of Embed?
I don’t know how much any of this can actually change. I’m one developer on the internet writing under a pseudonym.
Qlik is a large company with enterprise customers, revenue targets, shareholders, sales organisations, product roadmaps and priorities that are significantly bigger than whether I enjoyed building mashups in 2016.
I understand that.
But I also don’t think that means those of us actually building on these platforms should stop talking about what they are like to use.
And that is really why this account exists.
This isn’t going to be a weekly exercise in shouting Qlik bad, Power BI good or Tableau good, Qlik bad.
They all have problems. Trust me, we’ll get to them.
I want to talk about embedded analytics from the perspective that rarely makes it into vendor presentations:
The person who actually has to build the thing. What works. What doesn’t. What the documentation forgot to mention. What breaks in production.
What looks fantastic in a demo but becomes painful when you need to support 5,000 users. The API that saved three weeks of development. The API that stole three weeks of development. The clever workaround you probably shouldn’t need. And occasionally, yes, the things that annoy me enough to write several thousand words about them.
Because the criticism here comes from somewhere important:
I still care about the product.
I want Qlik to be better. I want Qlik to be a platform developers are excited to discover again. I want someone with curiosity and a laptop to be able to stumble into Qlik, build something completely unnecessary with it on a Saturday afternoon, publish it on Sunday and accidentally start a career.
That world existed once.
I know because it helped create mine. Maybe we can’t get all of it back. But at the very least, those of us who have been here long enough should stop pretending that nothing was lost along the way.
So this is The State of Embed.
No sales deck.
No Gartner quadrant.
No partner-approved messaging.
Just what happens when the dashboard ends…
and the code begins.