listMyTasks
The key owner's OWN to-do queue (appointments, never OVERDUE here: listAppointments).
The key owner's OWN to-do queue (appointments, never OVERDUE here: listAppointments). With no participants filter it is the key owner's, for every role. Pass userIds in participants (listTeammates, same-org) for a teammate's queue or a team backlog; a MEMBER key stays narrowed to itself regardless, and a team-admin key sees only tasks on contacts THE KEY OWNER CAN ACCESS, never a complete backlog. A task with no participants is unassigned and appears in neither. Each row's participants say WHO IT BELONGS TO: read them before acting, never assume the reader owns what came back. OVERDUE is INCOMPLETE tasks due before TODAY in timezone, so a task due 9am today is not in it. For what is overdue or past due, read completed: false with dueBefore now. Also filter by taskStatus TODAY/FUTURE, completed, dueBefore/dueAfter, searchTerm; timezone sets day boundaries: EST/CST/MST/AZ/PST/HST or that zone's IANA name (America/New_York, America/Chicago, America/Denver, America/Phoenix, America/Los_Angeles, Pacific/Honolulu; AZ is Arizona, which keeps MST all year); any other is refused. Rows carry dueDate, completedAt, the contact (id + name: the contactId completeTask needs; null when it has none) and deals (the dealId updateTaskOnDeal needs when contact is null). PAGING: this operation IS cursor-paginated, so "show me the rest" is answerable here. When canFetchNext is true, re-call with the SAME filters and cursor set to the LAST row's id to get the rows after it; repeat until canFetchNext is false. Forward only: there is no backwards page, so to revisit earlier rows restart from the top. Keep every filter identical between pages; changing one restarts the walk. total is the unpaged match count for the filters, so nothing is silently truncated. Order: latest-due first with dueBefore/OVERDUE and no dueAfter/TODAY/FUTURE; completed: true by latest completion; else soonest-first, open first.
curl https://server.goliathdata.com/api/v1/call \
-H "Authorization: Bearer $GOLIATH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"operationId": "listMyTasks",
"variables": {}
}'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.tasks.listMyTasks({})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',
},
body: JSON.stringify({
operationId: 'listMyTasks',
variables: {}
}),
})
const { data, errors } = await res.json()limit is clamped to 50.
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.
AZ: Arizona: MST all year, no DST.
Default 25.
Response
What comes back under data: a list shows as one entry, and a value as its type.
{
"data": {
"users": {
"getUserTasks": {
"tasks": [
{
"id": "<ID>",
"title": "…",
"description": "…",
"taskType": "…",
"dueDate": "2026-01-01T00:00:00.000Z",
"timezone": "IDLW",
"completedAt": "2026-01-01T00:00:00.000Z",
"contact": {
"id": "<ID>",
"name": "…"
},
"deals": [
{
"id": "<ID>"
}
],
"participants": [
{
"id": "<ID>",
"firstName": "…",
"lastName": "…"
}
]
}
],
"total": 0,
"canFetchNext": true
}
}
}
}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.
Behaviour
A read. It rejects an Idempotency-Key header with 400 bad_request.