Tibber Token: So bekommst Du Deinen Access Token

Personal Access Token (GraphQL) schnell erstellen, sicher speichern und sauber testen – plus Troubleshooting & Security-Checkliste.

Schnellstart: Tibber Access Token in 5 Schritten

Du bist neu bei Tibber und willst Deinen Access Token? Kein Stress: hier bekommst Du die Schritt-für-Schritt-Anleitung – inklusive Sicherheits-Checkliste, Test-Abfragen und den häufigsten Fehlern (401/403), die in der Praxis immer wieder auftauchen.

Was ist der Tibber Token?

Der Tibber Token ist Dein persönlicher „Schlüssel“ zur Tibber-API. Damit kannst Du – abhängig von Deinen Berechtigungen – z. B. Strompreise abrufen, Verbrauchsdaten analysieren oder Integrationen für Smart Home / Lade-Setups bauen.

Technisch ist das bei der GraphQL API ein Bearer Token: Du sendest ihn bei jeder Anfrage im HTTP-Header Authorization: Bearer <TOKEN>. Wer den Token besitzt, kann die API so benutzen, als wär’s Dein Account – deshalb gilt: behandle ihn wie ein Passwort.

Wenn Du tiefer einsteigen willst: Bei Tibber dreht sich vieles um dynamische Strompreise. In den Guides auf tiny-tool findest Du dazu z. B. dynamische Stromtarife, Hintergründe zu Erneuerbaren & Strompreis und den Praxis-Usecase Tibber Pulse.

Technischer Hintergrund: Authentifizierung vs. Autorisierung

Wenn es beim Tibber Access Token hakt, liegt der Fehler selten „irgendwo in GraphQL“, sondern fast immer in einem ganz klassischen Auth-Thema. Zwei Begriffe helfen beim Debugging sofort:

401 vs. 403 – technisch sauber unterscheiden

Warum Bearer Tokens so sensibel sind

Ein Personal Access Token für Tibber GraphQL ist ein Bearer Token. „Bearer“ ist wörtlich zu nehmen: wer ihn trägt, darf. Es gibt keine zusätzliche „Bindung“ an ein Gerät oder eine Session, wenn Du das nicht selbst durch Architektur erzwingst (z. B. durch serverseitige Nutzung und Zugriffskontrollen).

PAT (GraphQL) vs. OAuth2 (Data API)

Bei Tibber triffst Du 2026 häufig auf zwei Auth-Ansätze, die ähnliche Ziele haben, aber für unterschiedliche Szenarien gebaut sind:

Wenn Du gerade nur Deinen eigenen Tibber Token erstellen willst: bleib beim PAT. Wenn Du eine App für andere baust: plane OAuth2 von Anfang an ein (Datenminimierung, Widerruf, kurze Token-Laufzeiten).

Schritt-für-Schritt: Tibber API Token erstellen

1. Registrieren: Falls noch nicht geschehen, Konto bei tibber.com anlegen.
2. Einloggen: Im Web mit Deinen Zugangsdaten anmelden.
3. Developer Portal öffnen: developer.tibber.com aufrufen.
4. Token erstellen: Unter Access Tokens auf Create Token klicken.
5. Token sichern: Token sofort kopieren und sicher speichern (er wird oft nur einmal angezeigt!).
6. Testen: Mit den Beispiel-Requests weiter unten (API-Test).

Sicherheit: So gehst Du sorgsam mit Deinem Token um

→ Wenn Du nur eine Sache mitnimmst: Checkliste – und Token nie ins Frontend.

• Geheim halten: niemals posten, niemals in Tickets/Screenshots leaken.
• Sicher speichern: Passwort-Manager oder Secret-Store statt „Notepad“.
• Im Code schützen: über ENV-Variablen / Secrets injizieren – nicht als Klartext im Repository.
• Aufräumen: ungenutzte Tokens löschen; bei Verdacht sofort rotieren.

Sicherheitsarchitektur für produktive Umgebungen

Ein Tibber Access Token ist technisch „nur“ ein String – operativ ist er aber ein hochwertiges Secret. Sobald Du das nicht mehr nur lokal testest, sondern dauerhaft betreibst (Home-Server, NAS, Mini-PC, Cloud-VM), brauchst Du eine klare Architektur-Entscheidung: Wo liegt das Secret, wer darf es lesen, und wo könnte es unabsichtlich auftauchen?

Reverse Proxy: hilfreich, aber nicht automatisch sicher

Ein Reverse Proxy (z. B. Nginx, Traefik, Caddy) kann TLS terminieren, Auth erzwingen und Requests routen. Er kann aber auch zum Risiko werden:

• Header-Weitergabe: Achte darauf, dass Authorization-Header nicht versehentlich geloggt oder an interne Services weitergereicht werden, die ihn nicht brauchen.
• Access Logs: Manche Setups loggen Request-Header oder Query-Strings (z. B. bei Debug-Mode). Das ist ein häufiger Leak-Kanal.
• „Schnell mal nach außen“: Ein öffentlich erreichbarer Proxy-Endpoint ohne harte Auth kann Dritte zu Abuse/Rate-Limit-Problemen einladen.

Logging-Leaks: der Klassiker

Secret Management: was in der Praxis funktioniert

Token Rotation & „mehrere Tokens im Umlauf“

Rotation ist nicht nur „Security-Feeling“, sondern echte Schadenbegrenzung. Wichtig ist dabei der Prozess:

1. Neuen Token erstellen (parallel, ohne Downtime).
2. Deploy umstellen (ENV/Secret aktualisieren) und Smoke-Test fahren.
3. Alten Token deaktivieren – erst wenn alles stabil läuft.
4. Dokumentieren, wo Tokens liegen (welches System, welcher Zweck), damit Du bei Incidents schnell reagieren kannst.

Rate Limits & Retries ohne Abuse

Wenn Du 429 siehst, ist der Reflex oft „noch schneller nochmal“. Das ist genau falsch. Besser:

• Exponential Backoff mit Jitter (kleine Zufallskomponente), um Lastspitzen zu vermeiden.
• Max Retries begrenzen (z. B. 3–5 Versuche) und dann sauber failen.
• Caching für Daten, die sich nicht sekündlich ändern (z. B. Preisinfos), statt Polling.

Datenschutz und verantwortungsvoller Umgang mit Energiedaten

Auch wenn es „nur“ Stromdaten sind: Verbrauchs- und Zeitreihen-Daten sind in der Praxis sensibel. Aus Lastprofilen lassen sich Muster ableiten (Anwesenheit, Tagesabläufe, ggf. sogar Urlaubszeiten). Deshalb lohnt es sich, beim Tibber GraphQL Zugriff ein paar Basics sauber zu machen – ohne Drama, aber konsequent.

Hinweis: Das ist keine Rechtsberatung. Es sind technische Best Practices, die in fast jedem System helfen, Risiken zu reduzieren.

Häufige Fragen und Stolperfallen

• Token wird nach der Erstellung nicht mehr angezeigt? Ja, das ist normal. Daher: direkt kopieren und sicher speichern.
• Demo-Account „Arya Stark“? Dann bist Du vermutlich im falschen Login-Kontext. Ausloggen, Cookies prüfen, neu einloggen.
• Token verloren? Kein Drama: neuen erstellen, alten löschen.
• Läuft der Token ab? Bei PATs oft nicht automatisch – er bleibt gültig, bis Du ihn deaktivierst/löschst.
• Token löschen? Im Developer Portal deaktivieren/entfernen.

Fazit

Viel Spaß beim Ausprobieren – und willkommen in der Welt smarter Energie. 🙂

API-Test (curl / GraphQL)

Ein schneller Check spart Dir später Debugging-Zeit: Die GraphQL API erwartet den Token als Bearer im Authorization-Header.

curl https://api.tibber.com/v1-beta/gql \
  -H "Authorization: Bearer DEIN_TIBBER_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
  "query": "{ viewer { name } }"
}'

curl https://api.tibber.com/v1-beta/gql \
  -H "Authorization: Bearer DEIN_TIBBER_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
  "query": "{ viewer { homes { currentSubscription { priceInfo { current { total energy tax startsAt } } } } } }"
}'

Im Tibber GraphQL Explorer testen →

Praxis: Node.js & Python (Timeout, Errors, Retry)

Die curl-Tests oben sind perfekt, um „lebt der Token?“ zu prüfen. Für echte Skripte brauchst Du aber drei Dinge zusätzlich: ENV-Handling, saubere Fehlerbehandlung und Retries mit Backoff. Die folgenden Beispiele sind bewusst „produktionsnah“, aber gut lesbar gehalten.

/**
 * Node.js 18+ (global fetch)
 * ENV: export TIBBER_TOKEN="..."
 */
const TIBBER_GQL_URL = "https://api.tibber.com/v1-beta/gql";
const TOKEN = process.env.TIBBER_TOKEN;

if (!TOKEN) {
  throw new Error("Missing ENV: TIBBER_TOKEN (set it in your shell/CI secret store)");
}

// Simple sleep helper
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function tibberQuery(query, variables = {}, opts = {}) {
  const {
    timeoutMs = 10_000,
    maxRetries = 4,
    baseDelayMs = 400,
  } = opts;

  // Exponential backoff with jitter
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const controller = new AbortController();
    const t = setTimeout(() => controller.abort(), timeoutMs);

    try {
      const res = await fetch(TIBBER_GQL_URL, {
        method: "POST",
        signal: controller.signal,
        headers: {
          "Authorization": `Bearer ${TOKEN}`,
          "Content-Type": "application/json",
          "Accept": "application/json",
        },
        body: JSON.stringify({ query, variables }),
      });

      // HTTP-level handling
      if (res.status === 401) {
        throw new Error("401 Unauthorized: token missing/invalid, or wrong Authorization header");
      }
      if (res.status === 403) {
        throw new Error("403 Forbidden: authenticated but not allowed (account context/permissions/API mismatch)");
      }
      if (res.status === 429 || res.status >= 500) {
        // Retry-worthy: rate limit or transient server errors
        const retryAfter = res.headers.get("retry-after");
        const hint = retryAfter ? ` (Retry-After: ${retryAfter})` : "";
        throw new Error(`${res.status}: transient error${hint}`);
      }
      if (!res.ok) {
        throw new Error(`Unexpected HTTP ${res.status}`);
      }

      const data = await res.json();

      // GraphQL-level handling
      if (data.errors && data.errors.length) {
        // Avoid logging full objects; keep it minimal
        const msg = data.errors[0]?.message || "GraphQL error";
        throw new Error(`GraphQL: ${msg}`);
      }

      return data.data;
    } catch (err) {
      const isLast = attempt === maxRetries;

      // AbortError => timeout
      const msg = (err && err.name === "AbortError")
        ? `Timeout after ${timeoutMs}ms`
        : (err?.message || String(err));

      if (isLast) {
        throw new Error(`Tibber request failed after ${maxRetries + 1} attempts: ${msg}`);
      }

      // Backoff: base * 2^attempt + jitter(0..200)
      const jitter = Math.floor(Math.random() * 200);
      const delay = baseDelayMs * (2 ** attempt) + jitter;
      await sleep(delay);
    } finally {
      clearTimeout(t);
    }
  }
}

// Example query
(async () => {
  const query = `{ viewer { name homes { id appNickname } } }`;
  const data = await tibberQuery(query);
  console.log("OK (minimal output):", { name: data?.viewer?.name, homes: data?.viewer?.homes?.length });
})();

"""
Python 3.x
ENV (bash): export TIBBER_TOKEN="..."
pip install requests
"""
import os
import time
import random
import requests

TIBBER_GQL_URL = "https://api.tibber.com/v1-beta/gql"
TOKEN = os.getenv("TIBBER_TOKEN")

if not TOKEN:
    raise RuntimeError("Missing ENV: TIBBER_TOKEN (set it in your shell/CI secret store)")

HEADERS = {
    "Authorization": f"Bearer {TOKEN}",
    "Content-Type": "application/json",
    "Accept": "application/json",
}

def tibber_query(query: str, variables: dict | None = None,
                timeout_s: float = 10.0, max_retries: int = 4, base_delay_s: float = 0.4):
    variables = variables or {}

    for attempt in range(max_retries + 1):
        try:
            r = requests.post(
                TIBBER_GQL_URL,
                headers=HEADERS,
                json={"query": query, "variables": variables},
                timeout=timeout_s,
            )

            # HTTP-level checks
            if r.status_code == 401:
                raise RuntimeError("401 Unauthorized: token missing/invalid, or wrong Authorization header")
            if r.status_code == 403:
                raise RuntimeError("403 Forbidden: authenticated but not allowed (account context/permissions/API mismatch)")

            if r.status_code in (429,) or r.status_code >= 500:
                retry_after = r.headers.get("Retry-After")
                hint = f" (Retry-After: {retry_after})" if retry_after else ""
                raise RuntimeError(f"{r.status_code}: transient error{hint}")

            r.raise_for_status()

            payload = r.json()

            # GraphQL-level errors (avoid logging full payloads with sensitive content)
            if payload.get("errors"):
                msg = payload["errors"][0].get("message", "GraphQL error")
                raise RuntimeError(f"GraphQL: {msg}")

            return payload.get("data")

        except Exception as e:
            if attempt == max_retries:
                raise RuntimeError(f"Tibber request failed after {max_retries + 1} attempts: {e}") from e

            # Exponential backoff with jitter
            jitter = random.random() * 0.2
            delay = base_delay_s * (2 ** attempt) + jitter
            time.sleep(delay)

# Example query
if __name__ == "__main__":
    q = "{ viewer { name homes { id appNickname } } }"
    data = tibber_query(q)
    print("OK (minimal output):", {"name": data.get("viewer", {}).get("name"), "homes": len(data.get("viewer", {}).get("homes", []))})

Troubleshooting (401 / 403 / 429 & realistische Fehlerbilder)

Hier sind Fehlerbilder, die in echten Setups (NAS, Raspberry Pi, Home-Server, CI/CD, Docker) ständig auftreten – inklusive konkreter Checks. Wenn Du systematisch vorgehst, findest Du die Ursache meist in wenigen Minuten.

Typische Stolperfallen (aus der Praxis) – Quick Checks

Incident-Szenario: Token versehentlich ins Repo committed

Sicherheits-Checkliste (Do / Don’t)

FAQ (zusätzliche Praxisfragen)