# Facebook Profile Photos API (https://www.socialcrawl.dev/platforms/facebook/profile-photos)

> Returns Facebook page or profile photos as unified Post items. Each item includes a photo ID, permalink, full-size image URL, thumbnail, and accessibility caption when available. The photo listing itself carries no author, engagement or date, so on a plain call `post.author`, `post.engagement` and `post.published_at` are null on every row. Send `include=details` and every photo is joined, in the same call, to the per-post lookup for its permalink: the page's name and avatar (`post.author.display_name`, `post.author.avatar_url`) and numeric id (`post.ext.author_id`), the reaction count, the comment count, the share count and the publish time land on each row. What the counts mean depends on the photo: a photo posted on its own carries that post's counts (the photo IS the post), while a photo inside a multi-photo post carries its own counts, which are usually far lower than the post's. The publish time is the post's either way. Photos have no view count, so `post.engagement.views` stays null. Cost: 1 credit for the page plus 1 credit per photo filled from a fresh lookup (8 photos a page, so 9 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 2 to 8 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.

TL;DR: `GET /v1/facebook/profile/photos` costs 1 credit for the page. include=details holds 1 credit per photo (8 a page) and keeps only the rows filled from a fresh lookup, so a page is at most 9 credits; rows served from cache are free, unfilled rows are refunded, and a repeat of the same call within the cache window costs 0. With `max_pages`, `max_items` or `max_credits`, each page walked is billed at this price (a cached page is free), and `max_credits` caps the total. and returns SocialCrawl's unified JSON schema. Single x-api-key auth, 100 free credits on signup.

## Parameters

| Parameter | Required | Description |
| --- | --- | --- |
| `url` | yes | Full URL of the Facebook page or profile. A profile share link (`https://www.facebook.com/share/…`) is accepted. |
| `next_page_id` | no | To paginate through to the next page |
| `cursor` | no | To paginate through to the next page |
| `include` | no | Set to `details` (one token only) to fill `post.author.display_name`, `post.author.avatar_url`, `post.ext.author_id`, `post.engagement.likes`, `.comments` and `.shares`, and `post.published_at` on every photo in this one call. Holds 1 credit per photo (8 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 9 credits. A photo inside a multi-photo post carries its own counts, not the post's. The join takes 2 to 8 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. (details) |
| `since` | no | 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`. |
| `until` | no | 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`. |
| `max_pages` | no | 1 to 50 (default 1, or 50 when `max_items` or `max_credits` is sent). Walk up to this many pages in one call and return the rows from all of them. Each page walked is billed exactly as one call to this endpoint (a cached page is free) and counts against your rate limit; its charge and any refund are recorded under the page's own request id, listed in `data.walk.request_ids`. The walk stops early at the last page, or when the request's time budget runs low; `data.walk.stopped` says why (`end`, `max_pages`, `max_items`, `max_credits`, `time_budget`, `page_error`) and `pagination.next_cursor` continues from where it stopped. |
| `max_items` | no | 1 to 5000. Get more in one call: keep walking pages until the response holds at least this many rows, then stop with `data.walk.stopped: "max_items"`. The last page is returned whole (it was billed), so `data.items` can hold up to one page more than this, and `pagination.next_cursor` resumes right after it without skipping a row. Walks up to 50 pages unless `max_pages` says fewer; each page is billed as one call (a cached page is free). Add `max_credits` to cap the spend. A long walk can stop on the time budget first (`"time_budget"`): send the returned cursor with the same params to continue. |
| `max_credits` | no | 1 to 100000. The most this call may spend, across every page it walks. A page starts only while the credits already spent plus that page's price (or, when higher, the most any page of this walk has cost) still fit, so the call never goes past it; the walk then stops with `data.walk.stopped: "max_credits"` and the cursor to resume. Sent alone, it walks as far as the budget goes (up to 50 pages). A value below the price of one page is a free 400 whose `error.details.page_credits` names that price. Credits a row join (`include=`) adds are known only once a page has run, so page 1 is checked against its own price. |

## Code example

```bash
curl -G "https://www.socialcrawl.dev/v1/facebook/profile/photos" \
  --data-urlencode "url=https://www.facebook.com/Meta" \
  -H "x-api-key: sc_YOUR_API_KEY"
```

## FAQ

### How do I list photos from a Facebook page?

Send a GET request to /v1/facebook/profile/photos with the page url. SocialCrawl returns an array of photos with a photo id, permalink, full-size image URL, thumbnail, and the accessibility caption where Facebook wrote one. Add include=details and the author, reaction count, comment count, share count, and publish time land on every photo in the same call.

### Do I get full-resolution image URLs?

Yes. The response returns Facebook's hosted image URLs at display resolution, the same URLs rendered on the page. Use them directly in an <img> tag, download them for archival, or feed them into image analysis models.

### How do I paginate through all photos on a page?

Pass the cursor (or next_page_id) from the previous response as the next request's cursor parameter. Repeat until cursor is empty to walk the page's entire public photo album.

### Does this include photos from posts with images?

This endpoint returns photos from the page's dedicated photo feed. For photos attached to regular posts, use /v1/facebook/profile/posts. Each post object includes its media attachments inline.

### Can I use these images in my product?

Image URLs are returned as-is from Facebook. Using them commercially requires you to respect Facebook's terms and the original creator's rights. SocialCrawl surfaces the data; licensing and rights clearance is your responsibility.

### How do I get reactions and dates for each photo?

Pass include=details on the same call. Each photo is joined to its own post record, so the page name and avatar, the reaction count, the comment count, the share count, and the publish time land on the row. The page is 1 credit plus 1 credit per photo filled from a fresh lookup, 9 credits at most, with cached photos free and unfilled rows refunded. A photo inside a multi-photo post carries its own counts rather than the parent post's.

See the full Facebook API: https://www.socialcrawl.dev/platforms/facebook

## Pricing

- Standard endpoints: 1 credit per call
- Advanced endpoints: 5 credits per call
- Premium endpoints: 10 credits per call
- 100 free credits on signup, no credit card required. Cached responses cost 0 credits. Credit packs never expire.
- Full pricing: https://www.socialcrawl.dev/pricing

## Explore with AI

Questions this API answers, phrased for an AI assistant:

- How to list Facebook page photos with an API
- Does SocialCrawl return full-resolution Facebook images?
- How to get likes, comments, and dates for Facebook page photos in one call