The Object Model
Every record stored in DemandFlow, a person, a patent, a knowledge base article, a log entry, a relationship link, is an object. Objects all share the same JSON shape and the same set of API endpoints. There are no per-entity URLs, no per-entity create/update operations, no per-entity schemas to learn beyond the fields each entity carries.
What an object looks like
{
"id": "a1b2c3d4-e5f6-4890-abcd-ef1234567890",
"entity": "PPL",
"level": 220,
"comboKey": "SUB:fd6900a2-...|ENT:a8da263a-...",
"subscription": "<your-sub-id>",
"ownerId": "<user-id>",
"updatedId": "<user-id>",
"created": 1776336000000,
"updated": 1776338516765,
"_df_version": 2,
"name": "Ada Lovelace",
"firstName": "Ada",
"lastName": "Lovelace",
"email": "ada@example.com"
}System fields vs entity fields
Every object carries the same system fields, id, entity, level, comboKey, subscription, ownerId, updatedId, created, updated, _df_version. These are partly written by you on create and partly maintained by the server. See System Fields for the full list and ownership rules.
Below the system fields, every entity has its own set of entity-specific fields, a person has firstName, an action has dueDate, a knowledge article has content. These vary per entity and are documented on the per-entity reference pages.
The entity code
Every object has an entity field, an uppercase code identifying what type of object it is (PPL, PATENT, KBPUBLIC, LOG, LINK). The entity code drives validation, list queries, the tenant-table partition, and which definition controls the object's fields.
Why one shape
This uniform model is what makes the API small: a single CRUD set (GET, POST, PATCH, DELETE) plus a list query (GET /v1/entities) covers every entity type in the system. Add a new entity definition and the same API endpoints work without any code change.