Skip to main content
POST
Ingest a batch of camera-roll metadata

Authorizations

X-PARTNER-API-KEY
string
header
required

Your FanFeed partner API key, issued to your organization.

FanFeed trusts your authentication: the key identifies you, and the user_id in the path identifies which of your users the request is for. FanFeed performs no end-user authentication of its own.

Treat the key as a server-side secret. See the guide for what that implies for the camera-roll ingest path, which is the one call that naturally originates on-device.

Path Parameters

user_id
string<uuid>
required

The FanFeed user id returned by POST /users.

Example:

"8f14e45f-ceea-467a-9a1e-2b4d9c3f0a11"

Body

application/json
media
object[]
required

Aim for 50–200 items per request. 200 is a hard cap; anything larger returns 413.

Smaller batches are valid and expected: the last batch of a scan is normally short, and a user with only a handful of geotagged photos may never fill one.

Required array length: 1 - 200 elements

Response

Batch processed. Matches are included.

accepted
integer
required

Items in this batch accepted for matching: everything you sent that was not rejected.

Example:

96

matched
integer
required

A subset of accepted: how many of those landed on an event (matched: true with an event_id). The remainder are perfectly good ingested photos that were not taken at a live event.

Example:

8

rejected
object[]
required

Always present. Empty when every item in the batch was accepted. Rejections are per-item and never fail the request.

matches
object[]
required

One entry per accepted item, in no particular order. Resolve by media_id.

events
object[]
required

The distinct events matched in this batch, fully expanded, so you can render newly-found events as the sync progresses without a second call.

last_sync_at
string<date-time>
required

Server-side timestamp of the last time FanFeed received media or a sync-complete for this user, advanced by this batch. It never moves backwards, so the value on any response is the latest mark even when concurrent batches commit out of order.

Example:

"2026-08-25T18:44:12Z"