---
title: "Kunden-Token"
description: "Eine OpenTofu- oder Terraform-Konfiguration je Kunde, jede mit eigenem kundengebundenem API-Token und Provider-Alias."
---

API-Tokens gibt es in zwei Bereichen. Ein **Organisations-Token** verwaltet die ganze Organisation. Ein **Kunden-Token** erreicht nur die Kunden, an die es gebunden ist: genau richtig, wenn du Monitoring für mehrere Kunden betreibst. Details: [Token-Bereiche](/de/api/introduction/token-scopes-organization-vs-customer).

## Eine Konfiguration je Kunde

Gib jedem Kunden einen eigenen Provider-Alias und ein eigenes Kunden-Token. Ein Fehler im Code des einen Kunden erreicht die Monitore des anderen nicht.

```terraform
variable "acme_token" {
  type      = string
  sensitive = true
}

provider "uptimeify" {
  alias     = "acme"
  api_token = var.acme_token
}

data "uptimeify_customer" "acme" {
  provider = uptimeify.acme
  name     = "ACME GmbH"
}

resource "uptimeify_website" "acme_shop" {
  provider    = uptimeify.acme
  customer_id = tonumber(data.uptimeify_customer.acme.id)
  name        = "ACME-Shop"
  url         = "https://shop.acme.example/"
}
```

Mit Terragrunt den `provider`-Block generieren und das Token je Unit übergeben, wie bei jedem anderen Provider.

## Was ein Kunden-Token kann

Ein Kunden-Token verwaltet die Monitore seiner Kunden; Monitore, die es anlegt, sind immer `self_service`. Kunden anlegen kann es nicht. Auf einer organisationsweiten Ressource antwortet die API mit `403 customerScopedTokenForbidden`; fehlt einem Token ein Scope, kommt `403 apiTokenScopeForbidden` mit dem fehlenden Scope in `data.requiredScope`. Welcher Endpunkt welchen Scope braucht: [Berechtigungen je Endpunkt](/de/api/introduction/permissions-by-endpoint).

Ressourcen, die beides können, etwa [`uptimeify_tag`](/de/terraform/resources/tag), brauchen mit einem Kunden-Token ein `customer_id`.