링크드인 게시물 이력, 프로필 아카이브로 100건씩 끝까지

공개 멤버의 링크드인 게시물 이력은 GET /v1/linkedin/profile/posts/archive(linkedin profile posts archive)로 페이지당 최대 100건씩 받고, 커서가 안 나올 때까지 이어 가요. 이 링크드인 프로필 아카이브의 게시 시각은 밀리초까지 나오고, 과금은 요청 limit이 아니라 온 글 수 × 5예요. 아래 curl과 JSON은 2026-09-08, 공개 멤버 williamhgates로 받은 라이브 응답이에요.

링크드인 아카이브 api는 싼 피드랑 뭐가 다른가요?

최근 한 창이면 싼 피드로 끝나요. 링크드인 아카이브 api는 그 창을 넘기거나 게시 시각을 밀리초로 찍어야 할 때 쓰는 레인이에요. 같은 멤버 williamhgates를 2026-09-08에 두 레인으로 쳤어요. 싼 GET /v1/linkedin/profile/posts?limit=20은 20건, 고정 5크레딧, has_more=false, next_cursor=null이었고 시각은 날짜뿐이었어요. 링크드인 아카이브 api로 넘어가는 이유는 싼 레인을 다시 설명하려는 게 아니에요. 끝까지 읽어야 하거나 정확한 시각이 필요할 때예요.

공식 Open Permission의 w_member_social은 인증 멤버가 글을 쓰는 길이에요. (Getting Access, Share on LinkedIn) 임의 공개 프로필 URL을 끝까지 읽는 권한은 Open Permission이 아니에요. 권한 표와 프로필·회사 개관은 링크드인 api에 있어요.

링크드인 프로필 포스트 전체는 페이지당 몇 건인가요?

페이지당 최대 100건이에요. 한 번에 최신 N건만 보고 싶으면 limit을 줄이면 돼요. 다만 그 페이지에는 커서가 안 붙어서 다음으로 이어 갈 수 없어요. 링크드인 프로필 포스트 전체를 걷으려면 페이지를 가득 채워야 커서가 붙어요. 이번 하베스트에서 링크드인 프로필 포스트 전체를 limit=5로 치니 5건, 25크레딧(5 × 5)이 나왔고 has_more=false, next_cursor=null, page_size=5였어요. 게시 시각은 자정이 아니라 2026-09-05T19:09:50.123Z예요.

curl -s -H "x-api-key: $SOCIALCRAWL_API_KEY" -H "Cache-Control: no-cache" \
  "https://www.socialcrawl.dev/v1/linkedin/profile/posts/archive?url=https://www.linkedin.com/in/williamhgates/&limit=5"

HTTP 200, request_id req-pq0QiJ0yYh8J765b. 아래는 5건 중 앞 2개만 남긴 응답이에요.

{
  "success": true,
  "platform": "linkedin",
  "endpoint": "/v1/linkedin/profile/posts/archive",
  "credits_used": 25,
  "cached": false,
  "pagination": { "next_cursor": null, "has_more": false, "page_size": 5 },
  "data": {
    "dropped": 0,
    "items": [
      {
        "post": {
          "id": "7502080571335155713",
          "published_at": "2026-09-05T19:09:50.123Z",
          "author": { "username": "williamhgates", "display_name": "Bill Gates" },
          "engagement": { "views": null, "likes": 1741, "comments": 437, "shares": 86, "saves": null },
          "ext": { "published_at_epoch": 1788635390123, "post_type": "regular" }
        }
      },
      {
        "post": {
          "id": "7501738402128715777",
          "published_at": "2026-09-04T20:30:10.627Z",
          "author": { "username": "williamhgates", "display_name": "Bill Gates" },
          "engagement": { "views": null, "likes": 6870, "comments": 668, "shares": 595, "saves": null },
          "ext": { "published_at_epoch": 1788553810627, "post_type": "regular" }
        }
      }
    ]
  }
}

유료 호출마다 Cache-Control: no-cache를 붙였고, 전부 X-Cache: MISS였어요. 이 헤더 없이 치면 10분 캐시 히트에 credits_used=0일 수 있어요. limit=5라 커서가 없다는 건 문서 문구가 아니라, 이번 하베스트에서 실제로 나온 값이에요.

링크드인 포스트 페이지네이션에서 커서가 없으면 이력이 끝난 건가요?

커서가 없고 has_more가 false면 그 멤버가 쓴 공개 글의 끝이에요. 링크드인 포스트 페이지네이션을 items.length === 100으로 멈추면 안 돼요. 이번 실행은 limit=100을 요청해 97건을 받았고, 크레딧은 485(5 × 97)였어요. pagination.has_more는 true였고, next_cursor는 sc. 접두 257자, page_size는 97이었어요. 100을 요청해도 97만 오고 커서가 남을 수 있어요. 멈출 때는 pagination.has_more가 false일 때예요.

curl -s -H "x-api-key: $SOCIALCRAWL_API_KEY" -H "Cache-Control: no-cache" \
  "https://www.socialcrawl.dev/v1/linkedin/profile/posts/archive?url=https://www.linkedin.com/in/williamhgates/&limit=100"

첫 id는 7502080571335155713 (2026-09-05T19:09:50.123Z), 마지막 id는 7454604928066486273 (2026-04-27T18:58:34.713Z)예요. post_type은 regular 80건, quote 17건이고, 작성자 97행이 전부 williamhgates예요. 호출에 걸린 시간은 2026-09-08T00:19:02Z부터 00:19:08Z까지 약 5.8초예요. request_id는 req-2etbGBAiw3xDCQk9예요. 아래는 페이지네이션 객체와 앞 2개, 마지막 1개만 남긴 응답이에요. items_count 같은 키는 응답에 없어요.

{
  "success": true,
  "endpoint": "/v1/linkedin/profile/posts/archive",
  "credits_used": 485,
  "cached": false,
  "pagination": {
    "next_cursor": "sc.eyJ2IjoyLCJjIjoic2MyLmV5SnpJam9pZGlJc0ltTWlPaUprV0VwMVQyMTRjRTl0Um1wa1Iyd3lZVmhTTlU5cVl6Qk9WRkV5VFVSUk5VMXFaM2RPYWxrd1QwUlplVTU2VFhSTlZHTXpUbnBOZUU1cVRYaE9SRmsxVGxFOVBTSjkiLCJlIjoibGlua2VkaW4vcHJvZmlsZS9wb3N0cy9hcmNoaXZlIiwicCI6InBhZ2luYXRpb25fdG9rZW4ifQ",
    "has_more": true,
    "page_size": 97
  },
  "data": {
    "dropped": 0,
    "items": [
      {
        "post": {
          "id": "7502080571335155713",
          "published_at": "2026-09-05T19:09:50.123Z",
          "author": { "username": "williamhgates" },
          "engagement": { "likes": 1741, "comments": 437, "shares": 86 },
          "ext": { "published_at_epoch": 1788635390123, "post_type": "regular" }
        }
      },
      {
        "post": {
          "id": "7501738402128715777",
          "published_at": "2026-09-04T20:30:10.627Z",
          "author": { "username": "williamhgates" },
          "engagement": { "likes": 6870, "comments": 668, "shares": 595 },
          "ext": { "published_at_epoch": 1788553810627, "post_type": "regular" }
        }
      },
      {
        "post": {
          "id": "7454604928066486273",
          "published_at": "2026-04-27T18:58:34.713Z",
          "author": { "username": "williamhgates" },
          "engagement": { "likes": 1421, "comments": 130, "shares": 54 },
          "ext": { "published_at_epoch": 1777316314713, "post_type": "quote" }
        }
      }
    ]
  }
}

이번 97건은 1페이지일 뿐이에요. 2페이지는 따라가지 않았어요. 다음 호출은 pagination.next_cursor를 pagination_token으로 넘기면 돼요. 그 응답 JSON은 이번 실행에 없어요.

2026-09-07 측정 워크의 페이지당 소요 시간은 약 5초고, 18페이지도 1페이지와 비슷해요. 이번 1페이지 5.8초와 어긋나지 않아요. 링크드인 포스트 페이지네이션에 고정 깊이는 없어요. 커서가 없는 페이지가 그 멤버 공개 이력의 끝이에요.

링크드인 공유 수 api 응답의 시각은 왜 밀리초인가요?

아카이브는 상대 라벨이 아니라 실제 시각을 밀리초로 찍어요. 같은 글이 싼 레인에서는 2026-09-06T00:00:00.000Z(precision=day), 아카이브에서는 2026-09-05T19:09:50.123Z(epoch=1788635390123)로 찍혀요. 날짜가 하루 어긋나요. 싼 레인은 상대 라벨을 다시 계산하거든요. 공식 파트너 스키마의 게시 시각도 에포크 밀리초예요. (Post schema)

레인마다 id 필드가 달라요. 싼 레인은 ugcPost처럼 보이는 7502080570181586944, 아카이브는 activity 7502080571335155713예요. 싼 레인 URL 안에 아카이브 id가 activity URN으로 들어 있어요. 같은 글이에요.

링크드인 공유 수 api의 engagement.shares 필드는 아카이브 limit=100 페이지 97행 전부에 숫자로 있었어요. 같은 날 싼 피드 20행에도 숫자 shares가 있었어요. 아카이브만 공유 수를 주는 건 아니에요. 아카이브가 여기서 보여 준 건 밀리초 시각이에요. 커서가 이어지고, 싼 창보다 더 깊이 가요. views와 saves는 이번 아카이브 행 전부 null이었어요.

2026-09-08 하베스트에서 같은 limit=5를 no-cache로 74초 간격 두 번 쳤고, 둘 다 X-Cache: MISS였어요. 다섯 id의 published_at이 밀리초까지 같았어요.

게시 시각이 호출마다 흔들리면 올리기 좋은 시간 차트도 못 그려요. (링크드인에 올리기 좋은 시간)

링크드인 활동 아카이브에 다른 사람 글 리셰어가 왜 없나요?

링크드인 활동 아카이브는 그 멤버가 쓴 글만 돌려줘요. 다른 사람 글 리셰어는 버리고 과금하지 않아요. 이번 하베스트에서 100을 요청해 97이 왔고 data.dropped는 0이었어요. dropped는 스키마 수리 손실이지 리셰어 카운터가 아니에요. 3건 부족은 그 정책과 맞지만, 빠진 행을 검사하지 못했어요.

링크드인 활동 수집의 과금은 전달된 글 수 × 5예요. 요청 limit이 아니에요. limit=101은 HTTP 400 INVALID_REQUEST, 크레딧 0이었어요. 메시지에 한도가 적혀 있어요. (잘못된 요청) 가짜 프로필은 404가 아니라 HTTP 200이고, 빈 리스트에 크레딧 0이었어요.

limit=101 응답이에요. request_id req-5f79V4LhCyjNSZKX.

{
  "success": false,
  "error": {
    "type": "INVALID_REQUEST",
    "message": "Invalid value for 'limit': '101'. Must be an integer >= 1 and <= 100.",
    "status": 400,
    "doc_url": "https://www.socialcrawl.dev/docs/errors#invalid-request"
  },
  "credits_used": 0,
  "request_id": "req-5f79V4LhCyjNSZKX"
}

가짜 URL은 https://www.linkedin.com/in/this-profile-does-not-exist-zzz999/예요. request_id req-UoV4dWgSvJ9sOGDX.

{
  "success": true,
  "platform": "linkedin",
  "endpoint": "/v1/linkedin/profile/posts/archive",
  "data": { "items": [], "total": 0, "dropped": 0 },
  "credits_used": 0,
  "cached": false,
  "pagination": { "next_cursor": null, "has_more": false, "page_size": 0 },
  "request_id": "req-UoV4dWgSvJ9sOGDX"
}

링크드인 활동 아카이브는 공개 멤버만 대상이에요. 비공개·로그인 전용 활동은 이 엔드포인트 밖이에요. 공개로 보이는 글이라고 API 접근 권한이 생기는 건 아니에요. (User Agreement)

어떻게 시작하나요?

1. SocialCrawl 키를 받아요.
2. 아카이브 크레딧을 쓰기 전에 싼 GET /v1/linkedin/profile/posts?url=…&limit=20을 쳐 보세요. 이번 멤버는 20건, 고정 5크레딧, has_more=false였어요. 싼 레인은 항상 한 페이지라서, 20을 꽉 채우면 창이 잘렸을 수 있어요. limit=100도 크레딧은 같아요. 최근 창만 필요하면 여기서 끝나요. 계약은 링크드인 포스트 API에 있어요.
3. 가장 작은 아카이브는 위의 limit=5 curl이에요. 기대값은 5건, 25크레딧, 커서 없음이에요.
4. 커서를 보려면 limit=100 한 번이에요. 이번 실행은 97건, 485크레딧, has_more=true였어요. 나머지가 필요하면 pagination_token을 has_more가 false일 때까지 넘기면 돼요.
5. 코드 한 줄 쓰기 전에 데이터를 먼저 확인해 보세요. 계약은 링크드인 엔드포인트 문서에 있어요.

williamhgates는 재현용 공개 멤버예요. 공개 프로필만 이 링크드인 프로필 아카이브 범위예요.

자주 묻는 질문

링크드인 프로필 아카이브는 글당 크레딧이 어떻게 되나요?

전달된 글 수 × 5예요. 요청 limit이 아니에요. 이번 하베스트는 limit=5가 5건·25크레딧, limit=100인데 97건이 와서 485크레딧이었어요. 500이 아니에요.

빈 프로필을 아카이브로 치면 과금되나요?

빈 리스트, HTTP 200, 0크레딧이에요. 가짜 URL https://www.linkedin.com/in/this-profile-does-not-exist-zzz999/로 실측했어요. 404가 아니에요.

limit을 100보다 크게 보내면 어떻게 되나요?

HTTP 400 INVALID_REQUEST이고, 메시지에 한도가 적혀 있으며 크레딧은 0이에요. limit=101로 실측했어요. 에러 코드는 잘못된 요청에 있어요.

정확한 게시 시각은 호출마다 안 흔들리나요?

아카이브는 밀리초예요. 같은 5개 id를 no-cache로 74초 간격 두 번 쳤더니 밀리초까지 같았어요. 다른 링크드인 피드는 상대 라벨에서 다시 계산해서 날짜가 어긋날 수 있어요. 같은 글이 싼 레인에서는 6일 자정, 아카이브에서는 5일 19:09:50 UTC였어요.

싼 프로필 피드로 먼저 가도 되나요?

대부분 멤버는 /profile/posts 한 창이면 끝나요. 싼 레인은 항상 한 페이지예요. 이번 멤버 limit=20은 20건이 꽉 찼고, 아카이브 1페이지가 이미 97건이었어요. 싼 레인 계약은 싼 프로필 피드에 있어요. 끝까지 읽거나 정확한 시각이 필요할 때만 아카이브로 가면 돼요.

다른 사람 글을 리셰어한 건 왜 안 오나요?

본인 글만 와요. 리셰어는 버리고 과금하지 않아요. 100을 요청해 97이 온 것은 그 정책과 맞지만, 이번 실행은 빠진 행을 세지 못했어요. dropped=0을 리셰어 카운터로 읽지 마세요.