Events

​

Request

GET /v1/users/{user_id}/events?limit=25
X-PARTNER-API-KEY: <your partner key>

​

Response

{
  "events": [
    {
      "id": 18012359,
      "name": "Zach Bryan",
      "starts_at_local": "2026-06-13T19:30:00",
      "venue": {
        "id": 4412, "name": "Madison Square Garden",
        "city": "New York", "region": "NY", "country": "US",
        "latitude": 40.750504, "longitude": -73.993439
      },
      "performers": [
        { "id": 34421, "name": "Zach Bryan", "category": "Country",
          "image_url": "https://…", "is_headliner": true }
      ],
      "media_count": 12,
      "media": [
        { "media_id": "B84E8479-…/L0/001", "taken_at": "2026-06-14T02:31:07Z", "media_type": "photo" }
      ]
    }
  ],
  "next_cursor": null,
  "has_more": false,
  "total": 47
}

​

Reading it

• Newest first, cursor-paginated. total is the user’s full matched-event count and may be omitted on later pages; page with has_more and next_cursor, not with total.
• media is included and complete, so opening an event detail screen costs no extra request. It is not capped; a heavy event can carry hundreds of entries, so pass include_media=false on views that do not need it. Each entry echoes the thumbnail_url you submitted, when you submitted one.
• media_id echoes the id you originally submitted, so you can resolve each one back to the local asset on the device. FanFeed stores metadata only; it does not host the images. Rendering a photo means loading it from the user’s own camera roll by that id.

• Hidden events. An event hidden from a profile disappears from these responses. If an event vanishes between pages or syncs, this is usually why.
• Events not licensed for redistribution. As in The response: the photos still exist, but the event is never returned.