countOutboundTexts
HOW MANY TEXTS WENT OUT in a time window: one call, exact, live (not a nightly snapshot).
HOW MANY TEXTS WENT OUT in a time window: one call, exact, live (not a nightly snapshot). Use it for "how many texts did we send this week" instead of paging listInboxThreads, which is a preview feed and cannot count. WINDOW: startDate (inclusive) and endDate (exclusive) as ISO datetimes WITH an offset: resolve "this week"/"today"/"since 9/28" in the USER's timezone yourself (getMyProfile.resolvedTimezone, or the organization timezone) before calling; an offset-less time is read in the server zone. At most 93 calendar days; a wider window is REFUSED with a message (split it and add the parts). WHAT IS COUNTED: OUTBOUND texts created in the window on a line your organization owns or owned: the organization's texts whoever sent them, never another organization's. INBOUND texts are never counted. SKIPPED sends (the product declined to send: opt-out, Do-Not-Contact, throttle) are NOT counted. Each bucket reports sent (PENDING + SENT + DELIVERED: accepted for dispatch), delivered (the carrier-confirmed subset of sent) and failed (FAILED). byUser is each member's OWN sends: a text with an AI-employee or workflow stamp is never a member's, even when it went out on that member's line. otherSenders holds the rest: aiEmployees (texts an AI employee authored), workflows (texts a workflow or campaign step sent) and unattributed (a person's sends whose user was since removed). total is every bucket summed, so on an org-wide read it IS the whole organization's outbound volume. byUser is ranked by sent + failed, and a row's name is null when the user is gone; on an org-wide read only members with at least one counted text appear, while every member you NAME in userIds appears (zeros included). VISIBILITY (the inbox rule): with no userIds, a key owner who may read teammates (VIEW_TEAM_CALLS_TEXTS or VIEW_ALL_PHONES; admins) gets the WHOLE organization and otherSenders; anyone else gets ONLY THEIR OWN row and otherSenders null: so a non-admin's total is their own sends, not the team's; say so rather than reporting it as the org total. Naming a teammate in userIds without either is REFUSED (an error, not zeros); with it, userIds narrows to those members and otherSenders is null. getMyCapabilities says which the key owner holds. Teammate ids come from listTeammates.
curl https://server.goliathdata.com/api/v1/call \
-H "Authorization: Bearer $GOLIATH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"operationId": "countOutboundTexts",
"variables": {
"startDate": "2026-01-01T00:00:00.000Z",
"endDate": "2026-01-01T00:00:00.000Z"
}
}'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.team.countOutboundTexts({
startDate: '2026-01-01T00:00:00.000Z',
endDate: '2026-01-01T00:00:00.000Z'
})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: 'countOutboundTexts',
variables: {
startDate: '2026-01-01T00:00:00.000Z',
endDate: '2026-01-01T00:00:00.000Z'
}
}),
})
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.
Response
What comes back under data: a list shows as one entry, and a value as its type.
{
"data": {
"teamAnalyticsQuery": {
"outboundTextCounts": {
"startDate": "2026-01-01T00:00:00.000Z",
"endDate": "2026-01-01T00:00:00.000Z",
"total": {
"sent": 0,
"delivered": 0,
"failed": 0
},
"byUser": [
{
"userId": "<ID>",
"name": "…",
"sent": 0,
"delivered": 0,
"failed": 0
}
],
"otherSenders": {
"aiEmployees": {
"sent": 0,
"delivered": 0,
"failed": 0
},
"workflows": {
"sent": 0,
"delivered": 0,
"failed": 0
},
"unattributed": {
"sent": 0,
"delivered": 0,
"failed": 0
}
}
}
}
}
}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.