Tools

posts_list

Posts with their per-channel targets and publish status.

Posts with their per-channel targets and publish status. Filter by status (draft/scheduled/publishing/published/failed) and/or a scheduled-time range (ISO-8601 with offset) for calendar views, and/or by campaign, label, or channel — so “my scheduled LinkedIn posts” is one call rather than a range pulled down and filtered locally. Rows are excerpts and carry no fit verdicts unless you ask: include: ["ready"] adds ready per row, which answers “which of these can I publish?” without a posts_get each (the page is capped at 25 — each judged row costs a full post read, and an absent ready means not checked). Read one post in full with posts_get. Paginated: pass next_cursor from the previous page as cursor to continue.

Input

FieldTypeRequiredDescription
organizationstringnoOrganization slug to act in (see organizations_list). Optional: API keys are bound to one organization; OAuth connections default to your active organization.
statusesarrayno
scheduled_fromstringnoISO-8601 with offset
scheduled_tostringnoISO-8601 with offset
campaignstringnoOnly posts filed under this campaign id
labelstringnoOnly posts carrying this label id
channelstringnoOnly posts targeting this channel — id or provider name (“x”, “linkedin”)
includearraynoExtra per-row fields to compute. [“ready”] runs the fit check per row (caps the page at 25; absent ready means not checked, not false).
limitintegernoRows per page (default 25, max 100)
cursorstringnonext_cursor from a prior page for keyset pagination

Result

JSON on success. A refusal comes back as an error prefixed with its code (NOT_FOUND, FORBIDDEN, TOO_MANY_REQUESTS, …) and a message written to be acted on — read it before retrying.

The same operation elsewhere

This tool and the REST operation postsList and the CLI command inklate posts list run the same guarded procedure the dashboard uses — same permissions, same validation, same tenant isolation.