Data model
Feedback items
Incoming feedback on a grant - from uni TTO, programme officer, mentor, or a self-note. The body field carries the raw text; extracted markup points live in feedback_point.
feedback_item500Fields
Per-field validation rules. Values that violate any constraint are rejected with 400 before they reach the database.
| Field | Type | Constraints |
|---|---|---|
| who | string | max length 200 |
| body | string | max length 50000 |
| status | enum | enum open | extracting | applied | ignored |
| unread | bool | - |
| urgent | bool | - |
| subject | string | max length 300 |
| due_date | string | max length 32 |
| grant_id | string | max length 64ref →grant |
| source_type | enum | enum uni | ptj | mentor | self | external |
| file_blob_id | string | max length 64 |
Mutability
Which fields can you send, and when? Anything without a marker is server-managed - sending it isn't an error, it's silently ignored.
| Field | Create | Patch |
|---|---|---|
| who | ||
| body | ||
| status | ||
| unread | ||
| urgent | ||
| subject | ||
| due_date | ||
| grant_id | ||
| source_type | ||
| file_blob_id |
Fields marked create-only but not patchable are immutable after creation. Server-managed fields include id, timestamps, ownership, and status.
Filtering & sorting
Combinable on list endpoints. Repeating a filter key produces an IN clause; prefixing a sort key with - reverses direction. Example: ?status=open&status=blocked&sort=-created_at.
Filter keys
data__grant_iddata__source_typedata__statusdata__urgentdata__unreadstatusis_archivedowned_bySort keys
created_atupdated_atdata__statusDefault: created_at
Endpoints
Each endpoint below lists its HTTP method, path, and the PAT scope it needs. Code samples cover curl, JavaScript, TypeScript, Python, Rust, Java, and WebSocket.
/xapi2/data/feedback_itemfeedback_item:listList objects
Returns a paginated list of objects you can read. Default page size is 20; pass ?limit= to change (capped per type). Use ?after=<id> for keyset pagination on created_at-sorted lists, or ?offset= for offset paging.
curl -H "Authorization: Bearer pat_…" \"https://granttool.de/xapi2/data/feedback_item?limit=20"
/xapi2/data/feedback_item/{id}feedback_item:readRead one
Returns the object by id. 404 if it does not exist or you cannot read it (the two cases are intentionally conflated).
curl -H "Authorization: Bearer pat_…" \https://granttool.de/xapi2/data/feedback_item/OBJECT_ID
/xapi2/data/feedback_itemfeedback_item:createCreate
Creates a new object. Body is a flat JSON dict of field values. Server-side fields (id, timestamps, ownership) are filled automatically; only fields listed below as creatable are read from the body.
curl -H "Authorization: Bearer pat_…" \-H "Content-Type: application/json" \-X POST https://granttool.de/xapi2/data/feedback_item \-d '{"name": "…"}'
/xapi2/data/feedback_item/{id}feedback_item:updateUpdate
Partial update. Only fields included in the body are touched; everything else is preserved. Same allow-list as create, minus the fields that are immutable post-create.
curl -H "Authorization: Bearer pat_…" \-H "Content-Type: application/json" \-X PATCH https://granttool.de/xapi2/data/feedback_item/OBJECT_ID \-d '{"name": "…"}'
/xapi2/data/feedback_item/{id}feedback_item:deleteDelete
Removes the object. It vanishes from every default list immediately and stops being returned by read / list.
curl -H "Authorization: Bearer pat_…" \-X DELETE https://granttool.de/xapi2/data/feedback_item/OBJECT_ID
Use in CLI
The same endpoints are also exposed via the Grants CLI. For scripts, CI, and bulk imports it's usually the faster path.
grantscli feedback_item list --limit 5grantscli feedback_item get <id>grantscli feedback_item create --grant-id "Hello"grantscli feedback_item upsert --unique grant_id --csv items.csvgrantscli feedback_item schema # fields & limits
Full command reference, profiles, CSV import, auto-retry, NDJSON streaming → /docs/cli