---
title: Custom entities
description: Custom entities have API names that start with CE_. Use them like built-in entities, find their names in the Entities endpoint, and read their fields from your space's own spec.
canonical: https://developers.coevera.com/concepts/custom-entities/
section: concepts
verification: schema
lastVerified: 2026-10-15
publisher: Coevera
---

# Custom entities

**Answer:** A custom entity's API name is CE_ plus its name in CamelCase, such as CE_Asset, and its types are CE_AssetType. Use /entities/CE_Asset like a built-in entity; /entities/CustomEntities is refused. Read the names from the Entities endpoint and your space's own spec rather than from labels, which admins can rename.

An admin can add entities of their own, such as assets or contracts, next to Accounts and
Contacts. They work like the built-in entities, under names you have to look up.

## API names

A custom entity's API name is `CE_` followed by the name the admin gave it, in CamelCase:
**Asset** becomes `CE_Asset`. Its types, the layouts its records can use, are a second entity
with `Type` added: `CE_AssetType`.

| Request                  | Path                                                               |
| ------------------------ | ------------------------------------------------------------------ |
| List, create             | `/entities/CE_Asset`                                               |
| Read, update, delete one | `/entities/CE_Asset/{id}`                                          |
| Batches                  | `/entities/CE_Asset/batch-modify`, `batch-delete`, `batch-restore` |
| Its types                | `/entities/CE_AssetType`                                           |

The prefix is part of the name. `/entities/CustomEntities` is refused with HTTP 404, code 143
`ERROR_NO_ENTITY`: "To work with custom entities, you have to specify concrete custom entity api
name instead of CustomEntity/CustomEntities". A custom entity record needs an `owner_id`, like
most built-in records ([data model](/concepts/data-model/#owners-and-sales-units)).

## Find your custom entities

`GET /entities/Entities` lists every entity of the space. Ask for the custom ones by their prefix:

```text
GET /entities/Entities?filter[entity_name]=CE_&filter-op[entity_name]=starts&load-only=entity_name,name_singular,name_plural
```

`entity_name` is the stable name to use in paths. `name_singular` and `name_plural` are the labels
an admin set, and are `null` while the default applies. A custom entity's fields come from the
[Fields endpoint](/concepts/fields-and-custom-fields/#find-a-fields-api-name) and from your
space's own spec, `/api/v100/rest/spaces/{space_id}/openapi.json`. The published spec has only
the path templates `/entities/{custom_entity_api_name}` and `/entities/{custom_entity_type_api_name}`,
which the reference shows as [custom entity records](/reference/rest/custom-entities/) and
[custom entity types](/reference/rest/custom-entity-types/).

## Labels change, API names are what you key on

Admins rename entities and fields in the app, so a label that matched yesterday may not match
today. An integration that derives a path from a label, or looks a field up by its label, breaks
on the first rename. Read `entity_name` and the fields' `api_name` once, at start-up or when you
configure the integration, and use those.

## Limits

| Limit             | Details                                                                                          |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| The query builder | Offers the standard entities only; your custom entities and fields are not in the published spec |
| Renaming          | Read `entity_name` from the Entities endpoint rather than deriving it from the entity's label    |
