This is documentation for the next version of Grafana documentation. For the latest stable release, go to the latest version.

Enterprise Open source

Grafana’s New API Structure

Overview

Going forward, Grafana’s HTTP API will follow a standardized API structure alongside consistent API versioning.

API Path Structure

All Grafana APIs follow this standardized format:

/apis/<group>/<version>/namespaces/<namespace>/<resource>[/<name>]

Where the final /<name> segment is used for operations on individual resources (like Get, Update, Delete) and omitted for collection operations (like List, Create).

Understanding the Components

Group (<group>)

Groups organize related functionality into logical collections. For example dashboard.grafana.app will be used for all dashboard-related operations.

Version (<version>)

These APIs will also uses semantic versioning with three stability levels:

LevelFormatDescriptionUse CaseEnabled By Default?
Alphav1alpha1Early development stage. Unstable, may contain bugs, and subject to removalFor testing new featuresNo
Betav1beta1More stable than alpha, but may still have some changesFor non-critical useNo
GAv1Generally Available. Stable with backward compatibility guaranteesFor production useYes

Alpha

Alpha versions should not be served unless explicitly enabled by a feature flag, and should be considered completely experimental and subject to major changes. An alpha version may undergo breaking changes without adding an additional version, and should not be relied upon by production workflows. Alpha versions may be removed completely, even without being promoted to a more stable level (e.g. an experimental API may be introduced as alpha for a new feature and subsequently removed completely, in case that feature gets canceled).

Beta

Beta versions should not contain breaking changes in the schema, but still may be subject to changes in handling logic or semantics. Breaking schema changes require a new published beta version (such as publishing v1beta2 for breaking changes to the v1beta1 schema). While beta versions are no longer considered experimental like alpha versions, they should still be disabled by default.

GA

GA versions are enabled by default, and can be treated as completely stable. The only changes that can be made to these APIs are bug fixes, and any other changes should instead result in a new published version of the API.

Namespace (<namespace>)

Namespaces isolate resources within your Grafana instance. The format varies by deployment type:

OSS & On-Premise Grafana

  • Default organization (org 1): default
  • Additional organizations: org-<org_id>

Grafana Cloud

  • Format: stacks-<stack_id>
  • Your instance ID is the stack_id. You can find this value by either:
    • Going to grafana.com, clicking on your stack, and selecting “Details” on your Grafana instance
    • Accessing the /swagger page in your cloud instance, where the namespace will be automatically populated on the relevant endpoints

Resource (<resource>)

Represents the core resource you want to interact with, such as:

  • dashboards
  • playlists
  • folders

Name ()

The <name> is the unique identifier for a specific instance of a resource within its namespace and resource type. <name> is distinct from the metadata.uid field. The URL path will always use the metadata.name.

For example, to get a dashboard defined as:

{
  "kind": "Dashboard",
  "apiVersion": "dashboard.grafana.app/v1beta1",
  "metadata": {
    "name": "production-overview", // This value IS used in the URL path
    "namespace": "default",
    "uid": "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8" // This value is NOT used in the URL path
    // ... other metadata
  },
  "spec": {
    // ... dashboard spec
  }
}

You would use the following API call:

GET /apis/dashboard.grafana.app/v1beta1/namespaces/default/dashboards/production-overview