Search
Returns Threads posts matching a keyword, each with its text, like count, author, creation time, and the topic tag it was filed under at post.ext.topic_tag, plus a cursor for the next window.
Use it to find posts by topic across Threads. Follow pagination.next_cursor to page deeper, or set limit (up to 100) to collect several windows in one call; start_date and end_date bound the period.
Metered: 10–340 credits. We reserve the ceiling when the call starts and charge what it actually used when it finishes.
Paginates by cursor: see Pagination.
Request
- Base URL: https://api.insightsocial.app
- URL: https://api.insightsocial.app/v1/threads/search
- Auth: API key in header x-api-key
Query parameters
Search keyword or phrase to find Threads posts
Inclusive start of the search period (YYYY-MM-DD). Pagination never walks past it, and a relaxed query drops any post older than it. Threads treats the date pair as a ranking hint rather than a filter, so the window is enforced on our side: a post we cannot date is treated as outside it.
Inclusive end of the search period (YYYY-MM-DD). Pagination starts here and walks back in time, and a relaxed query drops any post newer than it.
Ask for a stripped record. This is a real shape change, not just less whitespace: a trimmed row carries only the id, text, shortcode, like count, timestamp and author, so media, reply count, share count, view count, topic tag, pinned flag and quoted post all come back null.
Opaque cursor from a prior response's pagination.next_cursor, passed back verbatim, to fetch the next (older) result window. It carries your date bounds, so paging cannot escape the period you asked for. A request that sends a cursor is never query-relaxed.
Collect AT LEAST this many unique posts in one call (1-100). This is a collection target, not a page size: the API walks whole result windows server-side until it has collected this many (or the query runs dry), so the response usually carries somewhat more than you asked for and never fewer unless the query ran out. Nothing you paid for is trimmed away. Omit for a single window. BUDGET FOR THE WALL CLOCK: the windows run one after another, at roughly 3.4 seconds each, so a high limit is a long request. Measured on production 07/09/2026, cache-cold: no limit 3.5s for 20 posts, limit=30 7.3s for 37, limit=50 10.2s for 55, limit=100 19.5s for 111. If your HTTP client defaults to a 10-second timeout, limit=50 and above will not fit inside it. Either raise the client timeout, or ask for a smaller limit and page with pagination.next_cursor, which costs the same credits for the same posts.
Set to false to search the exact phrase only. Ignored on a request that carries a cursor.
Send engagement to fill engagement.views and post.flags.pinned on the first 20 posts by looking each one up on /v1/threads/post in the same call. Adds 3 to 12 seconds, never more than 12. One token only: engagement. Not accepted with a limit above 20; page with the cursor for more.
Set to 1 to get the price of this call without making it: data.dry_run carries credits_min and credits_max. Nothing is charged.
Only rows published on or after this date: YYYY-MM-DD (midnight UTC) or an ISO 8601 timestamp. Rows older than it are left off each page. This list is not in date order, so the walk does not stop at the date: keep following next_cursor, and each page costs what a page costs even when every row on it is filtered out. A row with no date is kept.
Only rows published on or before this date: YYYY-MM-DD (that whole UTC day is included) or an ISO 8601 timestamp. Newer rows are left off each page and the walk does not stop, so older pages follow. A row with no date is kept.
1 to 5 (default 1). Walk up to this many pages in one call and return the rows from all of them (after any filter). Each page walked is billed as one call to this endpoint; the whole walk counts once against your rate limit.
Response
Success.
Changes
No recorded changes to this operation across all 1 revision of this API.