LINK Objects
A LINK is a real DemandFlow object whose only job is to join two other objects. It's the standard pattern for many-to-many relationships and for relationships where there is no natural "parent". A LINK always has entity = "LINK" and level = 0.
Why two combo keys
LINK is the canonical use of the multiple-combo-key pattern. To make the join queryable from either end, every LINK carries two combo keys:
comboKey, placed under side A, lets you list "every link from A".comboKey2, placed under side B, lets you list "every link from B".
Both keys point at the same single LINK record. Two GSIs (entity-comboKey-index and entity-comboKey2-index) make queries from either side equally fast.
Shape of a LINK
{
"id": "<link-id>",
"entity": "LINK",
"level": 0,
"comboKey": "SUB:<sub>|PPL:<personId>|COMP:<companyId>|ENT:<link-id>",
"comboKey2": "SUB:<sub>|COMP:<companyId>|PPL:<personId>|ENT:<link-id>",
"subscription":"<sub>",
"linkType": "employee-of",
"ownerId": "...",
"created": 1776000000000,
...
}The two combo keys are mirrors of each other, same segments, swapped order. A custom field like linkType describes what the relationship represents.
Creating a LINK
When you POST a LINK you provide both keys (each ending in |ENT:). The server appends the new id onto both:
POST /v1/objects
{
"entity": "LINK",
"level": 0,
"comboKey": "SUB:<sub>|PPL:<personId>|COMP:<companyId>|ENT:",
"comboKey2": "SUB:<sub>|COMP:<companyId>|PPL:<personId>|ENT:",
"linkType": "employee-of"
}Querying from either side
# Every company linked to this person
GET /v1/entities/LINK/SUB:<sub>|PPL:<personId>
# Every person linked to this company
GET /v1/entities/LINK/SUB:<sub>|COMP:<companyId>Both queries return the same LINK records. Parse the comboKey of each LINK to extract the id of the other side, then GET those objects if you need their full data.
Deleting a LINK
A single DELETE on the LINK's id removes the relationship in both directions, there's only ever one record.
When NOT to use LINKs
- Strict ownership: when the child genuinely has one parent that owns it (e.g. patent application under patent), use comboKey hierarchy instead, no extra record to maintain.
- Single foreign-key reference: if you only need to navigate one way (e.g. "this article belongs to this category"), a plain field holding the other object's id is simpler than a LINK.