Authentifizierung

Die Nomid MDM API verwendet API-Schlüssel zur Authentifizierung von Anfragen. Dieser Leitfaden erklärt, wie Sie Ihren API-Schlüssel erhalten und verwenden.

Übersicht

API-Schlüssel werden zur Authentifizierung aller Anfragen an die Nomid MDM API verwendet. Fügen Sie Ihren API-Schlüssel in jeder Anfrage im X-API-Key-Header hinzu.

X-API-Key: nm_acme_a1b2c3d4e5f6...

So erhalten Sie Ihren API-Schlüssel

API-Schlüssel werden über das Nomid-Portal erstellt und verwaltet. Befolgen Sie diese Schritte, um Ihren ersten API-Schlüssel zu erstellen.

Voraussetzungen

Ein Nomid MDM-Konto mit Administratorzugriff
Zugriff auf die Firmeneinstellungen im Nomid Portal

1
Melden Sie sich im Nomid Portal an
Öffnen Sie Ihren Browser und navigieren Sie zum Nomid Portal. Melden Sie sich mit Ihren Administratorzugangsdaten an.
2
Navigieren Sie zu Integrationen
Sobald Sie angemeldet sind, gehen Sie zum Abschnitt "Firmeneinstellungen" und wählen Sie den Tab "Integrationen" aus.
3
Klicken Sie auf API-Schlüssel erstellen
Klicken Sie auf die Schaltfläche "API-Schlüssel erstellen", die sich in der oberen rechten Ecke der Integrationsseite befindet.
4
Name eingeben
Geben Sie im erscheinenden Modal ein beschreibendes Benennung für Ihren API-Schlüssel ein. Dies hilft Ihnen, den Schlüssel später zu identifizieren (z. B. "Power BI Integration" oder "CRM Sync").
5
Schlüssel kopieren
Nach dem Klicken auf "Erstellen" wird Ihr API-Schlüssel angezeigt. Klicken Sie auf die Schaltfläche "Kopieren", um ihn in Ihre Zwischenablage zu kopieren. Der Schlüssel wird nur einmal angezeigt!

API-Schlüssel-Format

API-Schlüssel folgen diesem Format:

nm_{company}_{random_32_chars}

Alle Schlüssel beginnen mit 'nm_
Unternehmensspezifisches Präfix zur Identifizierung
32 zufällige Zeichen für die Sicherheit

Verwendung Ihres API-Schlüssels

Fügen Sie den API-Schlüssel bei jeder Anfrage in den X-API-Key-Header ein:

curl -X GET "https://api.nomid.tech/emm/api/v1/assets" \
  -H "X-API-Key: nm_acme_a1b2c3d4e5f6..."

API-Schlüssel-Berechtigungen

Jeder Schlüssel verfügt über die Berechtigungen, die Sie beim Erstellen auswählen. Ein Endpunkt gibt 403 zurück, wenn dem Schlüssel die erforderliche Berechtigung fehlt. Der MCP-Server gibt stattdessen einen Tool-Fehler zurück.

Berechtigung	Beschreibung
DEVICES_READ	Geräte, die Flottenübersicht und den Befehlsverlauf auflisten und lesen. Erforderlich für die Endpunkte GET /assets, die BI-API und die MCP-Gerätelesewerkzeuge.
POLICIES_READ	Richtlinien auflisten und lesen. Erforderlich für GET /policies, GET /policies/POLICY_ID und die MCP-Richtlinienwerkzeuge.
DEVICES_COMMAND	Einen Befehl an ein einzelnes Gerät senden: Sperren, Verloren-Modus, Nachricht, Statusbericht, Standortaktualisierung, Richtliniensynchronisierung, Neustart, Herunterfahren, App starten, App-Daten löschen und Richtlinie ändern (wofür auch POLICIES_READ erforderlich ist). Opt-in und niemals durch eine andere Berechtigung impliziert. Es muss mit DEVICES_READ kombiniert werden. Erforderlich für die Standard-POST-Befehlsendpunkte und die MCP-Befehlswerkzeuge.
DEVICES_COMMAND_DESTRUCTIVE	Destruktive Befehle auf einem Gerät ausführen: Daten löschen, die Bildschirmsperre zurücksetzen oder ändern und die Eigentümerschaft aufgeben. Sie werden sofort ausgeführt, ohne Genehmigungsschritt im Portal. Opt-in, getrennt von DEVICES_COMMAND, und muss mit DEVICES_READ kombiniert werden. Das Unternehmen muss destruktive Befehle außerdem unter „KI-Agent-Zugriff“ im Portal aktivieren. Erforderlich für die vier Endpunkte für destruktive Befehle und die MCP-Tools für destruktive Befehle.
PROVISIONING	Bereitstellungs-QR-Codes für die Richtlinien des Unternehmens erstellen. Jeder QR-Code enthält ein neues Registrierungstoken, das nach 24 Stunden abläuft. Opt-in, und es muss mit POLICIES_READ kombiniert werden. Nur ein Portal-Benutzer, der Geräte bereitstellen darf und Zugriff auf alle Richtlinien hat, kann einen Schlüssel damit erstellen. Erforderlich für POST /policies/POLICY_ID/provisioning-qr-codes und das MCP-Tool create_provisioning_qr_code. Bereitstellungs-QR-Codes-API
EXPORT_READ	Veraltete Berechtigung. Kein Endpunkt oder Tool überprüft sie, und neue Schlüssel können damit nicht mehr erstellt werden.
POLICIES_WRITE	Ein API-Schlüssel mit der Berechtigung POLICIES_WRITE (Richtlinienänderungen), kombiniert mit POLICIES_READ. Nur ein Portal-Benutzer mit der Berechtigung zum Bearbeiten von Richtlinien kann einen Schlüssel mit POLICIES_WRITE erstellen. Erforderlich für die sechs POST-Endpunkte und die MCP-Richtlinienänderungstools. API für Richtlinienänderungen

Wohin der Schlüssel gesendet werden muss

Die REST-API akzeptiert den Schlüssel nur im X-API-Key-Header. Der MCP-Endpunkt akzeptiert entweder X-API-Key oder Authorization: Bearer gefolgt vom Schlüssel.

MCP-Server-Leitfaden

Ratenbegrenzungen und Header

Die REST-Lese-Endpunkte wenden in der Nomid-Anwendung kein Limit pro Schlüssel an, dennoch sollten Sie Ihren Client so aufbauen, dass er bei 429 pausiert (Backoff). Der MCP-Endpunkt erlaubt 60 Anfragen pro Minute und Schlüssel. Gerätebefehle, Richtlinienänderungen (jeder Propose- und Apply-Aufruf) und Provisionierungs-QR-Codes teilen sich ein Schreiblimit von 10 Anfragen pro Minute und Schlüssel, kombiniert über REST und MCP. Eine „Sign in with Nomid“-Verbindung hat dieselben MCP- und Schreiblimits, gezählt pro Verbindung.

Eine HTTP 429-Antwort enthält einen Retry-After-Header mit der Anzahl der zu wartenden Sekunden. Wenn ein MCP-Befehl, eine Richtlinienänderung oder ein Provisionierungs-Tool-Aufruf das Schreiblimit überschreitet, gibt stattdessen der Tool-Fehlertext die Sekunden an. Die API setzt keine X-RateLimit-Limit-, X-RateLimit-Remaining- oder X-RateLimit-Reset-Header.

Sicherheits-Best-Practices

Geben Sie API-Schlüssel niemals in clientseitigem Code oder öffentlichen Repositories preis
Drehen Sie Schlüssel regelmäßig und widerrufen Sie ungenutzte Schlüssel
Speichern Sie Schlüssel in Umgebungsvariablen, nicht im Code
Verwenden Sie die minimal erforderlichen Berechtigungen für Ihre Integration