Omni CLI gateway: unlock dashboard analytics not exposed by REST API
Build an internal Omni CLI gateway. The goal is to expose analytics data that only lives in the Omni CLI (like per-dashboard view counts and last-viewed timestamps) — data the official Omni REST API doesn't surface — to other tools and workflows via a simple internal API. Trigger it over HTTP: expose a single POST /omni-cli endpoint that other workflows or scripts can call. Main steps, at a high level: Wrap the Omni CLI behind the workflow, running an allowlisted subset of CLI commands rather than exposing it directly. Accept a request specifying what data is needed (e.g. dashboard ID) and run the corresponding CLI command. Return the CLI output as JSON, acting as a thin pass-through rather than a stateful cache. Use this to build things like an unvisited-dashboard report, since view counts and last-viewed data aren't in the REST API. Tools used: Omni CLI
What this prompt builds
A centralized gateway workflow that wraps the Omni CLI and exposes an allowlisted subset as an internal JSON API, enabling access to rich Omni data—like dashboard view counts and last-viewed timestamps—that the official REST API doesn't surface. Any workflow needing deeper Omni insights calls this single endpoint instead of building CLI plumbing or reconstructing state. The gateway also centralizes the Omni org API key behind connector-only authentication, eliminating credential sprawl across workflows.
The problem
Analytics teams and platform engineers who rely on Omni dashboards often need telemetry—like when a dashboard was last viewed or how many visits it's had—that simply doesn't exist in Omni's official REST API. That data lives only in the Omni CLI, which is dramatically richer than the API across the board. Without CLI-level access, every workflow that wants this insight has to build its own flow-level caching and storage to reconstruct view counts and timestamps over time—polling, persisting, and stitching together state that Omni already tracks natively. This gateway wraps the Omni CLI and exposes a deliberately allowlisted slice as an internal JSON API. Workflows call a single endpoint and get the CLI's JSON back—no caching layer, no reconstructed state, no CLI plumbing of their own—unlocking data that was otherwise unreachable.
Solution and impact
The workflow centralizes Omni CLI access behind a single internal POST /omni-cli endpoint, delivering data the REST API doesn't surface—like lastViewedAt and visit counts—via a thin pass-through instead of forcing every consumer to build stateful caching. It also confines the powerful Omni org API key to one governed workflow, locked to connector-only authentication, so credentials never appear in code and the blast radius stays contained. Expanding the allowlist of permitted operations is a deliberate, reviewable edit—no drift, no credential sprawl, and CLI-level insights available to any workflow in the tenant on demand.