Sandbox

Eine Sandbox ist eine vollständige Kopie der API-Oberfläche mit erfundenen Daten — dieselben Adressen, dieselben Felder, dieselben Fehler. Sie liegt vollständig bei artim/dev: eine Anfrage mit Sandbox-Key erreicht das Produkt nie.

Wie es funktioniert

Du wechselst also die Umgebung, indem du den Schlüssel wechselst — nicht die URL. Derselbe Code, dasselbe Deployment, ein anderes Token.

# gegen die Sandbox
curl "https://members.api.methacore.de/v1/members?limit=2" \
  -H "Authorization: Bearer ai_sbx_…"

# gegen echte Daten — nur der Schlüssel ist anders
curl "https://members.api.methacore.de/v1/members?limit=2" \
  -H "Authorization: Bearer mcapi_…"

Sandbox anlegen

1. In der Konsole unter Sandboxes eine neue Sandbox anlegen. Jede Sandbox gehört zu genau einer API — eine Mitglieder-Sandbox antwortet nicht auf der Buchhaltungs-Subdomain.
2. Im selben Schritt bekommst du einen Sandbox-Key. Er erscheint genau einmal; gespeichert ist nur sein Hash.
3. Die Scopes des Keys entscheiden, was er darf — genau wie bei echten Tokens. Fehlt ein Scope, antwortet die Sandbox mit 403 missing_scope.

Die Daten

Sie entstehen aus dem Seed der Sandbox: dieselbe Sandbox liefert immer dieselben Datensätze. Ein Test, der gestern lief, läuft heute genauso — ohne dass jemand einen Datenbestand pflegt. Ein Reset in der Konsole würfelt den Seed neu, wenn du frische Daten willst.

Der Umfang ist bewusst realistisch: 120 Mitglieder, 240 Buchungen, 96 Lastschriften, 12 Sitzungen, 24 Trainingspläne, 9 Wettkämpfe, 5 Abzeichen. Genug, um Blättern, Suchen und Ranglisten ernsthaft zu testen.

Was in der Sandbox anders ist

• Enterprise-Scopes stehen jedem offen. Mandate, DATEV und Archiv kannst du hier ohne Enterprise-Mitgliedschaft ausprobieren — die Daten sind erfunden. Für echte Daten braucht es die Mitgliedschaft.
• Kein Rate Limit. Sandbox-Aufrufe zählen nicht auf dein Minutenkontingent, erscheinen aber im Live-Protokoll unter Nutzung.
• Jede Antwort trägt X-Artim-Sandbox mit der Kennung der Sandbox — daran erkennst du im Zweifel, dass du nicht auf echten Daten arbeitest.

Grenzen

Schreiben in der Sandbox

Alles, was die echte API schreiben kann, schreibt auch die Sandbox — auf derselben Adresse, mit demselben Körper, denselben Fehlern:

curl -X POST "https://members.api.methacore.de/v1/departments" \
  -H "Authorization: Bearer ai_sbx_…" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Bahn-9", "location": "Hallenbad" }'

Die Antwort ist eine 201 mit dem angelegten Eintrag, und die nächste Liste enthält ihn — vorne, weil er der jüngste ist. Ein PATCH bleibt sichtbar, ein DELETE nimmt den Eintrag aus den Listen und lässt den Abruf danach 404 antworten. Auch die Regeln gelten: eine zugeordnete Buchung lässt sich nicht löschen, ein freigegebenes Protokoll nicht zweimal freigeben, ein voller Termin schickt die nächste Anmeldung auf die Warteliste.

Das Geschriebene liegt als Auflage über den erzeugten Daten — je Sandbox getrennt, je Team getrennt. Zurücksetzen wirft diese Auflage weg: danach ist der Datensatz wieder genau der vom ersten Tag. Ein Testlauf, der Daten anlegt, braucht deshalb kein Aufräumen — ein Klick genügt.