Begin of the insertion**As a** mobile OpenProject userEnd of the insertion Begin of the deletion **As** a \[enter role of user\]End of the deletion
**I Begin of the insertionwant** the mobile Meetings module to use the same backend API capabilities as the desktop web appEnd of the insertion Begin of the deletion want to** \[enter objective\]End of the deletion
**so that** Begin of the insertionmeeting data is consistent across platforms and I can reliably view and manage meetings from my phone/tablet.End of the insertion Begin of the deletion \[enter desired result\]End of the deletion

Begin of the insertion### Acceptance CriteriaEnd of the insertion Begin of the deletion **Acceptance criteria**End of the deletion

* Begin of the insertionThe mobile app retrieves meetings data exclusively via supported OpenProject backend APIs (not by scraping or webview dependency).

End of the insertion Begin of the deletion <br>


**Technical notes**

End of the deletion * Begin of the insertionThe mobile Meetings module uses authenticated API calls equivalent to the desktop web app behavior:

* List meetings accessible to the user

* Fetch meeting details

* Create a meeting (when permitted)

* Update a meeting (when permitted)

* Delete a meeting (when permitted)

* All API requests require authenticated user contextEnd of the insertion Begin of the deletion <br>


**PermissionsEnd of the deletion and Begin of the insertionrespect the same permission rules as the web app.

End of the insertion Begin of the deletion visibility considerations**

End of the deletion * Begin of the insertionIf the user lacks permission for an operation, the API responseEnd of the insertion Begin of the deletion _To whomEnd of the deletion is Begin of the insertionhandled gracefully:

* The UI does not expose forbidden actions

* Attempts return a clear error state and messaging

* Meeting list retrieval supports:

* Filtering by project (at minimum)

* Filtering by time range (upcoming/past) when supported by backend

* Sorting by meeting date/time (or equivalent)

* Pagination (or an equivalent incremental loading mechanism)

* The mobile app can safely render meeting rich text content returned by the API without corrupting formatting.End of the insertion Begin of the deletion this feature visible?_End of the deletion

* Begin of the insertionThe mobile app can submit meeting content updates in a format accepted by the backend without data loss.

* The mobile app handles concurrency:

* If an update conflicts with a newer server version, the userEnd of the insertion Begin of the deletion _WhenEnd of the deletion is Begin of the insertionprompted to reload or resolve.

* API error handling is standardized:

* Network errors, timeouts, 4xx/5xx responses produce consistent UX and logs.

* API performance meets mobile constraints:

* First meeting list load completes within an acceptable time on typical mobile networks (define target SLA)

* Detail endpoints avoid returning unnecessary payload by default (or the client uses lightweight endpoints when available)

* The API connection layer is covered by automated tests (unit + integration) for:

* Authentication handling

* Request construction

* Response parsing

* Error mapping

* Pagination behavior


### Technical NotesEnd of the insertion Begin of the deletion it not visible?_


**Translation considerations**End of the deletion

* Begin of the insertion**Feature description (API Connection layer)**

* Implement a dedicated Meetings API client module in the mobile app responsible for:

* Authentication/session handling integration

* Calling backend endpoints for meetingsEnd of the insertion Begin of the deletion _Key termsEnd of the deletion and Begin of the insertionrelated resources

* Normalizing responses into mobile domain models

* Mapping API errors to user-facing states

* The API client must be reusable across iOS/Android code paths (shared layer if applicable) and isolated from UI components.

* **API contract discovery**

* Inventory the existing endpoints used by the desktop-browser Meetings module (OpenProject API v3 where applicable).

* Identify any gaps between web functionality and API availability:

* If web uses internal endpoints not exposedEnd of the insertion Begin of the deletion phrasesEnd of the deletion in Begin of the insertionAPI v3, define required API v3 extensions.

* Document final contracts with:

* Endpoint paths

* Methods (GET/POST/PATCH/DELETE)

* Required headers (auth, content type, caching)

* Query params for filter/sort/pagination

* Response shapes and key fields

* **Suggested endpoint set (logical)**

* Meetings list: `GET /api/v3/meetings` (or project-scoped equivalent)

* Meeting detail: `GET /api/v3/meetings/{id}`

* Create meeting: `POST /api/v3/meetings`

* Update meeting: `PATCH /api/v3/meetings/{id}`

* Delete meeting: `DELETE /api/v3/meetings/{id}`

* Related entities (as supported on web):

* Agenda items list/update (either embedded or sub-resource)

* Attachments (upload/list/delete)

* Participants/attendees

* Relations to work packages

* **Note:** final paths/structures must match OpenProject’s actual API; treatEnd of the insertion the Begin of the insertionabove as placeholders until confirmed.

* **Authentication**

* Use the same auth mechanism supported by OpenProject for mobile (e.g., OAuth2, API token, session-based) as defined by the product.

* All calls must include the required auth header/cookie and handle token refresh/expiration consistently.

* **Serialization &amp; rich text**

* Define canonical representation for meeting “notes/protocol” and “agenda descriptions” (HTML/Markdown/etc.).

* Mobile rendering must be read-safe (no XSS vectors) and editing must round-trip without stripping unsupported markup.

* If full rich-text editing is not feasible, implement:

* Read-only rendering for complex content

* A constrained editor for a safe subset

* Or a server-supported plain-text field update path (if available)

* **Caching**

* Apply cache policy for:

* Meeting list (short-lived cache)

* Meeting details (cache with invalidation on update)

* Respect server cache headers if present (ETag/Last-Modified).

* **Concurrency control**

* Prefer ETag-based conditional updates or lockVersion-style fields if the API supports it.

* On `412 Precondition Failed` or conflict response, fetch latest meeting and prompt user.

* **Observability**

* Add structured logging for request latency, status codes, and error categories (without logging sensitive payloads).

* Add client-side analytics events forEnd of the insertion key Begin of the insertionoperations (optional, if product uses analytics).


### Permissions and Visibility ConsiderationsEnd of the insertion Begin of the deletion languages_&nbsp;


**Out of scope**End of the deletion

* Begin of the insertionAPI calls must never assume permission; the UI shouldEnd of the insertion Begin of the deletion <br>


_Set the_ **ToEnd of the deletion be Begin of the insertiondriven by server-provided capabilities where possible (e.g., `_links`, `allowedActions`, or similar).

* If meeting access is project-bound:

* Ensure the mobile client only queries meetings within projects the user can access, or relies on server filtering.

* Participant and attachment operations mustEnd of the insertion Begin of the deletion informed/consulted teams** _field to include all teams necessary toEnd of the deletion be Begin of the insertionguarded by permission checks; if API returns 403, UI falls back to read-only and shows an appropriate message.

* Avoid leaking meeting content in logs, crash reports, or analytics.


### OutEnd of the insertion Begin of the deletion informedEnd of the deletion of Begin of the insertionScope

* Redesigning or changingEnd of the insertion the Begin of the insertiondesktop-browser Meetings module behavior.

* Implementing new backend meeting features unrelated to enabling mobile parity.

* Supporting unofficial or internal-only endpoints as a long-term solution (short-term bridging may be documented, but target is supported API contracts).

* Implementing a full offline sync engine with queued writes and background reconciliation.End of the insertion Begin of the deletion changes._End of the deletion