---
title: "TCP Monitor erstellen"
description: "Erstellt einen neuen TCP Monitor."
---

`POST /api/tcp-monitors`

## Authentifizierung

Erfordert eine gültige Session.

- Header: `Authorization: Bearer <token>`

## Request Body

```json
{
  "customerId": "11111111-1111-4111-8111-111111111111",
  "name": "Redis Primary",
  "hostname": "redis.deinkunde.com",
  "port": 6379,
  "status": "active",
  "checkInterval": 60,
  "timeoutSeconds": 30,
  "config": {
    "expectBanner": "+PONG"
  }
}
```

### Felder

- `customerId` (number | string, required)
  - Akzeptiert entweder die interne numerische Kunden-ID oder die öffentliche Kunden-UUID.
- `name` (string, required, max. 255 Zeichen)
- `hostname` (string, required, max. 253 Zeichen)
  - Muss ein reiner Hostname sein (kein Protokoll wie `https://`, kein Pfad wie `/status`).
- `port` (number, **required**, 1-65535)
  - Anders als bei anderen Monitor-Typen gibt es bei TCP-Monitoren keinen Standardport: der Port muss immer angegeben werden.
- `status` (string, optional)
  - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` (`paused`/`inactive` werden zu `disabled` normalisiert). Standard: `active`.
- `checkInterval` (number, optional, 1-1440 Minuten)
  - Standard: `30`.
- `timeoutSeconds` (number, optional, 1-60)
  - Standard: `30`.
- `allowedCheckCountryCodes` (string[], optional)
  - Beschränkt Checks auf diese ISO-3166-1-alpha-2-Ländercodes.
- `managementType` (string, optional)
  - Erlaubt: `managed`, `self_service`. Nur Organisations-Writer dürfen dies setzen; alle anderen Aufrufer erhalten immer `managed`.
- `config` (object, optional)
  - Wird als `config` JSON des Monitors gespeichert. TCP-Monitore enthalten **keine Zugangsdaten**: der einzige unterstützte Key ist `expectBanner`.

### `config` (vom Worker unterstützte Keys)

- `expectBanner` (string, optional, max. 255 Zeichen)
  - Wenn gesetzt, prüft der Worker, ob die Rohbytes direkt nach dem TCP-Handshake diesen Teilstring enthalten (z. B. `+PONG` bei Redis, `220` bei einem SMTP-Banner). Wenn weggelassen, prüft der Check nur, ob der TCP-Handshake erfolgreich ist.

## cURL

```bash
curl -X POST "https://YOUR_DOMAIN/api/tcp-monitors" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": "11111111-1111-4111-8111-111111111111",
    "name": "Redis Primary",
    "hostname": "redis.deinkunde.com",
    "port": 6379,
    "status": "active",
    "checkInterval": 60,
    "timeoutSeconds": 30,
    "config": { "expectBanner": "+PONG" }
  }'
```

## Response

```json
{
  "id": 300,
  "publicId": "44444444-4444-4444-8444-444444444444",
  "organizationId": 1,
  "customerId": 10,
  "name": "Redis Primary",
  "hostname": "redis.deinkunde.com",
  "port": 6379,
  "status": "active",
  "managementType": "managed",
  "checkInterval": 60,
  "timeoutSeconds": 30,
  "notificationEmail": null,
  "notificationPhoneNumber": null,
  "lastCheckedAt": null,
  "createdAt": "2026-02-26T12:00:00.000Z",
  "updatedAt": "2026-02-26T12:00:00.000Z",
  "config": {
    "expectBanner": "+PONG"
  }
}
```

## Errors

- `400` `invalidHostname`: Hostname muss ein gültiger Hostname sein (kein Protokoll, kein Pfad)
- `400` Ungültiger Request Body (z. B. fehlender/außerhalb des Bereichs liegender `port`, ungültige `config`-Keys)
- `400` Ungültiger Customer-Identifier
- `401` Unauthorized
- `403` Forbidden (z. B. `readonly` ohne Self-Service-Berechtigung, Self-Service-Quota erreicht, oder global supporter)
- `404` Customer nicht gefunden