Discussions

Hallo zusammen,wir testen aktuell das Erstellen von User Tasks über die facilioo API und stoßen dabei auf ein Problem, das wir nicht eindeutig aus der API-Dokumentation ableiten können.

Endpoint:
POST /api/user-tasks

Header:
api-version: 2.0
Content-Type: application/json
Authorization: Bearer

Beispiel-Payload:

{
  "description": "Testaufgabe über API",
  "primaryAssigneeId": 693839,
  "priorityId": 1,
  "isEmail": false,
  "isCompleted": false,
  "collectionId": 6863
}

Der POST-Request liefert HTTP 200 und eine Response mit einer neuen UserTask-ID zurück.

Direkt danach ist diese Aufgabe aber nicht lesbar:

GET /api/user-tasks/{id}

liefert HTTP 404.

Auch eine Suche über:

POST /api/user-tasks/search

mit:

{
"ids": [<zurückgegebene_id>]
}

liefert keine Treffer.

Read-Requests mit demselben Token funktionieren grundsätzlich. Wir können bestehende Aufgaben über /api/user-tasks und /api/user-tasks/search lesen. Auch PATCH auf eine bestehende sichtbare Aufgabe funktioniert und ist danach per GET und Search sichtbar.

Auffälligkeiten / Kontext:

• Der verwendete API-Account ist account id 746920, partyId 4892091.
• Bestehende UserTasks haben im Feld creatorId offenbar 4892091, also die partyId, nicht die account id 746920.
• primaryAssigneeId 693839 ist ein gültiger Account.
• priorityId 1 ist gültig.
• collectionId 6863 ist eine vorhandene Collection.
• Laut Swagger ist collectionId nullable/optional, praktisch scheint es aber für Create erforderlich zu sein.

Unsere Fragen:

1. Ist POST /api/user-tasks für API-Key/API-Benutzer-Accounts offiziell unterstützt?

2. Warum kann POST /api/user-tasks HTTP 200 mit einer UserTask-ID zurückgeben, wenn GET /api/user-tasks/{id} direkt danach 404 liefert?

3. Ist creatorId bei UserTaskRead eine Party-ID oder eine Account-ID?

4. Muss collectionId beim Erstellen zwingend gesetzt werden, obwohl sie im Swagger-Schema als nullable/optional erscheint?

5. Gibt es Einschränkungen, welche collectionId ein API-Benutzer verwenden darf?

6. Muss nach dem Erstellen zusätzlich ein Assignee über PUT /api/user-tasks/{userTaskId}/assignees/{accountId} gesetzt werden, damit die Aufgabe sichtbar wird?

7. Gibt es bei UserTask Create eine Verzögerung/Eventual Consistency, sodass die Aufgabe erst später per GET/Search sichtbar wird?

8. Ist api-version: 2.0 für diesen Endpoint korrekt, oder sollte UserTask Create mit api-version: 1.0 verwendet werden?

Unser erwartetes Verhalten wäre:
Wenn POST /api/user-tasks mit HTTP 200 und einer UserTaskRead-Response antwortet, sollte die zurückgegebene id anschließend per GET /api/user-tasks/{id} oder per /api/user-tasks/search auffindbar sein.

Danke vorab für eine Einordnung.