SpedySpedy Docs

API-Uebersicht

Alles, was du fuer die Integration mit der Spedy-API brauchst -- Authentifizierung, Request-Format, Paginierung und Fehlerbehandlung.

Die Spedy-API ermoeglicht es dir, Boards, Tickets, Nutzer und alles andere in deiner Organisation programmatisch zu verwalten. Sie folgt REST-Konventionen und gibt JSON fuer alle Antworten zurueck.

Basis-URL

Alle API-Anfragen sind auf die Subdomain deiner Organisation beschraenkt:

https://{org-slug}.spedy.ai/api/v1

Ersetze {org-slug} mit dem Slug deiner Organisation (zum Beispiel acme-corp).

Authentifizierung

Alle API-Anfragen muessen mit einem Personal Access Token (PAT) authentifiziert werden. Erstelle ein PAT in deinen Kontoeinstellungen in der Spedy-Oberflaeche. PATs laufen nicht ab, es sei denn, du widerrufst sie -- ideal fuer Skripte, CI/CD-Pipelines und langlebige Integrationen.

Fuege dein Token im Authorization-Header jeder Anfrage ein:

Authorization: Bearer spedy_pat_abc123...

PATs erben die Berechtigungen des Nutzers, der sie erstellt hat. Siehe die Authentifizierungsseite fuer Details zum Erstellen und Verwalten von Tokens.

Request-Format

  • Sende Request-Bodies als JSON mit dem Content-Type: application/json-Header.
  • Datei-Uploads verwenden stattdessen multipart/form-data.
  • Query-Parameter verwenden Standard-URL-Encoding.

Verfuegbare API-Bereiche

Die API ist in dieselben Gruppen unterteilt, die du auch in der Seitenleiste findest.

Erste Schritte

BereichBeschreibung
AuthentifizierungPersonal Access Tokens erstellen und verwalten
OAuth 2.0OAuth 2.0 mit PKCE fuer externe Anwendungen und KI-Tools

Kern-Ressourcen

BereichBeschreibung
BoardsBoard-CRUD und Einstellungen
Board-MitgliederBoard-Mitgliedschaft verwalten
Board-StatusBoard-spezifische Status konfigurieren
TicketsTickets erstellen und verwalten
KommentareTicket-Kommentare
AnhaengeDatei-Anhaenge
UnterticketsEltern-Kind-Ticket-Beziehungen
Ticket-VerknuepfungenVerwandte Tickets verknuepfen
BeobachterTicket-Beobachter

Organisation

BereichBeschreibung
OrganisationOrganisationseinstellungen und Details
NutzerNutzer auflisten und Aktivitaeten einsehen
TeamsTeamverwaltung
LabelsLabel-Verwaltung
StatusGlobale Statusdefinitionen
Ticket-TypenTicket-Typ-Konfiguration

Funktionen

BereichBeschreibung
SucheRessourcenuebergreifende Suche
ZeiterfassungZeiteintraege auf Tickets
MeilensteineMeilenstein-Tracking
ReleasesRelease-Verwaltung
WikiWiki-Spaces, Seiten und Ordner
Webhook-EndpunkteEvents per Webhooks abonnieren

Paginierung

Listen-Endpunkte geben paginierte Ergebnisse zurueck. Verwende die Query-Parameter page und limit, um das Fenster zu steuern:

ParameterTypStandardBeschreibung
pagenumber1Seitennummer (beginnt bei 1)
limitnumber20Eintraege pro Seite (max. 100)

Paginierte Antworten haben diese Struktur:

{
  "data": [],
  "total": 142,
  "page": 1,
  "pageSize": 20,
  "totalPages": 8
}

Fehlerbehandlung

Bei Fehlern gibt die API ein einheitliches Fehlerobjekt zurueck:

{
  "statusCode": 400,
  "message": "Validation failed",
  "error": "Bad Request"
}

Haeufige Statuscodes:

CodeBedeutung
400Bad Request -- ungueltige Eingabe oder Constraint-Verletzung
401Unauthorized -- fehlendes oder ungueltiges Token
403Forbidden -- unzureichende Berechtigungen
404Not Found -- Ressource existiert nicht oder ist nicht zugaenglich
409Conflict -- doppelter Name oder ungueltiger Statusuebergang
429Too Many Requests -- Rate-Limit ueberschritten

Rate Limiting

Bestimmte Endpunkte haben Rate-Limits zum Schutz der Plattform. Wenn du ein Limit ueberschreitest, erhaeltst du eine 429-Antwort. Rate-Limits werden pro Token angewendet und variieren je nach Endpunkt.

Multi-Tenancy

Spedy ist eine Multi-Tenant-Plattform. Jede Ressource gehoert zu einer Organisation, und alle API-Antworten sind automatisch auf die Organisation des authentifizierten Nutzers beschraenkt. Du kannst nicht auf Ressourcen anderer Organisationen zugreifen.

Soft Deletes

Die meisten Ressourcen verwenden Soft-Deletion. Geloeschte Eintraege werden standardmaessig aus Listen-Responses ausgeschlossen, koennen aber mit dem Query-Parameter includeDeleted eingeschlossen werden, wo unterstuetzt. Soft-geloeschte Ressourcen behalten ihre IDs und koennen teilweise wiederhergestellt werden.

Berechtigungen

Die Zugriffskontrolle wird auf zwei Ebenen durchgesetzt:

  1. Organisationsrolle -- Admin, TeamMember oder Customer. Admins haben vollen Zugriff; Kunden haben eingeschraenkte Sichtbarkeit (z.B. keine geheimen Kommentare).
  2. Feature-Berechtigungen -- granulare Faehigkeiten wie tickets:edit, milestones:view oder time-tracking:manage. Diese werden pro Endpunkt geprueft und auf jeder Ressourcenseite dokumentiert.

Einige Features (Teams, Webhook-Endpunkte) erfordern ein Pro-Plan-Abonnement.

Feature Guards

Bestimmte Endpunkte sind hinter Board-Level-Feature-Flags geschuetzt. Zum Beispiel erfordern Meilensteine und Releases, dass das Feature Meilensteine & Releases auf dem Board aktiviert ist, und Zeiterfassung erfordert, dass das Feature Zeiterfassung fuer die Organisation aktiviert ist. Wenn ein Feature nicht aktiviert ist, geben Anfragen an diese Endpunkte 403 Forbidden zurueck.