> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.coperniq.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.coperniq.io/_mcp/server.

## Project & opportunity title fallback

When a project or opportunity has no title of its own (empty string or whitespace-only), the API now returns the **parent account's title** in the `title` field instead of the blank value.

This applies to all read endpoints that return project or opportunity records:

* `GET /projects`, `GET /projects/search`, `GET /projects/{projectId}`
* `GET /opportunities`, `GET /opportunities/search`, `GET /opportunities/{opportunityId}`

### Behavior

| Record title         | Parent account title | Response `title`     |
| -------------------- | -------------------- | -------------------- |
| `"Roof replacement"` | `"Acme Co"`          | `"Roof replacement"` |
| `""` (empty)         | `"Acme Co"`          | `"Acme Co"`          |
| `"   "` (whitespace) | `"Acme Co"`          | `"Acme Co"`          |
| `""`                 | `""` or no parent    | `""`                 |

The underlying stored record is **not** modified — this is a read-time fallback only. Write endpoints (`POST`, `PATCH`) continue to accept and persist titles exactly as provided.

### Why

Many integrations rely on `title` being a meaningful, human-readable label (list views, search results, downstream syncs). Projects that were created without a title were surfacing as blank rows, which was confusing. Falling back to the parent account's title gives consumers a sensible default without changing the source of truth.