TikHub API 키·API 문서·GitHub SDK, 단계별로 직접 테스트해 봤습니다

2026년 11월 3일, 저희는 TikHub의 공개 개발자 자료를 모두 내려받아 스크립트로 집계했습니다. openapi.json에는 3.1 MB 분량에 엔드포인트 경로 1,058개가 들어 있으며, 모델이 읽으려면 약 840,000토큰이 필요합니다. 그중 1,052개 엔드포인트는 문서화된 성공 응답이 데이터 필드 없는 범용 래퍼입니다. GitHub에서 TypeScript, Go, Java, C++ SDK의 마지막 커밋은 2025년 3월이었습니다. 이 SDK들은 현재 활성 엔드포인트 1,055개 중 32.3%만 지원합니다. 예외는 Python SDK로, 2.2.0 버전은 99.2%를 지원합니다.

같은 날 밤 EveryInfra로 실제 호출 3건을 보냈습니다. curl, 저희 Python SDK, 원격 MCP 서버를 사용했습니다. TikTok 프로필, Douyin 동영상, Xiaohongshu 노트를 하나씩 읽었고 총비용은 $0.006668였습니다. TikHub 정가로 같은 3건을 읽으면 저희보다 1.8배 비싸므로, 저희가 약 44% 저렴합니다. 다만 일일 호출량이 많은 경우와 문서화되지 않은 Xiaohongshu 엔드포인트 하나를 쓰는 경우에는 TikHub가 더 저렴하며, 두 경우 모두 아래에서 다룹니다.

범위, 출처, 그리고 다른 글과의 차이

TikHub를 다룬 글은 이미 세 편 있습니다. TikHub 대안 글은 전체 지원 범위와 가격을 비교합니다. TikHub 요금 해설은 1,470행짜리 가격표와 무료 크레딧을 분석합니다. TikHub Douyin API 대안은 Douyin 기능 37개의 가격을 하나씩 따져 보며, 요약은 TikHub 대안 페이지에 있습니다. 이 글은 다른 질문에 답합니다. "tikhub api key", "tikhub api doc", "tikhub github"를 검색하는 사람들이 코드를 한 줄 쓰기 전에 알고 싶은 것은 무엇일까요?

키는 어디에 있나요? 인증은 어떻게 하나요? 어떤 문서를 읽어야 하고, 어떤 SDK가 아직 작동하나요? 첫 성공 응답을 받기까지 몇 단계가 걸리나요? 가격은 마지막에 간단한 점검으로만 다룹니다.

TikHub에 대해서는 공개 자료만 사용했습니다. 요금 페이지와 시작하기 페이지, 문서 사이트, openapi.json이 여기에 해당합니다. 키 없이 작동하는 가격표와 데모 엔드포인트, 공개 GitHub 조직, PyPI와 npm 페이지도 포함됩니다. 모든 자료는 2026년 11월 3일 싱가포르 시간 00:15~00:37에 확인했습니다.

TikHub 계정에 가입하지 않았고 유료 TikHub 엔드포인트도 호출하지 않았습니다. 따라서 TikHub의 유료 동작에 관한 내용은 모두 TikHub 자체 문서를 근거로 합니다. EveryInfra 쪽 수치는 모두 같은 30분 동안 보낸 실제 호출에서 나왔습니다. 토큰 수는 내려받은 각 파일에 o200k_base 토크나이저를 적용하는 스크립트로 계산했습니다.

TikHub API 키 발급 방법: 양쪽 모두 네 가지 액션

새 사용자가 가장 먼저 원하는 것은 키입니다. TikHub의 시작하기 페이지 제목은 "First API Call in 4 Steps"입니다. 첫 단계는 회원가입과 이메일 인증입니다. 두 번째는 API 마켓플레이스에서 엔드포인트별 가격과 무료 크레딧 규칙을 살펴보는 것입니다. 세 번째는 유료 엔드포인트를 위해 충전하는 것이고, 네 번째는 코딩을 시작하는 것입니다. 저희는 이 페이지를 한 단어씩 읽었습니다.

네 단계 어디에도 API 키를 만들라는 안내가 없습니다. 키 안내는 문서 사이트의 README - English 페이지 끝, "Get API Token" 섹션에 있습니다. 로그인한 뒤 사용자 센터를 열고 API 토큰 메뉴를 클릭합니다. 그런 다음 토큰을 만들어 요청 헤더에 복사해 넣습니다. 시작하기 페이지만 따라간 독자는 네 단계를 모두 마치고도 키가 어디 있는지 모릅니다.

이메일 인증은 선택 사항이 아닙니다. 튜토리얼 및 FAQ 페이지는 403 응답의 원인 중 하나로 "email is not verified"를 꼽습니다. 같은 페이지에 따르면 사용자 한 명당 API 키를 최대 100개까지 만들 수 있어 프로젝트마다 키를 따로 주기 쉽습니다. 요금 페이지에 따르면 신규 계정은 약 50회 요청에 해당하는 $0.05의 무료 크레딧을 1인당 한 번 받습니다. 삭제했다가 다시 만든 계정은 이를 다시 받지 못합니다.

요금 페이지에는 모든 엔드포인트에서 무료 크레딧을 사용할 수 있는 것은 아니라고도 나와 있어, 일부 엔드포인트는 첫 호출부터 유료 잔액이 필요합니다. 최소 충전 금액은 $5이며 PayPal, Alipay(하루 최대 $250), USDT(네트워크 수수료 별도 부담)로 결제할 수 있습니다. 2026년 7월 20일에 업데이트된 환불 정책에는 "All Sales Are Final"이라고 적혀 있습니다. 환불을 받으려면 엔드포인트가 실제로 작동하지 않아야 하고, TikHub 기술팀이 이를 확인해야 합니다.

함정이 하나 더 있습니다. TikHub에는 두 종류의 키가 있습니다. 소셜 데이터 엔드포인트용 키는 user.tikhub.io의 사용자 센터에서 발급합니다. TikHub는 베타 단계의 AI 프록시 서비스도 운영합니다. 그 AI API 페이지에 따르면 ai.tikhub.io에서 따로 가입하고 그 콘솔에서 키를 만들어야 합니다.

같은 페이지에 따르면 이 프록시는 OpenAI Python SDK, Anthropic SDK, Google AI SDK와 함께 작동하지 않습니다. 일반 HTTP 요청을 보내야 합니다. 한 서비스의 키는 다른 서비스에서 작동하지 않습니다. "tikhub api key"를 검색해 AI 프록시 페이지에 도착했다면, 거기서 만든 키로는 데이터 엔드포인트를 쓸 수 없습니다.

EveryInfra도 네 가지 액션이 필요합니다. GitHub, Google, 전화번호, 이메일 주소 중 하나로 로그인합니다. 콘솔의 API 키 메뉴에서 키를 만들면 전체 키는 한 번만 표시됩니다. 그런 다음 문서에 설명된 대로 Authorization: Bearer 헤더에 담아 보냅니다.

비용 없이 써 보려면 저희 GitHub 저장소 두 개에 스타를 누르고 콘솔에서 $1 체험용 크레딧을 받을 수 있습니다. 유효기간은 24시간입니다. 이 크레딧으로 할 수 있는 호출 횟수는 기능별 가격에 따라 다르며, 아래 무료 크레딧 섹션에서 세 가지 경우를 계산합니다.

스타를 누르고 싶지 않다면 대신 충전할 수 있습니다. 요금 페이지의 최소 충전 금액은 $10입니다. TikHub와 비교하면 저희는 별도 이메일 인증이 없지만, 최소 충전 금액은 TikHub의 $5보다 두 배 큽니다. 첫날 최대한 적게 내고 싶은 사람에게는 TikHub가 더 유리합니다.

팀에게 가장 중요한 행은 키 생성과 키 권한 범위입니다. 사용자당 키 100개는 프로젝트별로 비용을 구분하기에 넉넉합니다. 하지만 TikHub 공개 문서에는 키 하나를 일부 엔드포인트로 제한할 수 있는지가 나와 있지 않습니다. 유일한 단서는 토큰이 "lacks required permissions"인 경우를 다룬 상태 코드 설명입니다. 저희 키는 콘솔에서 제품 단위로 제한할 수 있습니다.

예를 들어 AI 에이전트에게 데이터 API는 열어 주고 CAPTCHA 해결은 닫아 둘 수 있습니다. 키를 비활성화해 모든 호출이 401을 반환하게 할 수도 있습니다. 키 권한 범위 변경, 한도 상향, 결제는 항상 콘솔에 로그인한 사람이 해야 합니다. API로 만든 키는 그 키를 만든 키보다 넓은 권한을 가질 수 없습니다. 따라서 키를 가진 AI 에이전트가 그 키로 계정을 변경할 수는 없습니다.

인증: Bearer 헤더, 쿠키, URL에 담긴 키

두 서비스 모두 Authorization: Bearer <key>를 사용합니다. 이 형식은 RFC 6750에서 왔습니다. 이 표준의 2.3절은 URL 쿼리에 담은 토큰을 "SHOULD NOT be used"라고 규정합니다. 5.3절은 두 가지를 덧붙입니다. 브라우저 기록과 서버 로그에 남을 수 있으므로 bearer 토큰을 페이지 URL에 넣지 말아야 합니다. 평문으로 전송될 수 있는 쿠키에 저장해서도 안 됩니다.

TikHub README는 두 가지 방법을 제시합니다. 방법 1은 헤더이며 권장 방법입니다. 방법 2는 Authorization이라는 이름의 쿠키로, "권장하지 않으며 방법 1을 쓸 수 없을 때만 사용"이라고 표시되어 있습니다. Swagger 페이지에도 알아 둘 세부 사항이 하나 있습니다. 오른쪽 위의 Authorize를 클릭하면 Bearer 접두사 없이 토큰만 붙여 넣어야 합니다. 접두사는 페이지가 알아서 붙입니다.

인증에 실패했을 때 서비스가 무엇을 반환하는지는 문서보다 많은 것을 알려 줍니다. 문제가 생기면 AI 에이전트가 볼 수 있는 것은 응답 본문뿐입니다. 싱가포르 시간 00:19:39에 키 없이 TikHub의 TikTok 프로필 엔드포인트를 호출했습니다. 0.21초 만에 401이 돌아왔습니다.

응답 헤더에는 WWW-Authenticate: Bearer가 있었으며, 이는 RFC 9110 15.5.2절이 401 응답에 요구하는 사항입니다. 본문의 message는 README의 "api-token-introduction" 앵커를 가리켰습니다. 같은 메시지의 중국어 버전과 Discord 링크도 있었습니다. docs 필드는 null이었고, 시간은 로스앤젤레스 시간대로 표시되었습니다.

싱가포르 시간 00:18:54에 키 없이 EveryInfra를 호출했습니다. 401과 함께 코드 missing_key, fault: account, retryable: false가 반환되었습니다. next_steps 필드는 호출자에게 Authorization 헤더에 키를 넣으라고 안내했고, 비용이 청구되지 않았다고 알렸습니다. 저희 응답 헤더에는 WWW-Authenticate가 없으므로, 이 점에서는 TikHub가 표준을 더 충실히 따릅니다.

더 흔한 실수는 잘못된 파라미터입니다. 싱가포르 시간 00:19:24에 username 대신 user로 tiktok/profile을 보냈습니다. EveryInfra는 422 missing_param을 반환하고 누락된 필드로 username을 지목했습니다. user는 이 기능의 파라미터가 아니라고 알려 주고, 작동하는 예시와 해당 플랫폼의 카탈로그 주소를 함께 보냈습니다.

TikHub의 openapi.json에서는 엔드포인트 973개가 422 검증 오류를 선언하며, 문서화된 형식은 해당 웹 프레임워크의 기본 필드 검증 메시지입니다. TikHub 키가 없어서 파라미터 이름을 잘못 썼을 때 실제로 어떻게 응답하는지는 확인하지 못했습니다. 비교는 여기까지만 하겠습니다.

키를 Git, 로그, 채팅 기록에 남기지 않는 방법

키를 받은 뒤 흔히 일어나는 사고는 낯선 사람이 키를 알아맞히는 일이 아닙니다. 본인이 저장소, 스크린샷, AI 도구와의 채팅에 키를 붙여 넣는 일입니다. GitHub의 지원 패턴 목록은 시크릿 스캐닝 규칙을 일반 규칙, AI 탐지 시크릿, 제공업체 규칙의 세 그룹으로 나눕니다. 11월 3일 기준 목록에는 제공업체 규칙이 531개 있었습니다.

여기서 가장 중요한 것은 일반 규칙 하나입니다. 이름은 http_bearer_authentication_header이며, 코드에 작성된 Authorization: Bearer 헤더를 찾습니다. GitHub는 이 규칙의 정밀도를 중간으로 평가합니다. 따라서 헤더와 함께 커밋한 키는 발견될 가능성이 있습니다. 하지만 GitHub 파트너 프로그램에 속한 제공업체만 보고를 받고 키를 대신 폐기할 수 있습니다. 그 밖의 경우에는 콘솔에서 직접 키를 비활성화해야 합니다.

2026년 10월 28일에 GitHub는 푸시 보호에 AI 탐지 시크릿을 추가했습니다. 새 검사는 정해진 키 형식이 필요 없습니다. 변수 이름, 파일 경로, 주변 코드를 살펴봅니다. 초기 결과에서는 푸시 보호가 막은 푸시 수가 두 배 이상으로 늘었습니다.

다만 기본적으로 꺼져 있습니다. 먼저 AI 탐지 시크릿과 푸시 보호를 켜야 합니다. Secret Protection 또는 Advanced Security 비용을 내는 조직만 쓸 수 있으며, AI 크레딧을 소모합니다. 대부분의 1인 개발자는 여전히 다음 세 가지 습관으로 두 서비스 모두에서 키를 보호할 수 있습니다.

키는 환경 변수나 클라이언트의 시크릿 설정에 보관하세요. MCP 설정에는 키 자체 대신 ${EVERYINFRA_API_KEY} 같은 참조를 쓰세요. 프로젝트마다 별도 키를 주면 유출되었을 때 모든 키가 아니라 키 하나만 비활성화하면 됩니다. TikHub의 사용자당 100개 키 한도 덕분에 마지막 습관은 실천하기 쉽습니다. 저희 콘솔에서도 키를 여러 개 만들고, 키마다 IP 허용 목록을 추가하고, 그 키에 필요 없는 제품을 끌 수 있습니다.

두 서비스 모두 여전히 더 약한 방식 하나를 허용합니다. TikHub는 Authorization이라는 쿠키로 토큰을 받으며, 권장하지 않는다고 표시합니다. RFC 6750 5.3절에 따르면 쿠키에 담은 토큰은 사이트 간 요청 위조에 대한 보호가 필요합니다. 평문으로 전송될 수 있는 쿠키에 담아 보내서도 안 됩니다. 저희 쪽에서는 초기 MCP 커넥터가 URL 쿼리에 키를 넣을 수 있었습니다.

저희 문서에는 이 방식이 아직 작동하지만 URL은 기록과 로그에 남으므로 새 설정에서는 쓰지 말라고 안내합니다. 저희 AI 엔드포인트는 URL에 담긴 키를 아예 거부합니다. RFC 6750은 쿼리 토큰에 대해 "SHOULD NOT"이라고 규정합니다. 현재 두 서비스 모두 헤더를 권장하므로 이 점에서는 같습니다.

TikHub 공개 문서는 키 하나를 비활성화하거나 교체하는 방법을 설명하지 않고, 401의 원인 여섯 가지만 나열합니다. 저희 쪽에서는 비활성화된 키가 401을 반환하며, 콘솔에 로그인한 사람만 다시 활성화하거나 교체할 수 있습니다.

키를 받기 전에 할 수 있는 일

두 서비스 모두 가입 전에 둘러볼 수 있습니다. TikHub에는 데모 엔드포인트가 8개 있습니다. 문서 사이트에는 항목이 9개 있는데, 아홉 번째는 데모 캐시 상태를 보여 줍니다. 데모 엔드포인트는 토큰이 필요 없고, 고정된 객체를 반환하며, 이를 1시간 동안 캐시합니다. 고정된 Douyin 웹·앱 동영상, Douyin 검색, 고정된 Kuaishou 동영상을 다룹니다. 고정된 TikTok 사용자, 고정된 TikTok 앱 동영상, 고정된 Instagram 사용자, WeChat 기사 추출기도 있습니다.

싱가포르 시간 00:19:38에 고정된 TikTok 사용자 데모를 호출했습니다. 0.65초 만에 200과 함께 tiktok 계정 정보를 반환했습니다. 팔로워 96,500,000명, 동영상 1,514개였고, statsV2에는 정확한 팔로워 수 96,519,349명이 있었습니다. 키 없이도 실제 응답 형태를 볼 수 있으니 좋은 설계입니다. 다만 헷갈리는 부분이 하나 있습니다.

데모 응답에는 "Request successful. This request will incur a charge."라고 적혀 있습니다. 토큰을 보내지 않았으니 과금될 수 없습니다. 모든 엔드포인트가 하나의 응답 모델을 공유하고 이 문장이 그 모델의 기본 문구이기 때문일 가능성이 높습니다.

EveryInfra에는 데모 엔드포인트가 없습니다. 대신 기능 카탈로그, 검색 도구 목록, CAPTCHA 유형 목록, MCP tools/list 메서드를 모두 키 없이 쓸 수 있습니다. 카탈로그의 각 항목에는 필수·선택 파라미터, 호출당 최대 행 수, price_usd, available, response_fields가 나와 있습니다. 따라서 무엇이든 호출하기 전에 받게 될 필드 이름과 호출당 비용을 알 수 있습니다.

싱가포르 시간 00:21:11에 키 없이 https://api.everyinfra.com/mcp로 tools/list를 보냈고, 도구 12개가 반환되었습니다. 두 방식은 강점이 다릅니다. TikHub의 데모는 실제 응답 하나가 어떻게 생겼는지 보여 줍니다. 저희 카탈로그는 첫 호출 전에 모든 필드 이름과 가격을 알려 줍니다.

무료 크레딧으로 몇 번이나 시험해 볼 수 있을까

"무료 크레딧이 있나요?" 다음에 오는 진짜 질문은 "필요한 엔드포인트마다 몇 번씩 시험해 보기에 충분한가요?"입니다. 저희는 양쪽 체험용 크레딧을 이 글의 세 시나리오 가격으로 나눴습니다. TikHub는 $0.05를 주며, 가격표 1,472행 중 631행(42.9%)에서 무료 크레딧을 사용할 수 있습니다. TikHub 문서에서 권장하는 Xiaohongshu 노트 엔드포인트에는 사용할 수 없습니다. 이 시나리오에서는 무료 크레딧으로 호출을 한 번도 할 수 없고, 먼저 $5를 충전해야 합니다. 저희 저장소에 스타를 눌러 받는 $1 체험용 크레딧은 CAPTCHA 해결을 제외한 모든 기능에 쓸 수 있지만 24시간 후 만료됩니다.

이 표가 단순히 "저희 체험이 더 후하다"는 뜻은 아닙니다. TikHub의 $0.05는 만료일이 명시되어 있지 않아, 지금 가입하고 다음 주에 테스트할 사람에게 맞습니다. 저희의 $1 체험용 크레딧은 하루 안에 써야 하므로, 오늘 바로 작동하는 흐름을 만들고 싶은 사람에게 맞습니다.

양쪽 모두 호출 횟수는 가격에 따라 달라집니다. TikHub에서는 같은 $0.05로 $0.01짜리 엔드포인트를 5회만 호출할 수 있고, 무료 크레딧을 사용할 수 없는 엔드포인트는 한 번도 호출할 수 없습니다. 저희 쪽에서는 TikTok 프로필처럼 $0.000556인 기능은 1,800회 가까이, Xiaohongshu 노트는 179회 호출할 수 있습니다. 직접 추정하려면 카탈로그의 price_usd로 나누거나, 저희 명령줄 도구를 --dry-run으로 실행해 추정치를 확인하세요.

TikHub API 문서는 어디에 있나: 진입점 다섯 곳과 840,000토큰짜리 파일

TikHub 문서에는 서로 많이 겹치는 진입점이 다섯 곳 있습니다. 호스팅형 API 문서 도구로 만든 docs.tikhub.io 문서 사이트가 있으며, 엔드포인트마다 페이지가 하나씩 있고 Markdown 내보내기를 지원합니다. api.tikhub.io의 Swagger 페이지에서는 토큰을 붙여 넣고 브라우저에서 호출을 시험할 수 있습니다. 메인 사이트에는 API 레퍼런스 페이지와 튜토리얼 페이지가 있습니다. AI용으로는 llms.txt와 llms-full.txt가 있습니다. 모두 하나의 openapi.json에서 만들어지며, Postman이나 SDK 생성기로 가져오는 파일도 이것입니다.

openapi.json에 대해 알아 둘 점이 세 가지 있습니다. 첫째, info 블록에는 버전 V5.3.2와 업데이트 시각 2026년 6월 22일이 적혀 있지만 경로 수는 계속 바뀝니다. Python SDK가 10월 3일에 동기화했을 때는 경로가 1,050개였습니다. 저희가 센 결과는 2026년 11월 2일에 1,056개, 2026년 11월 3일에 1,058개였고, 버전 번호는 바뀌지 않았습니다. 버전 번호로 명세 변경 여부를 판단하면 잘못된 결론을 내리게 됩니다.

둘째, 1,058개 엔드포인트 중 1,052개는 성공 응답이 하나의 범용 ResponseModel을 가리킵니다. 이 모델은 code, message, request_id, time_zone, cache_url 같은 래퍼 필드를 정의하며, data의 타입은 "any"입니다. 즉, 명세는 요청 방법을 알려 주지만 어떤 필드가 돌아오는지는 알려 주지 않으므로, 필드는 호출해 봐야 알 수 있습니다. 셋째, 파일이 큽니다. 약 840,000토큰으로 저희 전체 카탈로그(240,429토큰)의 3.5배입니다. 어떤 AI 에이전트도 이를 설명서처럼 통째로 읽을 수는 없습니다.

다른 개발자들도 같은 크기 문제를 겪었습니다. 한 개발자는 TikHub의 openapi.json을 Claude Code 스킬로 바꾸는 방법에 관한 공개 가이드(중국어)를 썼고, 코드는 GitHub에 있습니다. 엔드포인트 위에 검색 계층을 만드는 방식입니다. 그러면 모델은 파일 전체를 읽지 않고 필요한 것만 찾아봅니다. 이는 수요가 실제로 있다는 뜻입니다. 엔드포인트가 많은 서비스일수록 "먼저 찾고, 그다음 호출하는" 인덱스가 더 필요합니다.

TikHub 자체의 해법은 플랫폼마다 MCP 서버를 하나씩 두는 것이며, 아래에서 다룹니다. 저희 해법은 필터를 지원하는 카탈로그입니다. GET /api/v1/social/catalog?platform=tiktok&compact=1은 설명 없이 TikTok만 6,809바이트, 1,870토큰으로 반환합니다. TikHub 엔드포인트 페이지 하나보다 작습니다.

문서 사이트에는 작은 함정이 하나 더 있습니다. 메뉴의 세 번째 항목은 "Getting Started"이지만, 실제로는 TikHub 마켓플레이스에서 판매하려는 판매자를 위한 가이드입니다. 상점 개설, 디지털 상품 판매, 1% 출금 수수료를 설명합니다. API 호출과는 관련이 없습니다. 개발자용 시작하기 페이지는 문서 사이트가 아니라 메인 사이트의 tikhub.io/getting-started에 있습니다. "tikhub api doc" 검색으로 문서 사이트에 들어와 메뉴를 순서대로 클릭한 독자는 관련 없는 페이지부터 읽게 됩니다.

가격표와 문서가 맞지 않는 것도 길을 잃게 만드는 원인입니다. TikHub 가격표는 토큰 없이 볼 수 있습니다. 싱가포르 시간 00:19:39 기준 1,472행, 고유 경로로는 1,471개였습니다. 저희는 같은 시각의 openapi.json과 경로를 하나씩 비교했습니다.

1,038개 경로는 양쪽에 모두 있고, 433개는 가격표에만, 20개는 문서에만 있습니다. 가격표에만 있는 433개 엔드포인트는 가격은 있지만 파라미터 문서가 없습니다. 대부분 구버전으로 보이지만 전부는 아닙니다. 가격 섹션에서 보듯 가장 저렴한 Xiaohongshu 노트 엔드포인트도 여기에 속합니다.

EveryInfra의 진입점은 더 적습니다. /docs는 사람을 위한 가이드입니다. 기능 카탈로그와 압축 버전은 프로그램과 AI 에이전트용입니다. OpenAPI 파일은 버전 2.0.0이며 경로가 59개입니다. 모든 데이터 기능은 하나의 POST /api/v1/social을 거치며, platform과 action 두 필드로 선택합니다.

25,845바이트짜리 llms.txt도 있고, TikTok 프로필 API처럼 플랫폼별·기능별 문서 페이지도 있습니다. 카탈로그의 573개 기능 모두 response_fields를 제공하므로 호출 전에 필드 이름과 타입을 볼 수 있습니다. 저희의 약점은 같은 설계의 이면입니다. 573개 기능이 엔드포인트 하나 뒤에 있으므로 일반 OpenAPI 생성기로는 post(body) 메서드 하나만 만들어집니다. 파라미터 자동 완성은 저희 자체 SDK에 의존하며, 이는 다음 섹션에서 다룹니다.

AI 에이전트에 문서를 맡기면 첫 호출 전까지 얼마나 읽어야 할까

이제 많은 개발자가 API 문서를 직접 읽지 않습니다. Claude Code, Cursor 같은 코딩 에이전트에 문서를 읽고 호출 코드를 작성하게 합니다. 그러면 문서 크기가 곧 컨텍스트 공간이자 비용이 됩니다. 그래서 "TikTok 프로필 엔드포인트를 찾아 첫 요청을 작성한다"는 작업 하나를 정해, 공개 자료를 바탕으로 양쪽에서 가장 적게 읽는 경로를 계산했습니다. 모든 토큰 수는 2026년 11월 3일 싱가포르 시간 00:16~00:23에 내려받은 원본 파일에 o200k_base를 적용한 스크립트로 산출했습니다.

TikHub 쪽에서 가장 적게 읽는 경로는 두 단계입니다. 에이전트는 문서 사이트의 llms.txt 인덱스(1,274줄, 약 47,604토큰)를 읽고 TikTok 웹 "get user profile" 엔드포인트 항목을 찾은 다음, 해당 엔드포인트의 Markdown 페이지(약 2,295토큰)를 엽니다. 합계는 약 49,899토큰입니다. 메인 사이트의 llms.txt는 1,279토큰에 불과하지만 엔드포인트가 아니라 플랫폼과 링크만 나열하므로, 에이전트는 결국 문서 사이트로 가야 합니다.

약 839,775토큰에 달하는 전체 openapi.json을 어떤 에이전트에게든 읽게 하는 것은 비현실적입니다. TikHub의 MCP 서버도 또 다른 경로입니다. TikTok 서버에는 도구가 163개 있으므로, 연결된 모델은 도구 설명 163개를 받습니다. 도구 목록을 조회하려면 인증 토큰이 필요해서 그 크기는 측정하지 않았습니다.

EveryInfra 쪽에서 가장 적게 읽는 경로는 한 단계입니다. GET /api/v1/social/catalog?platform=tiktok&compact=1 하나로, 6,809바이트, 약 1,870토큰입니다. 여기에는 모든 TikTok 기능의 파라미터, 가격, 응답 필드 이름이 들어 있어 요청을 작성하기에 충분합니다. 이 경로에서 TikHub의 읽기 부담은 저희의 약 26.7배입니다. 이 비율은 엔드포인트 하나를 위해 에이전트가 읽어야 하는 양을 잰 것이며, 문서의 품질을 잰 것은 아닙니다.

TikHub의 엔드포인트 페이지에는 2개 언어로 된 설명과 자세한 파라미터 예시가 있습니다. 저희 압축 카탈로그는 설명을 빼고 이름만 남기므로 읽는 비용은 적지만 그만큼 간소합니다. 두 서비스 모두 AI 독자를 위한 llms.txt를 공개합니다. 이 방식은 llms.txt 제안에서 나왔습니다. 이 제안은 세부 내용을 링크 뒤에 두는 짧은 Markdown 인덱스를 권장하며, 두 서비스 모두 이를 따릅니다.

TikHub GitHub: 공개 저장소 12개를 하나씩 확인해 보니

싱가포르 시간 00:16 기준 TikHub GitHub 조직에는 공개 저장소가 12개 있었습니다. GitHub API로 저장소별 스타 수와 마지막 푸시 시각을 읽었습니다. 그런 다음 SDK와 플러그인 저장소 6개를 클론했습니다. 스크립트로 소스에 하드코딩된 /api/v1/... 엔드포인트 경로를 모두 추출해 그날의 openapi.json과 비교했습니다.

Python SDK는 조직에서 가장 잘 관리되는 저장소이며, 먼저 이 점을 인정해야 합니다. 10월 2일(태평양 시간) 커밋의 메시지는 "sync SDK to live OpenAPI spec, skip deprecated endpoints (1048 endpoints)"이고, 다음 날 PyPI에 버전 2.2.0이 배포되었습니다. 여기서 추출한 경로 1,048개는 모두 현재 문서에 남아 있으며, 사라진 경로는 하나도 없습니다. 동기·비동기 클라이언트, 자동 재시도, 요청 속도 제한 처리를 제공하고, mypy --strict를 통과하며, README는 영어, 중국어, 프랑스어, 스페인어, 일본어로 제공됩니다.

빠진 것은 10월 3일 이후 추가된 엔드포인트 9개뿐입니다. Bilibili 게시물 댓글 엔드포인트 1개, LinkedIn 비동기 작업 엔드포인트 5개, Threads 신규 엔드포인트 2개, TikTok Shop 베스트셀러 목록 1개입니다. 엔드포인트가 한 달에 약 9개씩 늘어나므로, 다음 동기화 전까지는 늘 조금씩 뒤처질 수밖에 없습니다.

나머지 4개 언어는 훨씬 더 뒤처져 있습니다. TypeScript, Go, Java, C++ SDK는 2025년 3월 OpenAPI 명세로 생성된 뒤 바뀌지 않았습니다. 소스에 있는 경로 586개(Go는 588개) 중 245개(Go는 247개)는 더 이상 문서에 없습니다. 이 메서드를 호출하면 404나 다른 오류가 반환됩니다. 남은 341개는 현재 엔드포인트의 32.3%에 해당합니다. TypeScript SDK에는 더 직접적인 문제가 있습니다.

npm에서 패키지 이름은 @tikhubio/tikhub-api-ts-sdk이고 최신 버전은 1.0.1입니다. 그런데 npm 페이지의 설치 명령어 두 개는 모두 @tikhub/tikhub-api-ts-sdk로 되어 있습니다. 싱가포르 시간 00:36에 npm 레지스트리를 조회하니 이 이름은 404를 반환했으므로, 명령어를 그대로 복사하면 설치에 실패합니다. GitHub README의 명령어는 올바릅니다.

Python SDK의 PyPI 페이지에는 그보다 작은 실수가 있습니다. "Homepage" 링크가 TikHub-API-Python-SDK-V2를 가리키는데, 이 주소도 404를 반환합니다. README에는 여전히 버전 2.1.1로 적혀 있지만 PyPI의 버전은 2.2.0입니다.

나머지 저장소에도 각자 쓰임새가 있습니다. TikHub-API-Demo에는 2024년 12월에 작성된 예제 스크립트가 Douyin, Instagram, Kuaishou, TikTok별로 정리되어 있습니다. TikHub-Multi-Functional-Downloader는 사용자 인터페이스를 갖춘 데스크톱 다운로더로, 스타 193개를 받아 Python SDK 다음으로 스타가 많은 저장소입니다. tikhub-mcp-dist는 MCP 서버를 로컬에서 실행하려는 사용자를 위한 저장소입니다.

TikHub_n8n_Integration은 n8n에 TikHub 노드를 추가하며, 마지막 푸시는 393일 전입니다. TikHub 공식 계정은 Reddit에 Claude, n8n, TikHub를 엮은 워크플로를 올리기도 했습니다. 2026년 11월 2일에도 활동이 있었던 Spinneret은 인증 정보와 프록시를 스케줄링하는 서비스로, API 호출과는 관계가 없습니다.

"tikhub github"로 검색하면 직접 호스팅할 수 있는 오픈소스 스크래퍼도 나옵니다. 호출당 비용은 없지만 요청 서명, 플랫폼 방어 체계, 버전 업데이트, 자체 서버를 모두 직접 감당해야 합니다.

사용 언어에는 어떤 경로가 맞을까

SDK 현황을 실제 선택 기준으로 놓고 보면 답은 언어에 따라 갈립니다. Python 개발자는 양쪽 모두에 바로 쓸 수 있는 패키지가 있습니다. TikHub의 pip install tikhub는 커버리지가 가장 넓고 비동기 클라이언트를 제공합니다. 저희의 pip install everyinfra는 의존성이 없고 명령줄 도구와 비용 추정 기능이 함께 제공됩니다. JavaScript와 TypeScript 개발자에게 TikHub의 npm 패키지는 별 도움이 되지 않습니다. 2025년 3월에 업데이트가 멈췄고, 엔드포인트의 32.3%만 다루며, 설치 명령어의 패키지 이름을 직접 고쳐야 합니다.

저희 npm 패키지는 Python 패키지와 같은 날 배포되었으며, Node 18 이상에 내장된 fetch 함수에만 의존합니다. Go, Java, C++, PHP 개발자는 양쪽 모두 일반 HTTP 요청을 쓰는 편이 가장 낫습니다. TikHub의 해당 언어 SDK는 오래되었지만, 튜토리얼 페이지에 복사해 쓸 수 있는 Go, Java, PHP 요청 예제가 있습니다. 저희는 이 언어들의 SDK를 제공하지 않습니다. 대신 모든 데이터 기능이 같은 POST /api/v1/social을 사용합니다. 요청 함수 하나를 작성하고 플랫폼마다 platform과 action만 바꾸면 됩니다.

그 이면에는 놓치기 쉬운 설계 차이가 있습니다. API의 형태에 따라 SDK가 얼마나 중요한지가 정해진다는 점입니다. TikHub의 엔드포인트는 각각 고유한 경로와 파라미터 이름을 가지므로, 엔드포인트 1,055개는 함수 1,055개가 됩니다. 한 달 뒤처진 SDK는 엔드포인트를 놓치고, 1년 반 뒤처진 SDK는 메서드 10개 중 약 4개가 더 이상 작동하지 않습니다. 유지 관리 부담이 크며, SDK 5개 중 하나만 최신 상태를 유지하는 이유도 여기에 있습니다. 저희는 엔드포인트가 하나이므로, SDK에서 업데이트가 필요한 부분은 기능 이름 목록뿐입니다.

새 기능이 출시되어도 이전 SDK에서 일반 문자열로 호출할 수 있습니다. 에디터에서 자동 완성이 되지 않을 뿐입니다. 어느 설계가 모든 경우에 더 낫다고 할 수는 없습니다. TikHub 방식은 타입 검사기로 모든 엔드포인트의 파라미터를 검사할 수 있고, 저희 방식은 SDK가 잘 깨지지 않습니다.

저희 예제 코드는 공개 저장소 everyinfra-agent-plugins에 있습니다. 문서의 프록시 예제에는 2026년 10월 24일에 문서 언어별로 한 번씩 실행했다고 명시되어 있습니다.

EveryInfra 쪽: Python SDK, 명령줄, 원격 MCP

EveryInfra SDK는 2026년 11월 1일에 출시되었습니다. PyPI의 everyinfra 0.3.0과 npm의 everyinfra 0.3.0이 같은 날 배포되었습니다. 같은 파일이 SHA-256 체크섬과 함께 GitHub 릴리스 sdk-v0.3.0에도 올라가 있습니다. 이 SDK는 OpenAPI로 생성하지 않았습니다. 앞서 설명했듯 기능 573개가 엔드포인트 하나를 공유하므로, 범용 생성기로는 범용 메서드 하나만 만들 수 있기 때문입니다.

대신 백엔드의 기능 레지스트리에서 플랫폼과 기능 이름을 리터럴 타입으로 생성합니다. 그러면 에디터에서 이름이 자동 완성되고 오타가 즉시 표시됩니다. 11월 3일 새벽에 0.3.0을 설치해 직접 세어 보았습니다. 타입 목록에는 플랫폼 106개와 기능 573개가 있었고, 현재 카탈로그와 항목별로 정확히 일치해 추가되거나 누락된 항목이 없었습니다.

같은 패키지를 설치하면 명령줄 도구 everyinfra도 함께 설치됩니다. everyinfra catalog --find와 everyinfra describe tiktok/profile은 키 없이 기능, 파라미터, 응답 필드, 가격을 보여 줍니다. --dry-run은 아무것도 보내지 않고 요청 내용과 정가 기준 예상 비용을 출력합니다. --max-cost-usd는 예상 비용이 설정한 한도를 넘으면 요청을 보내지 않습니다.

everyinfra mcp-config --client claude는 지정한 클라이언트용 MCP 설정을 출력합니다. 키는 환경 변수로 참조하며 파일에 직접 쓰지 않습니다. TikHub SDK에는 이런 기능이 없습니다. 이 기능들은 AI 에이전트가 대신 API를 호출할 때 사람들이 우려하는 세 가지를 겨냥합니다. 에이전트가 엉뚱한 것을 호출하거나, 너무 많이 호출하거나, 키를 파일에 노출할 수 있다는 점입니다.

두 서비스는 원격 MCP에 서로 다르게 접근합니다. TikHub는 플랫폼별로 나눕니다. MCP 페이지와 llms.txt에서는 https://mcp.tikhub.io/tiktok/mcp처럼 플랫폼마다 주소를 하나씩 제공하므로, 필요한 플랫폼마다 설정 항목을 하나씩 추가해야 합니다. 토큰 없이 볼 수 있는 플랫폼 목록에는 서버별 도구 수가 나와 있으며, Douyin은 319개, TikTok은 163개입니다. 장점은 엔드포인트 하나하나가 독립된 도구라는 점입니다.

단점은 Douyin 서버 하나만으로도 모델에 도구 설명 319개가 전달된다는 점입니다. 저희는 주소 하나(https://api.everyinfra.com/mcp)에 도구 12개를 제공합니다.

모든 데이터 기능은 platform과 action 두 인자를 받는 everyinfra_call_api를 거치며, 무료 도구인 everyinfra_list_capabilities로 먼저 기능을 찾습니다. tools/list는 합계 3,779토큰입니다. MCP 명세는 두 설계를 모두 허용합니다. 현재 개정판은 2026년 7월 28일 자입니다. 이 개정판의 전송 섹션은 프로토콜을 무상태(stateless)로 정의합니다. initialize 핸드셰이크도, 세션 ID도 없습니다. Streamable HTTP에서는 메시지 하나가 같은 주소로 보내는 HTTP POST 하나이며, 각 요청은 _meta에 프로토콜 버전을 담습니다.

00:21:11에 보낸 저희 MCP 요청 두 건은 이 방식으로 동작했습니다. 핸드셰이크 없이 tools/list와 tools/call을 차례로 보냈고 둘 다 결과를 반환했습니다. 인가 섹션은 OAuth 2.1을 기반으로 하지만, 인가가 OPTIONAL이라고 명시합니다. API 키 방식의 단점은 클라이언트가 로그인 절차를 대신 실행해 줄 수 없어 키를 직접 붙여 넣어야 한다는 점입니다.

두 서비스 모두 OAuth를 쓰지 않고 요청 헤더로 API 키를 받습니다. 다음은 설정 예시입니다. 필드 이름은 클라이언트마다 다르므로 해당 클라이언트의 문서를 확인하고, API 키는 환경 변수에 보관하십시오:

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}

실제 호출 3건: curl, Python SDK, MCP

‘키 발급부터 첫 성공 호출까지’를 구체적으로 보여 드리기 위해, 두 서비스가 모두 제공하는 흔한 조회 세 가지를 골라 각각 다른 호출 방식을 썼습니다. 호출마다 객체 하나를 읽으며, 대상은 TikTok 프로필, Douyin 동영상, Xiaohongshu 노트입니다. 저희 쪽에서는 tiktok/profile, douyin/video, xiaohongshu/note입니다. TikHub 문서에서 대응하는 엔드포인트는 tiktok/web/fetch_user_profile, douyin/web/fetch_one_video, 그리고 노트용으로 문서가 가장 먼저 권장하는 xiaohongshu/app_v2/get_image_note_detail입니다.

첫 번째 호출은 curl을 사용했습니다. 싱가포르 시간 00:18:54에 보내 30초 뒤 tiktok 계정 정보를 받았습니다. 팔로워 96,500,000명, 동영상 1,514개였고 $0.000556가 과금되었습니다. TikHub 데모 응답에 나온 같은 계정과 일치하지만, TikHub의 statsV2는 정확한 수치(96,519,349)를 주는 반면 저희는 반올림한 숫자를 반환합니다. 정확한 팔로워 수가 필요하다면 이 부분은 TikHub가 낫습니다.

curl -X POST https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"tiktok","action":"profile","params":{"username":"tiktok"}}'

두 번째 호출은 Python SDK 0.3.0을 사용했습니다. 싱가포르 시간 00:20:19에 보내 27.4초 만에 Douyin 에어프라이어 리뷰 동영상을 받았습니다. 이 동영상은 좋아요 33,693개, 댓글 2,101개였고, 호출 비용은 $0.000556였습니다. 코드는 몇 줄이면 되고, 키는 환경 변수에서 가져옵니다:

import os
from everyinfra import EveryInfra
ei = EveryInfra(os.environ["EVERYINFRA_API_KEY"])
video = ei.data("douyin", "video", url="https://www.douyin.com/video/7633263781723770163")
print(video["billing"]["charged_usd"])

세 번째 호출은 원격 MCP를 거쳤습니다. 싱가포르 시간 00:21:11에 everyinfra_call_api 도구에 대한 tools/call을 보냈습니다. 42.2초 만에 2026년 10월 25일에 게시된 Xiaohongshu 노트를 받았고, 좋아요 992개, 댓글 567개였으며 $0.005556가 과금되었습니다. result.content[0].text 필드에는 billing을 포함해 REST 호출과 같은 JSON이 담겨 있습니다.

짚고 넘어갈 점이 있습니다. 성공한 호출 3건 모두 27~42초가 걸려 느렸습니다. 저희 동기 호출의 제한 시간은 85초이며, 이보다 오래 걸리는 호출은 타임아웃으로 실패하고 과금되지 않습니다. 대량 처리에는 "mode": "async"를 추가해 작업 ID를 받고 나중에 결과를 가져오는 방식을 문서에서 권장합니다. TikHub 토큰이 없어서 TikHub의 실제 엔드포인트 응답 시간은 측정하지 못했습니다.

데모 엔드포인트가 캐시된 고정 객체로 0.65초 만에 응답했다는 것만 확인했습니다. openapi.json의 info 블록에는 타임아웃 설정이 30~60초로 나와 있으며, 30초를 넘는 요청에는 자체 프록시를 쓰라고 권장합니다. 어느 서비스가 더 빠른지는 이 글에서 결론 내리지 않습니다.

응답 읽기: 데이터는 어디에, 비용은 어디에 있을까

첫 호출이 성공하고 나면 다음 문제는 응답을 어떻게 파싱할지입니다. 두 서비스의 래퍼는 크게 다릅니다. TikHub의 모든 엔드포인트는 같은 래퍼를 씁니다. openapi.json의 ResponseModel과 데모 응답에서 최상위 필드 15개를 확인했습니다. code, message, message_zh, request_id, support, time, time_stamp, time_zone, docs, cache_message, cache_message_zh, cache_url, router, params, data입니다. 데이터는 data에 들어 있고, 그 형태는 엔드포인트마다 다릅니다.

대부분은 플랫폼 자체 응답과 비슷한 형태입니다. 예를 들어 TikTok 프로필은 data.userInfo.user와 data.userInfo.stats 아래에 플랫폼 고유의 camelCase 이름으로 들어 있습니다. 장점은 플랫폼이 반환한 내용을 빠짐없이 받을 수 있다는 점입니다. 대신 플랫폼마다, 엔드포인트 버전마다 별도의 파서가 필요합니다.

TikHub의 래퍼에는 호출 비용이 나오지 않습니다. 문서에 따르면 호출은 200을 반환하면 과금됩니다. 사용한 금액을 확인하려면 사용자 엔드포인트를 호출해야 합니다. 문서 사이트의 TikHub-User-API 그룹에 일일 사용량 엔드포인트와 가격 계산 엔드포인트가 있습니다. EveryInfra의 래퍼에는 id, platform, action, results, billing, quota가 있습니다.

results 필드는 카탈로그 response_fields의 필드 이름을 사용하며, TikTok 프로필에는 username, follower_count, video_count가 있습니다. billing.charged_usd는 이 호출에 실제로 과금된 미국 달러 금액이고, balance_after_usd는 호출 후 잔액입니다. 배치에서는 charged_usd를 합산하면 총액이 나오며, 이 글의 호출 3건 비용도 이렇게 확인했습니다.

간단한 가격 비교

가격은 저희의 다른 글 두 편에서 자세히 다루므로, 여기서는 세 가지 시나리오만 나란히 놓고 봅니다. 각 시나리오는 객체 하나를 읽으므로 호출 1,000건당 가격과 결과 1,000건당 가격이 같습니다.

정가 기준으로 세 시나리오 모두 TikHub가 저희의 1.8배이므로, 저희가 약 44% 저렴합니다. 이는 저희 카탈로그의 $0.000556 가격 등급과 일치합니다. TikHub가 더 저렴한 경우는 두 가지입니다. 첫째는 사용량입니다. TikHub의 llms.txt에는 일일 할인 단계가 나와 있으며, 하루 30,000건을 넘으면 절반 가격까지 내려갑니다. TikTok 프로필 엔드포인트는 할인이 적용되므로 최상위 등급에서는 1,000건당 $0.50으로, 저희 $0.556보다 저렴합니다.

둘째는 문서화되지 않은 엔드포인트입니다. TikHub 가격표에는 호출당 $0.001인 v5 Xiaohongshu 노트 엔드포인트가 있습니다. 문서가 권장하는 app V2 엔드포인트의 10분의 1이며, 저희 가격은 이 엔드포인트의 5.6배입니다. 하지만 v5는 openapi.json에 없어 파라미터 문서가 없고, 얼마나 안정적인지도 판단할 수 없습니다. 전체 가격 비교는 TikHub 요금 해설과 Douyin 기능 37개 가격 하나하나 비교를 참고하시기 바랍니다.

첫 청구액을 따질 때는 실패한 호출도 함께 계산해야 하며, API를 익히는 동안에는 보통 실패가 많습니다. 싱가포르 시간 00:18:54의 키 없는 호출과 00:19:24의 잘못된 파라미터 호출은 모두 charged_usd가 0인 오류를 반환했습니다. 저희는 과금 전에 파라미터를 검사하므로, 이름을 잘못 쓴 요청이 과금된 뒤 환불되는 일은 없습니다. TikHub의 FAQ에는 ‘성공한 요청에만 과금한다’고 나와 있습니다. 200을 반환한 요청이 과금되고 실패한 요청은 과금되지 않습니다. 가격은 요청당 $0.001~$0.01입니다.

이 규칙대로라면 TikHub에서도 401, 403, 422 오류는 비용이 들지 않겠지만, 키가 없어 직접 테스트하지는 못했습니다. 실제 차이는 ‘데이터 없는 200’에 있습니다. 저희는 빈 결과를 같은 charge_id로 환불합니다. TikHub에서는 빈 결과 환불을 설명하는 페이지를 찾지 못했고, 환불 정책에는 충전 금액이 환불되지 않는다고 나와 있습니다.

따라서 AI 에이전트가 파라미터를 시험하는 동안 발생하는 오류 호출은 양쪽 모두 비용이 들지 않을 가능성이 큽니다. 차이는 성공했지만 내용이 비어 있는 호출에서 드러납니다. 이름이 바뀐 계정이나 삭제된 동영상이 그런 예로, 플랫폼은 여전히 200을 반환합니다. 배치에 이런 대상이 많을수록 두 청구액의 차이도 커집니다.

TikHub가 더 나은 선택일 때

이 섹션이 없다면 위의 비교는 공정하지 않습니다. 아래 표의 모든 행은 이 글에서 인용한 공개 자료에 근거합니다.

TikHub에는 저희에게 없는 설계가 하나 더 있습니다. 성공한 응답마다 cache_url이 포함되어, 해당 호출의 원본 JSON을 24시간 동안 무료로 다시 열 수 있습니다. 튜토리얼 페이지에 따르면 덕분에 파싱 버그가 생겨도 다시 호출하는 비용이 들지 않습니다. 팀원이 같은 결과를 재현할 수도 있습니다. 저희 쪽에서는 request_id로 호출 레코드와 과금 내역을 조회할 수 있지만, 당시의 전체 응답은 볼 수 없습니다.

반대로 저희는 실패와 빈 결과를 자동으로 환불하고, 호출 전에 응답 필드를 보여 줍니다. 또한 API 키마다 제품별 사용 여부를 설정할 수 있고, 전송 전에 비용을 추정할 수 있으며, 더 다양한 플랫폼을 지원합니다. 저희 카탈로그의 플랫폼 106개에는 소셜 미디어뿐 아니라 이커머스, 지역 리뷰, 지도, 채용 사이트도 포함됩니다. TikHub의 MCP 플랫폼 목록에는 플랫폼 15개와 "Others" 그룹이 있습니다. 최신 목록은 카탈로그에서 확인하시기 바랍니다.

상황별로 고르는 법

위 비교를 몇 가지 판단으로 정리하면 다음과 같습니다. 첫째, Python으로 정했고 TikHub의 엔드포인트 1,055개 중 Xingtu나 Douyin Index처럼 매우 특수한 엔드포인트가 필요한 경우입니다. 엔드포인트마다 파서를 작성할 수 있다면 TikHub의 Python SDK가 바로 쓸 수 있는 경로입니다. 문서는 방대하지만 엔드포인트별 페이지가 자세합니다.

둘째, JavaScript, Go, Java를 쓴다면 TikHub의 SDK는 큰 도움이 되지 않으며, 양쪽 모두 HTTP 요청을 직접 보내게 됩니다. 차이는 먼저 읽어야 하는 양입니다. 저희 플랫폼별 카탈로그는 약 1,870토큰이고, 호출 전에 응답 필드를 알려 줍니다. 셋째, AI 에이전트가 호출을 맡는다면 가장 중요한 질문은 세 가지입니다.

파라미터와 가격을 먼저 조회할 수 있는가? 잘못된 호출에 비용이 드는가? 키를 파일에 노출할 수 있는가?

저희 테스트에서 401과 422는 비용이 들지 않았고, 에이전트에게 다음에 할 일을 알려 주었습니다. 저희 명령줄 도구는 전송 전에 비용을 추정할 수도 있습니다. TikHub의 데모 엔드포인트로는 에이전트가 실제 응답을 먼저 하나 볼 수 있고, TikHub의 401에는 표준 헤더가 포함됩니다. 넷째, 할인이 적용되는 엔드포인트 하나에 하루 수만 건을 호출하는 경우입니다.

또는 가격은 있지만 문서가 없는 엔드포인트를 감수할 수 있는 경우입니다. 두 경우 모두 TikHub의 단가가 더 낮을 수 있습니다. 결정하기 전에 TikHub 가격표로 직접 계산해 보시기 바랍니다.

최근 변경 사항(2026년 10월~11월)

• 2026년 11월 3일: TikHub의 openapi.json 경로가 1,058개로 11월 2일보다 2개 늘었지만, 버전 표기는 여전히 V5.3.2입니다. 시사점: 이 파일로 SDK를 생성하거나 동기화한다면 변경 감지를 버전 번호에 의존하지 마십시오.
• 2026년 11월 1일: EveryInfra의 Python 및 npm SDK 0.3.0이 출시되었고, 같은 날 카탈로그가 91개에서 106개 플랫폼으로 늘었습니다. 시사점: SDK 타입 목록을 실시간 카탈로그와 대조해 보십시오. 저희 테스트에서는 이 버전이 일치했습니다.
• 2026년 10월 28일: GitHub 푸시 보호가 이제 AI가 탐지한 시크릿을 차단할 수 있습니다. 공개 프리뷰로 기본값은 꺼져 있으며, Secret Protection 또는 Advanced Security를 사용하는 조직에서만 쓸 수 있습니다. 시사점: 고정된 형식이 없는 키도 이제 푸시 시점에 막을 수 있습니다. 다만 조직이 이 기능을 켜야 합니다. 개인 저장소에서는 여전히 키가 들어가지 않도록 직접 관리해야 합니다.
• 2026년 10월 20일: GitHub의 시크릿 스캐닝용 사용자 지정 패턴 API가 잘못된 인자에 대해 500 대신 422를 반환하도록 바뀌었습니다. 이제 호출하는 쪽에서 입력 오류와 서버 오류를 구분할 수 있습니다. 시사점: TikHub와 저희 API 모두 재시도를 같은 방식으로 작성하십시오. 4xx에서는 요청을 수정하고, 5xx에서만 재시도합니다. 두 서비스 모두 잘못된 파라미터에 422를 사용합니다.
• 2026년 10월 13일: GitHub가 새 시크릿 탐지 모델을 소개했습니다. 먼저 정규식 규칙으로 후보를 모은 뒤, 소형 모델이 파일 경로, 변수 이름, 주변 코드를 읽습니다. 사용자 수용률은 11.5% 올랐고 스캔 시간 중앙값은 86% 줄었습니다. 시사점: 고정 접두사가 없는 키도 점점 더 잘 잡힙니다. 하지만 가장 안전한 키는 여전히 저장소에 아예 들어가지 않은 키입니다.

FAQ

질문은 2026년 11월 3일에 확인한 해당 키워드의 Google 검색 추천어와 포럼 게시물에서 가져왔습니다. 답변마다 출처를 밝혔습니다.

TikHub API 키는 어디서 발급하나요?

user.tikhub.io에 로그인해 사용자 센터를 열고 API 토큰 메뉴에서 토큰을 생성합니다. 절차는 문서 README의 "Get API Token" 섹션에 있습니다(검색 추천어: "tikhub api key", "tikhub api token"). 먼저 이메일을 인증해야 하며, 인증하지 않으면 호출 시 403이 반환됩니다. 사용자당 키를 최대 100개까지 만들 수 있습니다. ai.tikhub.io의 AI 프록시용 키는 별도이며, 데이터 엔드포인트에는 쓸 수 없습니다.

TikHub API 문서 사이트와 Swagger는 무엇이 다른가요?

둘 다 같은 openapi.json을 보여 줍니다(검색 추천어: "tikhub api doc", "api tikhub io"). docs.tikhub.io는 엔드포인트마다 페이지가 있어 파라미터를 찾아보기에 가장 좋습니다. api.tikhub.io는 토큰을 붙여 넣고 호출을 시험해 볼 수 있는 Swagger 페이지이며, 토큰은 "Bearer" 접두사 없이 붙여 넣습니다. 엔드포인트 1,052개가 범용 래퍼만 문서화하고 있어 두 곳 모두 대부분 엔드포인트의 응답 필드를 보여 주지 않으므로, 필드는 직접 호출해 봐야 알 수 있습니다.

TikHub GitHub의 SDK 중 아직 쓸 수 있는 것은 무엇인가요?

Python SDK입니다(검색 추천어: "tikhub github", "tiktok api python github"). 10월 3일에 나온 버전 2.2.0은 현재 엔드포인트의 99.2%를 다룹니다. TypeScript, Go, Java, C++ SDK는 2025년 3월 이후 바뀌지 않았고 32.3%만 다룹니다. 이 SDK들에는 엔드포인트가 문서에서 사라진 메서드가 245개 들어 있습니다. 이 언어들에서는 일반 HTTP가 더 안전한 선택입니다.

Python 예제가 있는 TikTok API 문서가 있나요?

예, 양쪽 모두 있습니다(검색 추천어: "tiktok api documentation python"). TikHub의 튜토리얼 페이지에는 Python, JavaScript, Go, Java, PHP, cURL 예제가 있고, Python SDK README에는 리소스 이름으로 호출하는 방법이 나와 있습니다. 저희 문서에는 curl 예제가 있으며, pip install everyinfra를 실행하면 타입이 정의된 클라이언트를 사용할 수 있습니다. 위의 짧은 예제가 첫 호출의 전부입니다.

TikTok에도 API가 있나요? 무료 TikTok API 키가 있나요?

TikTok에도 자체 API가 있지만 제한이 있습니다(검색 추천어: "does tiktok have an api", "tiktok api key free"). 2026년 8월 4일에 업데이트된 Display API는 내 앱을 승인한 사용자의 프로필과 동영상만 읽을 수 있습니다. Research API는 자격을 갖춘 연구 기관이 신청해야 합니다. 공개 계정과 다른 사람의 동영상을 읽으려면 서드파티 API가 필요합니다. 대부분 소액의 체험용 크레딧을 제공합니다. TikHub는 $0.05를 지급하고, 저희는 저장소 두 개에 스타를 누르면 24시간 동안 유효한 $1를 드립니다.

TikHub를 Claude나 n8n과 함께 쓸 수 있나요?

예. TikHub는 플랫폼마다 MCP 서버를 하나씩 운영하며, Claude Code 플러그인 저장소와 n8n 통합 저장소가 있습니다(출처: TikHub MCP 페이지 및 GitHub). TikHub 공식 계정은 Reddit에 Claude, n8n, TikHub를 엮은 워크플로를 올리기도 했습니다. 단, n8n 저장소의 마지막 푸시는 393일 전입니다. 저희 원격 MCP 서버는 헤더 기반 원격 MCP를 지원하는 모든 클라이언트에서 작동하며, 위의 설정 예시만 있으면 됩니다.

TikHub는 믿을 만한가요?

한 Reddit 사용자가 "Is TikHub AI legit"이라고 물었지만(r/Seedance_AI 스레드), 답글에서 명확한 답은 나오지 않았습니다. TikHub 튜토리얼 페이지에는 공개 데이터만 제공하며 그 데이터를 소유하지 않는다고 나와 있습니다. 환불 정책에는 엔드포인트가 실제로 작동하지 않는 경우를 제외하면 결제 후 환불되지 않는다고 되어 있습니다. 저희는 TikHub의 규정 준수 여부를 판단하지 않습니다. 먼저 데모 엔드포인트와 $0.05의 체험용 크레딧을 사용해 본 뒤 충전 금액을 정하시기를 권합니다.

시작하기

1. 기능 카탈로그 또는 인프라 마켓플레이스에서 필요한 기능을 찾습니다(예: tiktok/profile). 파라미터, 응답 필드, 가격을 확인합니다. 키는 필요 없습니다.
2. 회원가입 후 콘솔에서 키를 생성합니다. 전체 키는 한 번만 표시되므로 환경 변수 EVERYINFRA_API_KEY에 저장합니다.
3. 문서 빠른 시작의 curl 예제로 첫 요청을 보냅니다. pip install everyinfra를 실행해 SDK를 쓰거나, 위의 MCP 설정을 클라이언트에 붙여 넣어도 됩니다. 응답에서 billing.charged_usd를 확인합니다.
4. 401이나 422가 반환되면 먼저 응답의 next_steps를 읽습니다. 다른 플랫폼은 TikTok, Douyin, Xiaohongshu 페이지와 MCP 설정 가이드를 참고하십시오.

참고 자료

1. “Getting Started: First API Call in 4 Steps”, TikHub, 2026-11-03 열람, https://tikhub.io/getting-started
2. “Social Media API Tutorials and Code Examples”, TikHub, 2026-11-03 열람, https://tikhub.io/tutorials
3. “Pricing”, TikHub, 2026-11-03 열람, https://tikhub.io/pricing
4. “FAQ: Billing, Rate Limits and Platform Support”, TikHub, 2026-11-03 열람, https://tikhub.io/faq
5. “llms.txt”, TikHub, 2026-11-03 열람, https://tikhub.io/llms.txt
6. “llms-full.txt”, TikHub, 2026-11-03 열람, https://tikhub.io/llms-full.txt
7. “MCP Integration Guide”, TikHub, 2026-11-03 열람, https://tikhub.io/mcp
8. “Social Media API Reference”, TikHub, 2026-11-03 열람, https://tikhub.io/api-reference
9. “README - English”, TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/4592766m0
10. “README”(중국어판), TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/4579297m0
11. “Getting Started”(판매자 온보딩), TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/5432442m0
12. “llms.txt”(문서 사이트 인덱스), TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/llms.txt
13. “Get user profile (TikTok Web API)”, TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/186826057e0
14. “Demo: fixed TikTok user”, TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/337619232e0
15. “Get all endpoints information”, TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/186826055e0
16. “About TikHub AI API”, TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/7781112m0
17. “TikHub Refund Policy”(2026-07-20 업데이트), TikHub 문서 사이트, 2026-11-03 열람, https://docs.tikhub.io/9453198m0
18. “openapi.json”(V5.3.2), TikHub, 2026-11-03 열람, https://api.tikhub.io/openapi.json
19. “Swagger UI”, TikHub, 2026-11-03 열람, https://api.tikhub.io/
20. 가격 목록 엔드포인트 get_all_endpoints_info, TikHub, 2026-11-03 열람, https://api.tikhub.io/api/v1/tikhub/user/get_all_endpoints_info
21. 데모 엔드포인트 demo/tiktok/web/fetch_user_profile, TikHub, 2026-11-03 열람, https://api.tikhub.io/api/v1/demo/tiktok/web/fetch_user_profile
22. MCP 플랫폼 목록, TikHub, 2026-11-03 열람, https://mcp.tikhub.io/platforms
23. TikHub GitHub 조직, GitHub, 2026-11-03 열람, https://github.com/TikHub
24. TikHub-API-Python-SDK, GitHub, 2026-11-03 열람, https://github.com/TikHub/TikHub-API-Python-SDK
25. 커밋 c4620078: “sync SDK to live OpenAPI spec (1048 endpoints)”, GitHub, 2026-10-02, https://github.com/TikHub/TikHub-API-Python-SDK/commit/c4620078fa6930380c6c2a0a51597718c762e27a
26. TikHub-API-TypeScript-SDK, GitHub, 2025-03-17, https://github.com/TikHub/TikHub-API-TypeScript-SDK
27. TikHub-API-GoLang-SDK, GitHub, 2025-03-09, https://github.com/TikHub/TikHub-API-GoLang-SDK
28. TikHub-API-Java-SDK, GitHub, 2025-03-09, https://github.com/TikHub/TikHub-API-Java-SDK
29. TikHub-API-CPP-SDK, GitHub, 2025-03-09, https://github.com/TikHub/TikHub-API-CPP-SDK
30. TikHub-API-Demo, GitHub, 2024-12-02, https://github.com/TikHub/TikHub-API-Demo
31. tikhub-plugin, GitHub, 2026-06-16, https://github.com/TikHub/tikhub-plugin
32. tikhub-mcp-dist, GitHub, 2025-09-23, https://github.com/TikHub/tikhub-mcp-dist
33. TikHub_n8n_Integration, GitHub, 2025-10-05, https://github.com/TikHub/TikHub_n8n_Integration
34. TikHub-Multi-Functional-Downloader, GitHub, 2025-03-18, https://github.com/TikHub/TikHub-Multi-Functional-Downloader
35. Spinneret, GitHub, 2026-11-02, https://github.com/TikHub/Spinneret
36. tikhub_api_skill, GitHub, 2026-11-03 열람, https://github.com/liangdabiao/tikhub_api_skill
37. tikhub 2.2.0, PyPI, 2026-10-03, https://pypi.org/project/tikhub/
38. @tikhubio/tikhub-api-ts-sdk, npm, read 2026-11-03, https://www.npmjs.com/package/@tikhubio/tikhub-api-ts-sdk
39. EveryInfra 기능 카탈로그, EveryInfra, 2026-11-03 열람, https://api.everyinfra.com/api/v1/social/catalog
40. EveryInfra 기능 카탈로그, compact=1, EveryInfra, 2026-11-03 열람, https://api.everyinfra.com/api/v1/social/catalog?compact=1
41. EveryInfra OpenAPI 2.0.0, EveryInfra, 2026-11-03 열람, https://api.everyinfra.com/openapi.json
42. EveryInfra llms.txt, EveryInfra, 2026-11-03 열람, https://api.everyinfra.com/llms.txt
43. everyinfra 0.3.0, PyPI, 2026-11-01, https://pypi.org/project/everyinfra/
44. everyinfra 0.3.0, npm, 2026-11-01, https://www.npmjs.com/package/everyinfra
45. everyinfra-agent-plugins 릴리스 sdk-v0.3.0, GitHub, 2026-11-01, https://github.com/everyinfra/everyinfra-agent-plugins/releases/tag/sdk-v0.3.0
46. everyinfra-agent-plugins, GitHub, 2026-11-03 열람, https://github.com/everyinfra/everyinfra-agent-plugins
47. “RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage”, IETF, 2012-10, https://datatracker.ietf.org/doc/html/rfc6750
48. “RFC 9110: HTTP Semantics”, IETF, 2022-06, https://www.rfc-editor.org/rfc/rfc9110.html
49. “MCP specification: Transports (2026-07-28)”, Model Context Protocol, 2026-11-03 열람, https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
50. “MCP specification: Authorization (2026-07-28)”, Model Context Protocol, 2026-11-03 열람, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
51. “The /llms.txt file proposal”, llmstxt.org, 2026-11-03 열람, https://llmstxt.org/
52. “About secret scanning”, GitHub Docs, 2026-11-03 열람, https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
53. “Display API Overview”(2026-08-04 업데이트), TikTok for Developers, https://developers.tiktok.com/doc/display-api-overview
54. “Research API: access and eligibility”, TikTok for Developers, 2026-11-03 열람, https://developers.tiktok.com/products/research-api/
55. “DIY: turning a full API doc into a Claude Code skill”(중국어), Juejin, 2026-11-03 열람, https://juejin.cn/post/7595096774546096137
56. “Is TikHub AI legit and works?”, Reddit r/Seedance_AI, 2026-11-03 열람, https://www.reddit.com/r/Seedance_AI/comments/1u2gjmx/is_tikhub_ai_legit_and_works_seems_very_cheap_for/
57. “Day 1 on TikTok: Claude, TikHub API and n8n workflow”, Reddit r/ClaudeAI, 2026-11-03 열람, https://www.reddit.com/r/ClaudeAI/comments/1levnmu/day_1_on_tiktok_400_likes_90_saves_on_first_video/
58. “Supported secret scanning patterns”, GitHub Docs, 2026-11-03 열람, https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns
59. “Push protection beyond predefined secret patterns”, GitHub Changelog, 2026-10-28, https://github.blog/changelog/2026-10-28-push-protection-beyond-predefined-secret-patterns/
60. “Updates to GitHub secret scanning”, GitHub Changelog, 2026-10-20, https://github.blog/changelog/2026-10-20-updates-to-github-secret-scanning/
61. “GitHub's model for secret detection: Finding more secrets with less noise”, GitHub Blog, 2026-10-13, https://github.blog/ai-and-ml/githubs-model-for-secret-detection-finding-more-secrets-with-less-noise/