Facebook

The Facebook connector exposes four endpoints:

Endpoint	Purpose	Billed
GET /v1/facebook/search	Keyword search across public Facebook posts	per page
GET /v1/facebook/page/{page_id}/posts	A public Page or profile's posts, newest first	per page
GET /v1/facebook/post/{post_id}	A single post with author, text, and engagement counts	per request
GET /v1/facebook/post/{post_id}/comments	A post's comments	per page

The typical workflow is discover → fetch: run a keyword search or pull a Page's timeline to discover relevant posts, then pass each result's id to the post and comments endpoints for the full record.

Post identifiers

A post is identified by its id, returned by the search and Page-posts endpoints. Both the post and comments endpoints accept that id — or a full Facebook post URL verbatim:

• Post id — 253053527513133
• Full post URL — https://www.facebook.com/story.php?story_fbid=253053527513133&id=100064000
• A pfbid… token or a .../posts/pfbid… URL

Search and Page-posts results already include both the id and the url, so you can hand either straight to the post endpoint.

Engagement vocabulary

Post engagement is surfaced under stable keys:

Field	Meaning
reaction_count	Total reactions (likes, loves, etc.) on the post
comment_count	Comments on the post
share_count	Shares, when available

Why some fields are null

Not every post exposes every metric. Missing values are returned as null rather than dropped, so your schema stays stable.

Latency & reliability

Facebook is a public-web source, so:

• Results are best-effort discovery — they reflect what is publicly available and can shift over time; they are not exhaustive.
• Occasional 429 upstream_rate_limited responses indicate a transient block — retry with backoff and it will clear. See Errors.
• Large max_pages values run several sequential fetches; prefer modest page counts and paginate over multiple calls for big pulls.