addPropertiesToList
Add properties to one or more lists (list ids from searchPropertyTags).
Add properties to one or more lists (list ids from searchPropertyTags). ASYNC bulk-task op: returns bulkTaskId before the change applies; poll getBulkTask. TWO selection forms, never combined (ids with a filter is rejected). EXPLICIT: propertyIds (esIds) with totalCount = how many. FILTER-BACKED: filterId (saved; must be visible to the key owner (a teammate's private filter is refused) OR filterTree (inline, saveFilter's DSL, parsed STRICTLY) an unknown fieldId rejects the call) with selectAll: true for EVERY match or selectCount: N for the first N in the runner's DEFAULT traversal order: NOT the sort you previewed with on filterProperties, which the bulk task does not take; for a sorted top-N, pass that sorted page's ids as propertyIds (one window, not both; neither is REFUSED). An inline filterTree has no saved areas: save one with inSavedAreas and pass its filterId. excludeIds applies to a filter-backed selection only (on the explicit form, leave the id out). totalCount is an EXECUTION CAP the task stops at. It is DERIVED server-side for explicit ids (their count) and for selectCount: N (N (exclusions are not subtracted, the runner drops them as it goes)) whatever you send is ignored there, and a negative value is rejected (and TRUSTED only for selectAll: true: pass the filter's total from filterProperties UNSUBTRACTED (never minus excludeIds) the runner handles exclusions). An understated select-all count silently turns it into a partial write, so round UP. Pass the same includeIncompleteRecords you used on filterProperties. A filter-backed selection can touch thousands of properties in one call: state the match count to the user and get a go-ahead BEFORE submitting one.
curl https://server.goliathdata.com/api/v1/call \
-H "Authorization: Bearer $GOLIATH_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"operationId": "addPropertiesToList",
"variables": {
"listIds": [
"<String>"
],
"totalCount": 10
}
}'import { GoliathClient } from '@goliath-data/sdk'
const goliath = new GoliathClient({
apiKey: process.env.GOLIATH_API_KEY!,
baseUrl: 'https://server.goliathdata.com',
})
const result = await goliath.properties.addPropertiesToList(
{
listIds: [
'<String>'
],
totalCount: 10
},
{ idempotencyKey: crypto.randomUUID() },
)const res = await fetch('https://server.goliathdata.com/api/v1/call', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.GOLIATH_API_KEY}`,
'Content-Type': 'application/json',
'Idempotency-Key': crypto.randomUUID(),
},
body: JSON.stringify({
operationId: 'addPropertiesToList',
variables: {
listIds: [
'<String>'
],
totalCount: 10
}
}),
})
const { data, errors } = await res.json()Variables
The example sends only what the schema requires. Some operations also need one of several optional variables (one filter or another, say); the description above says which.
Default false.
Response
What comes back under data: a list shows as one entry, and a value as its type.
{
"data": {
"propertyMutation": {
"addPropertiesToList": {
"mode": "SYNC",
"bulkTaskId": "…"
}
}
}
}Errors
unknown_variableA variable the operation does not declare. A typo is refused rather than silently dropped.
unauthorizedNo bearer header, or the key is invalid or revoked.
insufficient_scopeThe key lacks the scope the operation requires.
forbiddenA referenced record does not exist, was deleted, or is outside your organization. The gateway cannot tell those apart.
idempotency_conflictA request with this Idempotency-Key is still in flight.
Idempotency
Send an Idempotency-Key of 1 to 255 characters. A finished request retried with the same key replays its stored response, marked Idempotency-Replayed: true; one still in flight returns 409 idempotency_conflict. Keys expire after 24 hours. Write without fear →