facebook

Search Facebook videos by keyword

Searches public Facebook videos and reels by keyword and returns unified Post items: video id, caption, permalink, thumbnail, the author's name and numeric id (post.ext.author_id), the author's profile URL (post.ext.author_url), and the verified flag where Facebook shows it. Facebook's search card carries no counts, no duration and no publish date (its view count is a rounded display string that runs well below the real count, so it is never parsed), so on a plain call post.engagement, post.content.duration_seconds, post.published_at and post.author.avatar_url are null on every row. Send include=details and every video is joined, in the same call, to the per-post lookup for its permalink: the exact view, like, comment and share counts (post.engagement.views, .likes, .comments and .shares), the duration, the publish time, the author's avatar and the per-reaction breakdown (post.ext.reaction_counts) land on each row. The video id, permalink, caption and thumbnail the search row carries are never replaced. With start_date or end_date, the join dates every video and a video dated outside your window is then dropped; its lookup is still billed, since the search card carries no date to filter on before it. Cost: 1 credit for the page plus 1 credit per video filled from a fresh lookup (7 videos a page, so 8 credits at most); rows already in cache are filled for free, rows that could not be filled are refunded, and a repeat of the same call within the cache window is 0 credits. Time: include=details adds 3 to 5 seconds on a fresh page (the lookups run in parallel and the call waits for the slowest, never more than 12 seconds) and nothing when the rows are already cached. The response carries a hydration block itemising rows, lookups, cache hits, credits and milliseconds. About 7 videos a page. Forward pagination.next_cursor as cursor.

get/facebook/search/videos

Request

  • Base URL: https://www.socialcrawl.dev/v1
  • URL: https://www.socialcrawl.dev/v1/facebook/search/videos
  • Auth: API key in header x-api-key

Query parameters

querystring required

Keyword or phrase to search for.

cursorstring

Cursor from the previous response.

start_datestring

Include videos on or after this date (YYYY-MM-DD).

end_datestring

Include videos on or before this date (YYYY-MM-DD).

recent_videosboolean

When true, rank by recency instead of relevance.

location_uidstring

Facebook location id to scope the search.

include'details'

Set to details (one token only) to fill post.engagement.views, .likes, .comments and .shares, post.content.duration_seconds, post.published_at, post.author.avatar_url and post.ext.reaction_counts on every video in this one call. Holds 1 credit per video (7 a page) and keeps only the rows filled from a fresh lookup: rows already in cache and rows the lookup cannot fill are refunded, so a page is never more than 8 credits. The join takes 3 to 5 seconds on a fresh page, never more than 12, and nothing when the rows are already cached; read data.hydration for the rows, the credits held and kept, and the time. Without it the call is unchanged.

sincestring

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. published_after, start_date, from_date, publish_time (yesterday, this-week, this-month, last-3-months, last-6-months) and max_age_days are accepted and applied as since.

untilstring

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. published_before, end_date and to_date are accepted and applied as until.

Headers

Cache-Controlstring

Send no-cache to bypass the response cache and force a live fetch. Billed at the normal endpoint cost; the fresh result is written back to cache for the next caller. Only the no-cache directive triggers this. See the Response Schema guide for details.

Idempotency-Keystring

Optional UUID that makes the request safely retriable. The key is reserved atomically per account before billing. A concurrent retry receives 409 IDEMPOTENCY_IN_PROGRESS with a Retry-After of 1 second while the original is young, growing to a quarter of the time it has been running (at most 30); a crashed reservation expires after 5 minutes. A replay keeps the cached payload immutable except for billing metadata: credits_used becomes 0, idempotent_replay becomes true, and credits_remaining is refreshed to the current balance. A known current balance appears in both the body and X-Credits-Remaining header; no balance row resolves to 0. On a transient lookup failure, body credits_remaining is null and X-Credits-Remaining is omitted. Completed outcomes expire after 24 hours. If the claim store is unavailable, the request fails closed before billing. GET endpoints do not combine idempotent replay with Server-Sent Events: use Accept: application/json when sending this header. The unsupported key-plus-SSE combination is rejected before billing.

Response

Successful response

successboolean required

Whether the request succeeded

platformstring required

Platform name

endpointstring required

API endpoint path

credits_usedinteger required

Number of credits consumed

credits_remaininginteger nullable required

Current account balance, or null when this response could not establish one. Free cache hits always return null because they do not establish an authoritative post-request balance. An idempotency replay also returns null when its current-balance lookup fails. It is never a fabricated zero, so a zero here means the account really is empty. The authoritative reading is the one on a billed response, which comes straight from the deduction.

request_idstring required

Unique request identifier for support

cachedboolean required

Whether the response was served from cache

idempotent_replayboolean

True only when this response is an idempotency replay

Example response

{
  "success": true,
  "platform": "facebook",
  "endpoint": "/v1/facebook/search/videos",
  "credits_used": 1,
  "credits_remaining": 4999,
  "request_id": "req-abc123",
  "idempotent_replay": true,
  "meta": {
    "hint": {
      "code": "search_multi",
      "message": "You searched \"matcha\" on 3 platforms one call at a time; /v1/search/multi returns each platform's own search rows in one call at the same price per platform, and a platform with no rows is not charged.",
      "method": "GET",
      "path": "/v1/search/multi?query=matcha&platforms=instagram,tiktok,youtube"
    }
  },
  "pagination": {
    "next_cursor": "sc.eyJ2IjoyLCJjIjoiMiIsInAiOiJwYWdlIn0",
    "has_more": true,
    "page_size": 30,
    "stopped_at": "known_id"
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.