Grafana Infinity datasource: point a dashboard at an API that was never built for one

A datasource for the API you already have

The Grafana Infinity datasource visualises data from JSON, CSV, XML, GraphQL and HTML endpoints in Grafana, and the package description widens that to REST APIs and RSS and ATOM feeds, with the phrase "Do infinite things with Grafana" as the summary. The plugin is listed in the Grafana plugin catalog as `yesoreyeram-infinity-datasource`, and the documentation lives on grafana.com.

The problem it solves is specific and common. A team has an internal service that exposes a JSON API, or a system that only offers a CSV export, or a public feed with the numbers in it, and someone wants a chart. The Grafana-native answer is to write a Prometheus exporter, a StatsD shim or an OpenTelemetry collector, deploy it, and then own it. Infinity skips all of that: you give it a URL and a way to pick fields out of the response, and you get a panel.

That is a genuinely useful shortcut for operational questions. It is also a different kind of datasource from the ones Grafana is built around, and the rest of the plugin is shaped by that difference. The plugin advertises support for alerting, recorded queries, public dashboards and query caching, so the usual Grafana features are meant to work, but the data is fetched on demand rather than collected over time.

The repository lives under the `grafana` GitHub organisation, is authored by Grafana Labs in the package manifest, and is licensed Apache-2.0.

UQL, GROQ and JSONata reshape the response before the panel sees it

The feature list calls this flexible data manipulation with UQL, GROQ and JSONata, and it is the part of the plugin that does the actual work.

A raw API response is rarely in the shape a Grafana panel wants. There is a wrapper object, a field named `data` that holds an array, timestamps in a local format, and a page of results that has to be walked. The query languages are how you bridge that gap without writing code, and three of them are offered because they suit different shapes of data.

The manifest's keyword list gives a sense of the coverage: JSON, simple-json, graphql, csv, html, xml, url, scraping, web scraping, soap, atom, rss, feed. So the plugin can scrape a web page as well as call an API, and it handles SOAP and feeds alongside the mainstream formats.

The rest of the list is the Grafana surface area: utility variable functions, support for the Grafana node graph panel, and annotations. Node graph support is worth a second look, because it means the plugin is not only for time series. A dependency graph or a service topology read out of an API is a natural fit for what this datasource does.

The repository has a `docs/` directory, a `skills/` directory, `testdata/` and `tests/`, and a `CHANGELOG.md`, so the plugin is developed with the documentation, fixtures and tests that a plugin in the official catalogue is expected to have.

Nine ways to authenticate, which is the real feature list

The authentication options are where a datasource that calls other people's systems earns its keep, and the list is long: basic authentication, bearer token authentication, API key authentication, OAuth passthrough, OAuth2 client credentials, OAuth2 JWT authentication, AWS, Azure and GCP authentication, and digest authentication.

Each of those solves a different access problem. Basic auth covers the internal service with a username and password. Bearer and API key cover the modern token in a header. OAuth passthrough forwards the user's own session so a dashboard inherits the permissions of whoever is looking at it, which is the option that matters when a dashboard exposes data behind per-user authorisation. OAuth2 client credentials and JWT cover machine-to-machine flows. The cloud provider options cover the case where the endpoint is an object store rather than an API, which the dependency list confirms is in scope, since the Go module pulls in the AWS SDK v2, the Azure SDK for Go and the Google Cloud libraries.

The Go module also shows the pieces doing the work: `grafana-plugin-sdk-go` for the plugin framework, the `infinity-libs` framer modules, one per format, `csvframer`, `jsonframer`, `xmlframer` and `gframer`, plus `framesql` for the query layer, `transformations` and `macros`. The `icholy/digest` dependency accounts for digest authentication, `abbot/go-http-auth` is there for the basic auth handling, and OpenTelemetry is present in both the tracer and trace packages.

The plugin is a backend datasource, which means this Go code runs inside the Grafana server. That has an operational consequence: the credentials and the network path belong to the Grafana server, not to the browser of whoever opens the dashboard.

Installing it from the catalogue, the CLI, or a container

There are four documented routes, and the third one is the fastest way to see whether the plugin fits your data before you commit to it.

The plugin can be installed from the Grafana plugin catalog, or from the GitHub release page, where the readme notes that beta and pre-release versions are also available. The command line route is:

grafana-cli plugins install yesoreyeram-infinity-datasource

And the Docker route preinstalls the plugin into a running Grafana:

docker run -p 3000:3000 -e "GF_PLUGINS_PREINSTALL_SYNC=yesoreyeram-infinity-datasource" grafana/grafana-enterprise:latest

Note the image tag in that command, `grafana/grafana-enterprise:latest`, and the preinstall environment variable rather than a volume mount, which is the mechanism Grafana uses to fetch and install plugins at container start.

For local development, the repository has a `docker-compose.yaml` that extends a base compose file in `.config/`, mounts local dashboards and a `conf` directory, and points `GF_PATHS_CONFIG` at a `grafana.ini` inside that directory. The `server` script in the manifest runs `docker compose up --build`, and there is a separate `docker-compose-debug.yaml` for the debugging variant.

The build itself is webpack, with `build` and `dev` scripts pointing at `webpack.config.ts` with a production or development environment flag, and the package entry point is `dist/module.js`. The plugin is signed for distribution with `npx --yes @grafana/sign-plugin@latest`, which is a required step for publishing to the catalogue.

TypeScript in the browser, Go on the server

The architecture is the standard Grafana plugin shape with a modern dependency set, and the manifests make it easy to see which half does what.

The frontend is TypeScript and React, with `@grafana/data` and `@grafana/runtime` pinned at 13.1.1, which ties the plugin to a specific Grafana major version. There is also `@grafana/assistant` in the dependency list, and an `emotion` CSS package, plus a `components.json` file at the root, which is the shadcn-style configuration for a component-based frontend. The webpack config, the `tsconfig.json` and the jest config with a setup file are all present, along with a Playwright config for end to end tests and a `jest-setup.js`.

The backend is Go, and the module path is `github.com/grafana/grafana-infinity-datasource` with `go 1.27.0` declared, which is a recent toolchain floor worth checking against your build image. The `pkg/` directory holds the Go side and `src/` the TypeScript side.

Around them are the files that say this is an official catalogue plugin rather than a weekend project: a `Magefile.go` for build tasks, `provisioning/` with dashboards for the local environment, a `.changeset/` directory for versioned changes, a `cspell.config.json` with a `spellcheck` script, an `eslint.config.mjs`, a prettier configuration, a `CHANGELOG.md`, a `CONTRIBUTING.md`, and a `go.mod` and `go.sum` checked in alongside the JavaScript lockfile.

Where the Infinity datasource is the wrong tool

The limits come from the fetch-on-demand model, and they are not subtle once you start comparing it to a metrics pipeline.

The first is time series. A datasource that queries an API when a dashboard refreshes does not have a history of its own. Grafana's recorded queries feature is listed as supported, which means the plugin participates in the recording mechanism, but the underlying behaviour is still that each refresh goes back to the source. For a metric with high cardinality, a dashboard with many panels, and a refresh interval of a few seconds, that is a lot of calls to somebody else's API, and the API is the one that will rate limit you.

The second is alerting. Alerting on a value that is only known when a panel refreshes ties your alert latency to your dashboard refresh interval, and if nobody has the dashboard open, there may be no refresh at all. A push-based collector decouples the two.

The third is the deployment model. This is a backend plugin, so the Go process runs in the Grafana server with the credentials and the network position of the Grafana server. If the API is only reachable from a network segment where Grafana does not live, or if the credentials cannot be stored in the Grafana server, the plugin cannot reach it. The authentication list looks broad, but every one of those options still needs the server to be able to make the call.

The fourth is scope. The plugin reads. There is no write path, no backfill, and no storage of the fetched data, so it is not a replacement for a warehouse, and the SQL-like query languages are for reshaping a response, not for storing history.

The fifth is the naming history, which is worth noting for anyone grepping for it. The plugin id in the catalogue and in the install command is still `yesoreyeram-infinity-datasource`, even though the repository now lives under the `grafana` organisation and the author in the manifest is Grafana Labs. The id has to stay stable for existing installations, so expect the old name in commands and in dashboards.

An active catalogue plugin with a wide release line

The release history says this is a live project. v4.0.0 was published on 2026-08-11, v4.1.0 and v4.1.1 were both published on 2026-10-05, and the last push to the repository was on 2026-10-15. A major version in August and a minor plus patch in October is a normal cadence for a plugin that has to track Grafana releases.

The version numbering also tracks the Grafana dependency, since `@grafana/data` and `@grafana/runtime` are pinned to 13.1.1. That pinning is the upgrade cost to plan for. A Grafana major upgrade generally means a plugin major upgrade, and the plugin's own changelog is where you read what changed.

The documentation is unusually good for a plugin of this kind. There is a plugin documentation website, a demo video, and two learning journeys in the Grafana documentation, one on visualising CSV data and one on visualising JSON data, which are the fastest way to see whether the query language fits your data shape. There is also a live demo on Grafana Play that lets you try the plugin against a real dashboard without installing anything, at play.grafana.org.

The licence is Apache-2.0, with the licence file at the repository root, and the plugin is distributed through the official catalogue, so the usual questions about signing and distribution are already handled.

Editorial conclusion

Grafana Infinity fits a team that wants to look at an operational API, a CSV export, a feed or a scraped page in a Grafana panel without standing up a metrics pipeline for it, and it fits an organisation that already runs Grafana and wants one more source without new infrastructure. It does not fit a team with high cardinality time series that need recording, alerting rules and long retention, because the datasource fetches on demand rather than collecting, and it is the wrong choice if you cannot accept a backend plugin running inside the Grafana server. Before you deploy it, check the Go version your build needs, since the backend module declares go 1.27.0, and confirm that the endpoint and its credentials are reachable from the Grafana server rather than only from your laptop.

Frequently asked questions

Official sources

1. grafana/grafana-infinity-datasource on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases