Uptimeify

Fehlerliste und bekannte API-Fallen

Bekannte API-Fehlerbilder, Ursachen und aktuelle Loesungen in Uptimeify.

Fehlerliste und bekannte API-Fallen

Diese Seite dokumentiert reale Fehlerbilder, die bei Integrationen aufgetreten sind.

Schema

Error CodeGrundLoesung / Bug
404 Website not foundEinige Website-Unterendpunkte haben frueher nur die alte numerische Website-ID akzeptiert, obwohl die Docs websitePublicId gezeigt haben.Behoben. GET /api/websites/:websitePublicId/check-history und GET /api/websites/:websitePublicId/uptime-stats akzeptieren jetzt Public IDs und weiterhin Legacy-IDs.
403 Forbidden auf GET /api/organizations/:organizationPublicIdDie Route hat die Pfad-ID frueher direkt als Zahl interpretiert. Eine UUID wurde dadurch schon in der Berechtigungspruefung verworfen.Behoben. Die Organisations-Detail- und Billing-Routen loesen jetzt publicId korrekt auf.
400 Bad Request mit ZodError bei customer-ips oder customer-domainsQuery-Parameter wie organizationId=, page= oder perPage= wurden als leere Strings gesendet. Zod coerct leere Strings zu 0, was dann an den Mindestwerten scheitert.Behoben fuer organizationId, page und perPage. Optional bedeutet trotzdem: ungenutzte Parameter komplett weglassen statt leere Strings zu senden.

Betroffene Faelle

Website not found bei Website-Monitoring-Endpunkten

Betroffene Endpunkte:

  • GET /api/websites/:websitePublicId/check-history
  • GET /api/websites/:websitePublicId/uptime-stats

Frueherer Effekt:

{
  "error": true,
  "statusCode": 404,
  "statusMessage": "Website not found",
  "message": "Website not found"
}

Grund:

  • Die Route hat nur die alte numerische id direkt geparsed.
  • Eine UUID wurde nicht in die interne numerische ID aufgeloest.

Aktueller Stand:

  • Public IDs funktionieren jetzt wie in der Doku beschrieben.
  • Legacy-Integer-IDs bleiben aus Kompatibilitaetsgruenden gueltig.

Forbidden bei Organisations-Details mit Public ID

Betroffener Endpoint:

  • GET /api/organizations/:organizationPublicId

Grund:

  • Die Berechtigungspruefung lief frueher gegen Number(id).
  • Bei einer UUID wurde daraus NaN, was zu 403 Forbidden fuehrte.

Aktueller Stand:

  • Die Route und die Billing-Routen loesen organizationPublicId jetzt korrekt in die interne ID auf.

ZodError bei optionalen Listen-Parametern

Betroffene Endpunkte:

  • GET /api/customer-ips
  • GET /api/customer-domains

Typisches Muster:

{
  "error": true,
  "statusCode": 400,
  "statusMessage": "Bad Request"
}

Grund:

  • Nicht das Weglassen der Parameter war das Problem.
  • Das Problem waren leere Query-Werte wie ?page=&perPage=.

Loesung:

  • Unbenutzte optionale Parameter weglassen.
  • Die API ignoriert fuer diese Felder jetzt leere Strings robuster.

Public IDs in DNS- und DNSBL-Monitoren

Die folgenden Pfad-Endpunkte können in den Docs und in Clients mit Public IDs verwendet werden:

  • GET /api/customer-domains/:customerDomainPublicId
  • PATCH /api/customer-domains/:customerDomainPublicId
  • DELETE /api/customer-domains/:customerDomainPublicId
  • GET /api/customer-ips/:customerIpPublicId
  • PATCH /api/customer-ips/:customerIpPublicId
  • DELETE /api/customer-ips/:customerIpPublicId

Legacy-Integer-IDs bleiben auch dort weiterhin kompatibel, die Public ID ist aber die bevorzugte Form fuer Integrationen und Postman-Collections.

Update Billing Details: benoetigter Body

Endpoint:

  • PATCH /api/organizations/:organizationPublicId/billing

Aktuell unterstuetzter Request-Body:

{
  "billingEmail": "billing@example.com"
}

Der Endpoint akzeptiert derzeit nur billingEmail.