Public API returns 200 but does not persist project logo_props

Bug reports
1 
Hi Plane team,

I found an inconsistency between the public API and the UI/session API for project icons.

Summary

The Plane UI appears to render project icons from `logo_props`, but the public API exposes/accepts `icon_prop`.

When I try to update `logo_props` through the public API, the request returns HTTP 200, but the value is not persisted.

Environment

- Plane self-hosted
- Public API route:
  `PATCH /api/v1/workspaces/{workspace_slug}/projects/{project_id}/`
- UI/session API route that works:
  `PATCH /api/workspaces/{workspace_slug}/projects/{project_id}/`

Steps to reproduce

Send this request to the public API:

```http
PATCH /api/v1/workspaces/{workspace_slug}/projects/{project_id}/
Content-Type: application/json
X-Api-Key: <api-key>
```

Payload:

```json
{
  "logo_props": {
    "icon": {
      "name": "bug_report",
      "color": "#8B5CF6"
    },
    "in_use": "icon"
  }
}
```
Current behavior

- The API returns HTTP 200.
- The response still contains the previous `logo_props`.
- Re-fetching the project also shows the previous `logo_props`.
- The visible project icon in the UI does not change.

Expected behavior

One of these should happen:

1. `logo_props` should be persisted through the public API, because it appears to be the field used by the UI for project icons.
2. Or `icon_prop` should drive the visible UI project icon.
3. Or the public API should reject unsupported `logo_props` updates instead of returning HTTP 200.

Additional context

Updating the same field through the UI/session-backed API does work:

```http
PATCH /api/workspaces/{workspace_slug}/projects/{project_id}/
```

Payload:

```json
{
  "logo_props": {
    "icon": {
      "name": "bug_report",
      "color": "#8B5CF6"
    },
    "in_use": "icon"
  }
}
```

So this looks like either a public API bug, a serializer/update-field allowlist issue, or a documentation mismatch between `icon_prop` and `logo_props`.

Thanks.
2

Thanks for reporting this. We have identified the issue and are working on a fix. We will update this thread as soon as it’s resolved.

3

Good news!

Thanks for the feedback. Since we have a work-around, we fix it temporary this way.