When we started building nBlick, our architecture naturally followed the product: users created analyses in nBlick, our pipelines queried multiple AI engines, collected answers and citations, calculated visibility metrics, identified opportunities, and turned those opportunities into actions and generated content.
That model worked well until companies started asking for something different: they wanted the capabilities behind nBlick inside their own products, without requiring their customers to adopt nBlick itself.
That sounds like a small distinction. Architecturally, it isn't. Making an internal feature available through an endpoint is relatively easy. Making the entire nBlick workflow available as infrastructure, with isolated customers, asynchronous execution, permissions, retries, artifacts, and a stable resource model, required us to rethink where the product ended and the platform began.
We've now reached that milestone. The nBlick analysis and content-generation pipeline is available through our White Label API. Partners can provision their own customers, run AI visibility analyses, inspect the evidence behind the results, retrieve recommended actions, and execute those actions to generate content, all without their users ever needing an nBlick account.
From a website to evidence
At the center of the API is a workspace. A partner creates one for a customer, configures what should be analyzed, and can then launch a visibility report:
POST /v1/workspaces/{workspace_id}/visibility-reports
The API deliberately hides most of the complexity behind that request. A report triggers the same analysis machinery we use inside nBlick: we analyze the target website, build the relevant prompt set, query the configured AI engines, process their responses and citations, and aggregate the results into metrics such as mention rate, platform coverage, ranking, sentiment, citation share, and competitive visibility.
We also preserve the evidence behind those metrics. If a report says that a brand has poor visibility for a particular topic, a partner shouldn't have to trust an opaque score produced by nBlick. The API exposes the prompts that were evaluated, the responses produced by the models, and the sources they cited.
That distinction matters to us. AI visibility is inherently probabilistic and the ecosystem is changing quickly. A metric without its underlying evidence is difficult to debug, difficult to explain to a customer and, ultimately, difficult to trust.
Closing the loop
Exposing the analysis was only part of what we wanted to accomplish. One of the principles behind nBlick is that measuring visibility should lead to an action. If we detect that a competitor repeatedly appears for an important question while a brand doesn't, telling the customer that their visibility score is 42 instead of 58 isn't enough.
We already have the evidence required to understand the gap. We should be able to do something with it.
The White Label API therefore exposes the next part of the pipeline as well. nBlick turns findings from an analysis into concrete actions, and those actions can be executed programmatically:
POST /v1/actions/{action_id}/executions
An execution can produce the actual artifact required by the recommendation. In the case of content, that means a generated article with its metadata, sources, and images, ready to be consumed by the partner's own publishing workflow.
The API isn't exposing a collection of unrelated AI features. It is exposing the loop that nBlick itself runs: observe → understand → act → measure again. The entire workflow can happen inside the partner's product and under the partner's brand.
Building a platform behind the product
Getting to this point forced us to solve a number of engineering problems that weren't visible when nBlick was only consumed through our own application.
The most important was tenancy. A partner may manage hundreds or thousands of customer analyses, so resources need explicit ownership and isolation. Reports, actions, and generated artifacts cannot depend on assumptions from our first-party application about who the current nBlick user is.
Authentication and authorization had to follow the same model. API credentials are scoped, permissions can be constrained, and operations are evaluated against the workspace they belong to rather than relying on application-level ownership assumptions.
Execution also needed different guarantees. AI analysis is not a normal request-response workload: it involves external models, crawling, multiple stages of processing, and operations that can take considerably longer than a conventional HTTP request. Reports and content generation therefore run asynchronously, with bounded execution and explicit lifecycle states that partners can integrate into their own systems.
Idempotency matters for the same reason. Networks fail. Clients retry. Workers restart. A production API has to assume all of those things will happen without accidentally creating duplicate reports or repeating expensive work.
Generated artifacts introduced another boundary. Images and other assets need to belong to the correct workspace and be delivered securely without exposing our internal storage architecture. The same principle applies throughout the API: partners should interact with stable nBlick resources, not implementation details of the systems running behind them.
Why this is a bigger milestone for us
The most important part of this release isn't the number of endpoints we've added. It's that the architecture of nBlick no longer assumes that nBlick's UI is the only way to consume what we build.
An SEO platform can add AI visibility to its existing customer experience. An agency can incorporate the evidence and recommendations into its own reporting. A CMS or hosting platform can analyze a customer's visibility and act on the findings close to where the content actually lives. Larger partners can build completely different experiences while using nBlick as the analysis and optimization engine underneath them.
As we improve our models, analysis methodology, prompt generation, recommendation engine, and content pipelines, integrations built on top of the API benefit from those improvements without having to rebuild that infrastructure themselves.
We are still building nBlick as a product, and our own interface remains an important way to use it. But there is now a clear boundary underneath it. nBlick is no longer just a place where you measure AI visibility. It can now be the infrastructure another product uses to understand and improve it.
The first version of the White Label API is available now. Authentication, workspaces, visibility reports, actions, executions, and the underlying resource model are all documented in the White Label API documentation.
If you're building a product where AI visibility should be a capability rather than another dashboard, we'd like to hear what you build with it.