Sandbox

Ein Testschlüssel läuft in der Sandbox. Ihre Anfragen durchlaufen dasselbe Gateway wie mit einem Live-Schlüssel: Schlüssel, Bereiche, Limits, Idempotency-Key, Anfrageprüfung, Aufträge, Dateien und Webhooks funktionieren wie im Betrieb. Nur die Arbeit selbst wird simuliert: Kein Werkzeug läuft, nichts wird erstellt und nichts berechnet.

Einen Testschlüssel erhalten

Öffnen Sie im Kabinett API → Schlüssel, wählen Sie den Schlüsseltyp Test und erstellen Sie den Schlüssel. Ein Testschlüssel beginnt mit gsk_test. Verwenden Sie ihn genau wie einen Live-Schlüssel.

Jede Sandbox-Antwort trägt den Header Grem-Sandbox: true, damit ein Testprotokoll nie mit echter Arbeit verwechselt wird - auch Antworten vor der Schlüsselprüfung (fehlerhaftes JSON, 413, unbekannter Pfad).

Was passiert

• Die Anfrageprüfung ist echt. Eine Anfrage, die der Betrieb ablehnen würde, lehnt die Sandbox mit demselben Status und Grund ab: ein fehlendes Feld, weniger als 4 Fotos im Content-Paket, Texte ohne Objekt, Beschreibung, Stadt und Fläche. Geprüft werden auch Formularfelder von multipart-Anfragen, Berichtsfelder einer anderen Kategorie und die heatingType-Werte eines Hauses, ebenso hochgeladene Dateien: Typ und Größe. Was der Betrieb kürzt oder ersetzt (ein langer Text, eine unbekannte Video-length), nimmt auch die Sandbox an.
• Ergebnisse sind Beispiele. Synchrone Werkzeuge antworten sofort mit festen Beispielwerten. Asynchrone liefern eine jobId; der Auftrag geht in etwa 5 Sekunden pending → running → Ergebnis.
• Die Berichtsprüfung hält wie im Betrieb in action_required mit Beispieldaten in extracted; bestätigen Sie sie mit POST /valuation/review/jobs/{id}/confirm.
• Dateien sind Platzhalter. PDFs und Bilder sind echte Dateien, die sich öffnen lassen; Video, docx und Texte sind kurze, gekennzeichnete Platzhalter mit dem richtigen Inhaltstyp. Eine Datei gibt es nur für einen abgeschlossenen Sandbox-Auftrag, unter dem Pfad seines Werkzeugs und mit einer Artefakt-ID, die der Auftrag geliefert hat - sonst 404. Ein Avatar-Video wird wie im Betrieb für jede Artefakt-ID eines abgeschlossenen Auftrags geliefert. Range funktioniert (206, 416).
• Webhooks sind echt. Ein Testschlüssel legt nur Sandbox-Webhook-Adressen an und verwaltet nur diese. Sie erhalten nur Ereignisse von Sandbox-Aufträgen - signierte Zustellungen mit Wiederholungen, genau wie im Betrieb. Live-Adressen erhalten nie Sandbox-Ereignisse, und ein Testschlüssel kann sie weder sehen noch ändern.

Das Ergebnis wählen

Der Header Grem-Simulate bestimmt, womit der Aufruf oder Auftrag endet:

Groß-/Kleinschreibung des Werts ist egal. Ein unbekannter Wert ergibt 400, damit ein Tippfehler nie als Erfolg durchgeht. Live-Schlüssel ignorieren den Header.

curl -X POST https://developers.grem.capital/api/v1/text/generate \
  -H "Authorization: Bearer gsk_test_xxx" \
  -H "Content-Type: application/json" \
  -H "Grem-Simulate: failed" \
  -d '{"city":"Berlin","totalArea":64}'

Was ein Testschlüssel darf

Unterschiede zum Betrieb

• Ergebnisse sind feste Beispiele, keine Bewertung und keine echten Texte. Zeigen Sie sie nicht Ihren Nutzern.
• Die Sandbox prüft nicht, ob das Objekt in objectId existiert und Ihnen gehört; der Betrieb antwortet in diesem Fall mit 403 oder 404.
• Aufträge und Ergebnisse werden einen Tag aufbewahrt.

Verwandte Artikel

• Schnellstart
• Aufträge und Ergebnisse
• Webhooks