> ## Documentation Index
> Fetch the complete documentation index at: https://docs.so-me.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Sicherheit und Fehler

> Partner-Zugangsdaten schützen, Kunden isolieren und SDK-Fehler behandeln

## Partner-Schlüssel schützen

Partner-Schlüssel autorisieren projektweite Operationen. Speichere sie in einem serverseitigen Secret-Manager oder einer verschlüsselten Umgebungsvariable und stelle sie nur vertrauenswürdigen Backend-Prozessen bereit.

> [!WARNING]
>
> Sende einen Partner-Schlüssel niemals als Konfiguration, API-Antwort, Query-Parameter oder gerenderte Umgebungsvariable an dein Frontend. Dein Backend sollte schmale Endpunkte bereitstellen, die den angemeldeten Kunden autorisieren, bevor Social media studio aufgerufen wird.

Verwende `pk_test_`-Schlüssel während der Entwicklung und `pk_live_`-Schlüssel ausschließlich in der Produktion. Halte Test- und Live-Projekte getrennt, rotiere Schlüssel regelmäßig und widerrufe einen Schlüssel sofort, wenn er möglicherweise offengelegt wurde.

## Jede Kundenoperation autorisieren

Das SDK authentifiziert deine Anwendung, nicht den Kunden, der dein Produkt nutzt. Vor jedem SDK-Aufruf:

1. Authentifiziere den Kunden in deiner Anwendung.
2. Ermittle die gespeicherte Social-media-studio-`endUserId` des Kunden auf deinem Server.
3. Prüfe, dass die angeforderten Verbindungs- und Beitrags-IDs diesem Kunden gehören.
4. Rufe das SDK mit diesen serverseitig ermittelten IDs auf.

Nimm niemals eine beliebige `endUserId` aus einem Browser entgegen und gib sie weiter, ohne die Zugehörigkeit in deiner Datenbank zu prüfen.

## Schlüssel-Scopes

Partner-Schlüssel lassen sich auf die Fähigkeiten beschränken, die ein Dienst benötigt:

| Ressource | Lese-Scope | Schreib-Scope |
| - | - | - |
| Endnutzer | `end_users:read` | `end_users:write` |
| Verbindungen | `connections:read` | `connections:write` |
| Connect-Sessions | `connect_sessions:read` | `connect_sessions:write` |
| Beiträge | `posts:read` | `posts:write` |
| Medien | — | `media:write` |
| Webhooks | `webhooks:read` | `webhooks:write` |

Verwende nach Möglichkeit getrennte Schlüssel mit minimalen Rechten für unabhängige Dienste.

## SDK-Fehler behandeln

Jede nicht erfolgreiche API-Anfrage löst einen `SoMePlatformError` aus:

```ts theme={null}
import {
  SoMePlatformError,
  SoMePlatformClient,
} from "@social-media-scheduler/sdk";

try {
  await soMe.posts.get(endUserId, postId);
} catch (error) {
  if (error instanceof SoMePlatformError) {
    logger.error("Social media studio request failed", {
      status: error.status,
      details: error.details,
    });
  }
  throw error;
}
```

| Status | Bedeutung | Empfohlene Behandlung |
| - | - | - |
| `0` | Netzwerkfehler, DNS-Fehler oder Request-Timeout | Wenn sicher, mit Backoff wiederholen |
| `400` | Ungültige Eingabe, Plattform-Abweichung oder nicht erlaubte Return-URL | Anfrage korrigieren; nicht unverändert wiederholen |
| `401` | Partner-Schlüssel fehlt, ist ungültig, abgelaufen oder widerrufen | Anhalten und den Schlüssel rotieren oder ersetzen |
| `403` | Dem Schlüssel fehlt ein erforderlicher Scope | Einen Schlüssel mit passenden Scopes verwenden |
| `404` | Die Ressource existiert in diesem Projekt bzw. für diesen Endnutzer nicht | Gespeicherte IDs abgleichen |
| `409` | Der Workspace des Kunden ist nicht bereit | Nach Behebung des gemeldeten Zustands erneut versuchen |
| `429` | Rate Limit erreicht | Retry-Hinweise beachten und exponentielles Backoff verwenden |
| `5xx` | Vorübergehender Ausfall des Social-media-studio-Dienstes | Mit begrenztem exponentiellem Backoff wiederholen |

Beim Erstellen von Beiträgen sind Wiederholungen nur sicher, wenn du denselben Idempotenzschlüssel wiederverwendest. Wiederhole andere Schreiboperationen nicht blind, es sei denn, deine Anwendung kann ihr Ergebnis bestätigen.

## Logging

Protokolliere Anfragekontext wie deine Kunden-ID, die Endnutzer-ID, die Operation, den HTTP-Status und den Idempotenzschlüssel. Protokolliere keine vollständigen Partner-Schlüssel, Webhook-Secrets, OAuth-Tokens, vorsignierten Upload-URLs oder sensiblen Kundenmetadaten.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.