Developer
Test ModeTest Mode Sign In Get started
DeveloperDeveloper / FehlerbehandlungError Handling

FehlerbehandlungError Handling

Die BEEP! API verwendet konventionelle HTTP-Statuscodes und gibt strukturierte JSON-Fehlerobjekte zurück.

The BEEP! API uses conventional HTTP status codes and returns structured JSON error objects.

Fehler-ObjektError Object

Bei einem Fehler enthält die Antwort immer:

On error the response always contains:

Error Response: 4xx / 5xx
{ "success": false, "error": "INVALID_API_KEY", "message": "The provided API key is invalid or has been revoked.", "statusCode": 401 }

HTTP-StatuscodesHTTP Status Codes

CodeBedeutungMeaningWannWhen
200OKAnfrage erfolgreichRequest successful
400Bad RequestFehlende/ungültige ParameterMissing/invalid parameters
401UnauthorizedKein oder ungültiger API-KeyNo or invalid API key
403ForbiddenKey hat keine Berechtigung für diesen Endpoint (Paket-Beschränkung)Key has no permission for this endpoint (package restriction)
404Not FoundRessource (Store, Produkt …) nicht gefundenResource (store, product …) not found
405Method Not AllowedNur POST wird unterstütztOnly POST is supported
429Too Many RequestsRate Limit überschrittenRate limit exceededRate Limits
500Internal Server ErrorServerfehler, bitte erneut versuchenServer error, please try again

FehlercodesError Codes

Das error-Feld enthält einen maschinenlesbaren Code:

The error field contains a machine-readable code:

CodeHTTPBeschreibungDescription
MISSING_AUTH_HEADER401Authorization-Header fehltAuthorization header missing
INVALID_API_KEY401Key ungültig oder widerrufenKey invalid or revoked
SUBSCRIPTION_INACTIVE403Kein aktives Abo (Live-Modus erfordert aktive Subscription)No active subscription (live mode requires active subscription)
ENDPOINT_NOT_ALLOWED403Dein Paket hat keinen Zugriff auf diesen EndpointYour package has no access to this endpoint
RATE_LIMIT_EXCEEDED429Zu viele Anfragen, warte bisToo many requests, wait until Retry-After
INVALID_ACTION400Unbekannter Endpoint / ActionUnknown endpoint / action
MISSING_FIELDS400Pflichtfelder fehlen im Request-BodyRequired fields missing in request body
STORE_NOT_FOUND404Store-ID existiert nichtStore ID does not exist
PRODUCT_NOT_FOUND404Produkt nicht gefunden (Barcode oder ID)Product not found (barcode or ID)
INTERNAL_ERROR500Unerwarteter ServerfehlerUnexpected server error

Best Practices

  • Prüfe immer success im Response-Body statt nur den HTTP-Code.Always check success in the response body, not just the HTTP code.
  • Retry bei 429 & 500: Implementiere exponentielles Backoff. Bei 429 enthält der Header Retry-After die Wartezeit in Sekunden.Retry on 429 & 500: Implement exponential backoff. On 429 the Retry-After header contains the wait time in seconds.
  • Logge den error-Code: Für Debugging immer den maschinenlesbaren Code speichern.Log the error code: Always save the machine-readable code for debugging.
  • Zeige dem User die message: Das message-Feld ist für menschliche Leser gedacht.Show the user the message: The message field is intended for human readers.
  • Unterscheide Client- vs. Server-Fehler: 4xx = dein Code hat ein Problem. 5xx = unser Problem, automatisch retrien.Distinguish client vs. server errors: 4xx = your code has a problem. 5xx = our problem, retry automatically.
💡
In der Sandbox geben alle Endpoints immer 200 zurück (auch bei ungültigen Parametern), damit du schnell iterieren kannst. Das Feld _sandbox: true markiert Sandbox-Antworten.
In the Sandbox all endpoints always return 200 (even with invalid parameters) so you can iterate quickly. The field _sandbox: true marks sandbox responses.