TikHub API Key, API Docs and GitHub SDKs, Tested Step by Step

On November 3, 2026, we downloaded every public piece of TikHub's developer material and counted it with scripts. Its openapi.json lists 1,058 endpoint paths in 3.1 MB, which is about 840,000 tokens for a model to read. For 1,052 of those endpoints, the documented success response is a generic wrapper with no data fields. On GitHub, the TypeScript, Go, Java and C++ SDKs had their last commits in March 2025. They cover only 32.3% of today's 1,055 active endpoints. The Python SDK is the exception: version 2.2.0 covers 99.2%.

On the same night we made three live calls through EveryInfra. We used curl, our Python SDK and our remote MCP server. They read a TikTok profile, a Douyin video and a Xiaohongshu note, and cost $0.006668 in total. At TikHub's list prices the same three reads cost 1.8 times as much as ours, so we are about 44% lower. TikHub is cheaper in two cases, high daily volume and one undocumented Xiaohongshu endpoint, and we show both below.

Scope, sources and how this article differs from the others

We already have three TikHub articles. The TikHub alternative article compares overall coverage and price. TikHub pricing explained takes apart the 1,470-row price list and the free credit. The TikHub Douyin API alternative prices 37 Douyin capabilities one by one, and the TikHub alternatives page has the summary. This article answers a different question: what people who search for "tikhub api key", "tikhub api doc" and "tikhub github" want to know before they write a line of code.

Where is the key? How does authentication work? Which docs should you read, and which SDK still works? How many steps does it take to get a first successful response? Price comes up only at the end, as a small check.

For TikHub we used only public material. That means the pricing and getting-started pages, the docs site and openapi.json. It also means the price list and demo endpoints that work without a key, the public GitHub organization, and the PyPI and npm pages. We read all of it on November 3, 2026, between 00:15 and 00:37 Singapore time.

We did not sign up for a TikHub account and we did not call any paid TikHub endpoint. So every statement about TikHub's paid behavior comes from its own docs. On the EveryInfra side, every number comes from live calls in the same half hour. Token counts come from a script that runs the o200k_base tokenizer over each downloaded file.

How to get a tikhub api key: four actions on each side

The first thing a new user wants is the key. TikHub's getting-started page has the title "First API Call in 4 Steps". The first step is to sign up and verify your email. The second is to browse the API marketplace for each endpoint's price and free-credit rule. The third is to top up for paid endpoints, and the fourth is to start coding. We read the page word by word.

None of the four steps tells you to create an API key. The key instructions are at the end of the README - English page on the docs site, in a section called "Get API Token". You log in, open the user center and click the API token menu. Then you create a token and copy it into your request header. A reader who follows only the getting-started page finishes all four steps and still does not know where the key is.

Email verification is not optional. The tutorials and FAQ page lists "email is not verified" as one cause of a 403 response. The same page says that each user can create up to 100 API keys, which makes it easy to give each project its own key. The pricing page says new accounts get $0.05 of free credit, about 50 requests, once per person. An account that was deleted and created again does not get it a second time.

It also says that not every endpoint accepts free credit, so some endpoints need a paid balance from the first call. The minimum top-up is $5, and you can pay with PayPal, Alipay (up to $250 a day) or USDT (you also pay the network fee). The refund policy, updated on July 20, 2026, says "All Sales Are Final". A refund needs an endpoint that truly does not work, confirmed by TikHub's technical team.

There is one more trap: TikHub has two kinds of keys. Keys for the social data endpoints come from the user center at user.tikhub.io. TikHub also runs an AI proxy service in beta. Its AI API page says you sign up separately at ai.tikhub.io and create the key in that console.

The same page says the proxy does not work with the OpenAI Python SDK, the Anthropic SDK or the Google AI SDK. You must send plain HTTP requests. A key from one service does not work on the other. If a search for "tikhub api key" lands you on the AI proxy page, the key you create there will not open the data endpoints.

EveryInfra also takes four actions. You sign in with GitHub, Google, a phone number or an email address. In the console, under API Keys, you create a key, and the full key is shown only once. Then you send it in an Authorization: Bearer header, as described in our docs.

To try us without paying, you can star two of our GitHub repositories and claim $1 of trial credit in the console. It lasts 24 hours. The number of calls it buys depends on the price of each capability, and the free credit section below works it out for three cases.

If you do not want to star anything, you can top up instead. The smallest tier on our pricing page is $10. Compared with TikHub, we skip the separate email check, but our smallest top-up is twice as large as TikHub's $5. For someone who wants to pay as little as possible on day one, TikHub is friendlier.

The rows that matter most to teams are key creation and key scope. One hundred keys per user is generous for splitting costs by project. But TikHub's public docs do not say whether one key can be limited to some endpoints. The only hint is the status-code note about a token that "lacks required permissions". Our keys can be limited by product in the console.

For example, you can open the data API to an AI agent and keep CAPTCHA solving closed. You can also disable a key so that every call returns 401. Changing a key's scope, raising its limits and paying always need a person signed in to the console. A key created through the API can never be wider than the key that created it. So an AI agent that holds a key cannot use it to change the account.

Authentication: Bearer header, cookie and keys in URLs

Both services use Authorization: Bearer <key>. This form comes from RFC 6750. Section 2.3 of that standard says a token in the URL query "SHOULD NOT be used". Section 5.3 adds two points. Do not put bearer tokens in page URLs, because browser history and server logs can keep them. Do not store them in cookies that can be sent in clear text.

TikHub's README gives two methods. Method one is the header, and it is the recommended one. Method two is a cookie named Authorization, marked "not recommended, only when method one is not available". There is also a small detail on its Swagger page. When you click Authorize in the top right corner, you paste only the token, without the Bearer prefix. The page adds the prefix itself.

What a service returns when authentication fails says more than its docs. When something goes wrong, an AI agent sees only the response body. At 00:19:39 Singapore time we called TikHub's TikTok profile endpoint with no key. It answered 401 in 0.21 seconds.

The response headers included WWW-Authenticate: Bearer, which is what RFC 9110 section 15.5.2 requires for a 401. In the body, the message pointed to the "api-token-introduction" anchor in the README. There was a Chinese copy of the message and a Discord link. The docs field was null, and the time was in the Los Angeles time zone.

At 00:18:54 Singapore time we called EveryInfra with no key. It answered 401 with the code missing_key, fault: account and retryable: false. The next_steps field told the caller to put the key in the Authorization header and said that nothing was charged. Our response headers do not include WWW-Authenticate, so on this point TikHub follows the standard more closely than we do.

Wrong parameters are the more common mistake. At 00:19:24 Singapore time we sent tiktok/profile with user instead of username. EveryInfra returned 422 missing_param and named username as the missing field. It said that user is not a parameter of this capability, and attached a working example and the catalog address for the platform.

In TikHub's openapi.json, 973 endpoints declare a 422 validation error, and the documented format is the default field-validation message of its web framework. We had no TikHub key, so we could not see how it answers a misspelled parameter name in practice. We leave the comparison there.

Keeping the key out of Git, logs and chat transcripts

Once you have a key, the usual accident is not a stranger guessing it. It is you pasting it into a repository, a screenshot or a chat with an AI tool. GitHub's list of supported patterns sorts its secret scanning rules into three groups: generic rules, AI-detected secrets and provider rules. On November 3 the list showed 531 provider rules.

One generic rule matters most here. It is called http_bearer_authentication_header, and it looks for an Authorization: Bearer header written into code. GitHub rates its precision as medium. So a key that you commit together with its header has a chance of being found. But only providers in GitHub's partner program get a report and can revoke the key for you. In every other case you must disable the key yourself in the console.

On October 28, 2026, GitHub added AI-detected secrets to push protection. The new check does not need a fixed key format. It looks at variable names, file paths and nearby code. In early results it more than doubled the number of pushes that push protection stopped.

It is off by default, though. You must first turn on AI-detected secrets and push protection. It is only for organizations that pay for Secret Protection or Advanced Security, and it uses AI credits. For most solo developers, three habits still protect you on both services.

Keep the key in an environment variable or in your client's secret settings. In MCP configs, write a reference such as ${EVERYINFRA_API_KEY} instead of the key itself. Give each project its own key, so that a leak means you disable one key, not all of them. TikHub's limit of 100 keys per user makes the last habit easy. Our console also lets you create several keys, add an IP allow list to each one, and switch off products a key does not need.

Both services still accept one weaker method. TikHub accepts the token in a cookie named Authorization, and marks it as not recommended. RFC 6750 section 5.3 says that a token in a cookie needs protection against cross-site request forgery. It must not travel in a cookie that can be sent in clear text. On our side, early MCP connectors could put the key in the URL query.

Our docs say that this still works, but URLs end up in history and logs, so new setups should not use it. Our AI endpoint refuses a key in the URL outright. RFC 6750 says query tokens "SHOULD NOT" be used. Today both services recommend the header, so on this point they agree.

TikHub's public docs do not explain how to disable or rotate one key; they only list the six causes of a 401. On our side, a disabled key returns 401, and only a person in the console can enable it again or rotate it.

What you can do before you have a key

Both services let you look around before you sign up. TikHub has 8 demo endpoints; the docs site lists 9 entries, and the ninth shows the demo cache status. They need no token, return fixed objects and cache them for one hour. They cover fixed Douyin web and app videos, a Douyin search and a fixed Kuaishou video. They also cover a fixed TikTok user, a fixed TikTok app video, a fixed Instagram user and a WeChat article extractor.

At 00:19:38 Singapore time we called the fixed TikTok user demo. It returned 200 in 0.65 seconds with the tiktok account: 96,500,000 followers, 1,514 videos, and an exact 96,519,349 followers in statsV2. This is a good design, because you see a real response shape with no key at all. One detail is confusing.

The demo response says "Request successful. This request will incur a charge." We sent no token, so nothing could be charged. The likely reason is that every endpoint shares one response model, and this sentence is the model's default text.

EveryInfra has no demo endpoints. Instead, the capability catalog, the search tool list, the CAPTCHA type list and the MCP tools/list method all work without a key. Each catalog entry lists required and optional parameters, the maximum rows per call, price_usd, available and response_fields. So before you call anything, you know the field names you will get and what each call costs.

At 00:21:11 Singapore time we sent tools/list to https://api.everyinfra.com/mcp with no key, and it returned 12 tools. The two approaches have different strengths. TikHub's demos show you what one real response looks like. Our catalog tells you every field name and price before the first call.

How many tries the free credit buys

After "is there free credit?", the real question is "is it enough to try each endpoint I need a few times?" We divided each side's trial credit by the prices of the three scenarios in this article. TikHub gives $0.05, and 631 of the 1,472 rows in its price list (42.9%) accept free credit. The Xiaohongshu note endpoint that its docs recommend does not. For that scenario the free credit buys zero calls, and you must top up $5 first. Our $1 star credit works on everything except CAPTCHA solving, but it expires after 24 hours.

This table does not simply mean "our trial is more generous". TikHub's $0.05 has no stated expiry, which suits someone who signs up now and tests next week. Our $1 must be used within a day, which suits someone who wants a working flow today.

On both sides the number of calls moves with the price. On TikHub, the same $0.05 buys only 5 calls to an endpoint that costs $0.01, and none on an endpoint that refuses free credit. On our side, a $0.000556 capability such as the TikTok profile gets close to 1,800 calls, and the Xiaohongshu note gets 179. To estimate your own case, divide by the price_usd in the catalog, or run our command line tool with --dry-run, which prints the estimate.

Where the tikhub api doc lives: five entry points and an 840,000-token file

TikHub's docs have five entry points with a lot of overlap. There is the docs site at docs.tikhub.io, built with a hosted API-docs tool, with one page per endpoint and a Markdown export. There is a Swagger page at api.tikhub.io, where you can paste a token and try a call in the browser. There is an API reference page and a tutorials page on the main site. And there are llms.txt and llms-full.txt for AI readers. All of them come from one openapi.json, which is also what you import into Postman or an SDK generator.

Three things about openapi.json are worth knowing. First, its info block says version V5.3.2 and an update time of June 22, 2026, but the number of paths keeps changing. When the Python SDK synced on October 3 there were 1,050 paths. We counted 1,056 on November 2, 2026 and 1,058 on November 3, 2026, and the version number did not change. If you use the version number to decide whether the spec changed, you will decide wrong.

Second, 1,052 of the 1,058 endpoints point their success response at one generic ResponseModel. It defines wrapper fields such as code, message, request_id, time_zone and cache_url, and the type of data is "any". In other words, the spec tells you how to ask, but not which fields come back; you learn the fields by calling. Third, the file is large. At about 840,000 tokens, it is 3.5 times the size of our full catalog (240,429 tokens). No AI agent can read it whole as a manual.

Other developers have hit the same size problem. One developer wrote a public guide (in Chinese) on turning TikHub's openapi.json into a Claude Code skill, with the code on GitHub. The idea is to build a search layer over the endpoints. Then the model looks up only what it needs and does not read the whole file. That shows the need is real: the more endpoints a service has, the more it needs a "find first, then call" index.

TikHub's own answer is one MCP server per platform, covered below. Our answer is the catalog with filters. GET /api/v1/social/catalog?platform=tiktok&compact=1 returns only TikTok, without descriptions, in 6,809 bytes and 1,870 tokens. That is smaller than one TikHub endpoint page.

The docs site has one more small trap. The third item in its menu is called "Getting Started", but it is a guide for merchants who want to sell on the TikHub marketplace. It explains how to open a shop, sell digital goods, and pay a 1% withdrawal fee. It has nothing to do with calling the API. The developer getting-started page is on the main site at tikhub.io/getting-started, not on the docs site. A reader who lands on the docs site from a "tikhub api doc" search and clicks the menu in order reads an unrelated page first.

A mismatch between the price list and the docs is another way to get lost. TikHub's price list can be read without a token. At 00:19:39 Singapore time it had 1,472 rows, or 1,471 unique paths. We compared them path by path with the openapi.json from the same minute.

1,038 paths are in both, 433 are only in the price list, and 20 are only in the docs. The 433 price-only endpoints have a price but no parameter docs. Most look like old versions, but not all of them: as the price section shows, the cheapest Xiaohongshu note endpoint is one of them.

EveryInfra has fewer entry points. /docs is the human guide. The capability catalog and its compact version are for programs and AI agents. Our OpenAPI file is version 2.0.0 with 59 paths. Every data capability goes through one POST /api/v1/social and is picked with two fields, platform and action.

There is also an llms.txt of 25,845 bytes, and one docs page per platform and per capability, such as the TikTok profile API. All 573 capabilities in the catalog list response_fields, so you see the field names and types before you call. Our weakness is the other side of the same design. With 573 capabilities behind one endpoint, a generic OpenAPI generator gives you a single post(body) method. Parameter completion depends on our own SDK, which the next sections cover.

Handing the docs to an AI agent: how much it reads before the first call

Many developers no longer read API docs themselves. They ask Claude Code, Cursor or a similar coding agent to read them and write the call. Then the size of the docs becomes context space and cost. So we took one task, "find the TikTok profile endpoint and write the first request", and worked out the cheapest reading path on each side from public material. Every token count comes from a script that ran o200k_base over the original files, downloaded on November 3, 2026, between 00:16 and 00:23 Singapore time.

On TikHub's side, the cheapest path has two steps. The agent reads the docs-site llms.txt index (1,274 lines, about 47,604 tokens), finds the line for the TikTok web "get user profile" endpoint, and then opens that endpoint's Markdown page (about 2,295 tokens). That is about 49,899 tokens in total. The main-site llms.txt is only 1,279 tokens, but it lists platforms and links, not endpoints, so the agent must still go to the docs site.

The full openapi.json, at about 839,775 tokens, is not a sensible thing for any agent to read. TikHub's MCP server is another route. The TikTok server has 163 tools, so a connected model receives 163 tool descriptions. Listing them needs a token, so we did not measure their size.

On our side, the cheapest path is one step: GET /api/v1/social/catalog?platform=tiktok&compact=1, 6,809 bytes and about 1,870 tokens. It holds the parameters, prices and response field names of every TikTok capability, which is enough to write the request. On this path, TikHub's reading load is about 26.7 times ours. This ratio measures how much an agent must read for one endpoint, not the quality of the docs.

TikHub's endpoint pages have bilingual descriptions and detailed parameter examples. Our compact catalog drops descriptions and keeps names, so it is cheaper to read and also plainer. Both services publish an llms.txt for AI readers. The idea comes from the llms.txt proposal, which suggests a short Markdown index with the details behind links, and both services follow it.

tikhub github: 12 public repos, checked one by one

At 00:16 Singapore time the TikHub GitHub organization had 12 public repos. We read the stars and last push time of each through the GitHub API. Then we cloned the 6 SDK and plugin repos. A script pulled out every hard-coded /api/v1/... endpoint path in their source and compared them with that day's openapi.json.

The Python SDK is the best-kept repo in the organization, and it deserves credit first. Its commit of October 2 (Pacific time) says "sync SDK to live OpenAPI spec, skip deprecated endpoints (1048 endpoints)", and the next day version 2.2.0 went out on PyPI. All 1,048 paths we pulled from it are still in today's docs; not one is dead. It ships sync and async clients, automatic retries and rate-limit handling, passes mypy --strict, and has a README in English, Chinese, French, Spanish and Japanese.

It lacks only the 9 endpoints added after October 3. They are a Bilibili post comments endpoint, five async job endpoints for LinkedIn, two new Threads endpoints and a TikTok Shop bestseller list. At about 9 new endpoints a month, it will always trail a little until the next sync.

The other four languages are much further behind. The TypeScript, Go, Java and C++ SDKs were generated from the OpenAPI spec in March 2025 and have not changed since. Of the 586 paths in their source (588 in Go), 245 (247 in Go) are no longer in the docs. Calling those methods gets a 404 or some other error. The remaining 341 cover 32.3% of today's endpoints. The TypeScript SDK has a more direct problem.

On npm the package is @tikhubio/tikhub-api-ts-sdk, latest version 1.0.1. But both install commands on the npm page say @tikhub/tikhub-api-ts-sdk. We queried the npm registry at 00:36 Singapore time, and that name returned 404, so copying the command fails. The command in the GitHub README is correct.

The Python SDK's PyPI page has a smaller slip. Its "Homepage" link points to TikHub-API-Python-SDK-V2, which also returns 404. The README still says version 2.1.1, while PyPI is at 2.2.0.

The other repos each have a use. TikHub-API-Demo holds sample scripts from December 2024, sorted by Douyin, Instagram, Kuaishou and TikTok. TikHub-Multi-Functional-Downloader is a desktop downloader with a user interface and, at 193 stars, the most starred repo after the Python SDK. tikhub-mcp-dist is for people who want to run the MCP server locally.

TikHub_n8n_Integration adds TikHub nodes to n8n, and its last push was 393 days ago. TikHub's own account posted a Claude, n8n and TikHub workflow on Reddit. Spinneret, still active on November 2, 2026, is a service for scheduling credentials and proxies and has nothing to do with calling the API.

A "tikhub github" search also turns up open-source scrapers that you can host yourself. They cost nothing per call, but you must handle request signing, platform defenses, version updates and your own servers.

Which path fits your language

Turn the SDK data into choices and the answer splits by language. Python developers have a ready package on both sides. TikHub's pip install tikhub has the widest coverage and an async client. Our pip install everyinfra has no dependencies and comes with a command line tool and cost estimates. JavaScript and TypeScript developers get little from TikHub's npm package. It stopped in March 2025, covers 32.3% of endpoints, and its install command needs the package name fixed by hand.

Our npm package shipped on the same day as the Python one and depends only on the fetch function built into Node 18 and later. Go, Java, C++ and PHP developers are best served by plain HTTP on both sides. TikHub's SDKs for these languages are out of date, but its tutorials page has Go, Java and PHP request samples you can copy. We have no SDK for these languages. The upside is that every data capability is the same POST /api/v1/social. You write one request function and change only platform and action for each platform.

There is a design difference behind this that is easy to miss: the shape of an API decides how much its SDK matters. Every TikHub endpoint has its own path and its own parameter names, so 1,055 endpoints become 1,055 functions. An SDK that is one month behind misses endpoints. One that is a year and a half behind has about four in ten methods that no longer work. That is a heavy maintenance load, and it explains why only one of five SDKs keeps up. We have one endpoint, so the only part of our SDK that needs updates is the list of capability names.

When a new capability goes live, an old SDK can still call it with a plain string; the editor just will not autocomplete it. Neither design is better in every case. TikHub's lets a type checker check every endpoint's parameters. Ours makes the SDK hard to break.

Our own sample code lives in the public repo everyinfra-agent-plugins. The proxy example on our docs states that it ran on October 24, 2026, once in each docs language.

Our side: Python SDK, command line and remote MCP

The EveryInfra SDK shipped on November 1, 2026. everyinfra 0.3.0 on PyPI and everyinfra 0.3.0 on npm went out the same day. The same files are in the GitHub release sdk-v0.3.0 with SHA-256 checksums. It is not generated from OpenAPI. As explained above, 573 capabilities share one endpoint, so a generic generator could only produce one generic method.

Instead, we generate the platform and capability names as literal types from our backend's capability registry. An editor can then autocomplete them and flag a typo at once. Early on November 3 we installed 0.3.0 and counted. Its type list has 106 platforms and 573 capabilities, and it matches the live catalog item by item, with nothing extra and nothing missing.

The same package installs a command line tool, everyinfra. everyinfra catalog --find and everyinfra describe tiktok/profile need no key and show capabilities, parameters, response fields and prices. --dry-run prints the request and the estimated cost at list price and sends nothing. --max-cost-usd refuses to send when the estimate is above your limit.

everyinfra mcp-config --client claude prints the MCP config for a given client. It refers to the key through an environment variable and does not write the key into a file. TikHub's SDK has none of these. They target three fears people have when an AI agent calls an API for them. The agent can call the wrong thing, call too much, or leak the key into a file.

The two services take different approaches to remote MCP. TikHub splits by platform. Its MCP page and llms.txt give one address per platform, such as https://mcp.tikhub.io/tiktok/mcp, so you add one config entry for each platform you need. Its platforms list, readable without a token, gives the tool count for each server: 319 for Douyin and 163 for TikTok. The upside is that each endpoint is a tool of its own.

The downside is that the Douyin server alone shows the model 319 tool descriptions. We have one address, https://api.everyinfra.com/mcp, with 12 tools.

Every data capability goes through everyinfra_call_api with two arguments, platform and action, and the free everyinfra_list_capabilities tool finds capabilities first; tools/list totals 3,779 tokens. The MCP spec allows both designs. The current revision is dated July 28, 2026. Its transport section makes the protocol stateless. There is no initialize handshake and no session ID. With Streamable HTTP, each message is one HTTP POST to the same address, and each request carries its protocol version in _meta.

Our two MCP requests at 00:21:11 worked this way. We sent tools/list and then tools/call with no handshake, and both returned results. The authorization section builds on OAuth 2.1, but it states that authorization is OPTIONAL. The cost of a plain key is that the client cannot run a sign-in flow for you, so you paste the key yourself.

Neither service uses OAuth; both take a key in a request header. Here is a config example. Field names depend on your client, so check its docs, and keep the key in an environment variable:

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

Three live calls: curl, the Python SDK and MCP

To make "from a key to the first successful call" concrete, we picked three common reads that both services offer and used a different calling method for each. Each call reads one object: a TikTok profile, a Douyin video and a Xiaohongshu note. On our side these are tiktok/profile, douyin/video and xiaohongshu/note. In TikHub's docs the matching endpoints are tiktok/web/fetch_user_profile, douyin/web/fetch_one_video, and the endpoint its docs recommend first for notes, xiaohongshu/app_v2/get_image_note_detail.

The first call used curl. It went out at 00:18:54 Singapore time and came back 30 seconds later with the tiktok account: 96,500,000 followers and 1,514 videos, charged $0.000556. That matches the same account in TikHub's demo response, but TikHub's statsV2 gives the exact count (96,519,349) while we return a rounded number. If you need exact follower counts, TikHub is better here.

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"}}'

The second call used Python SDK 0.3.0. It went out at 00:20:19 Singapore time and returned in 27.4 seconds with a Douyin air fryer review video. The video had 33,693 likes and 2,101 comments, and the call cost $0.000556. The code is a few lines, and the key comes from an environment variable:

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"])

The third call went through remote MCP. At 00:21:11 Singapore time we sent tools/call for the tool everyinfra_call_api. It returned in 42.2 seconds with a Xiaohongshu note posted on October 25, 2026: 992 likes and 567 comments, charged $0.005556. The result.content[0].text field holds the same JSON as the REST call, including billing.

One point needs saying: all three successful calls were slow, 27 to 42 seconds. Our synchronous calls have an 85-second limit; a call that runs longer fails as a timeout and is not charged. For batches, our docs suggest adding "mode": "async" to get a job ID and fetch the result later. We had no TikHub token, so we could not time its real endpoints.

We only know that its demo endpoint answered in 0.65 seconds with a cached fixed object. The info block of its openapi.json gives a timeout setting of 30 to 60 seconds and suggests your own proxy for requests over 30 seconds. This article does not settle which service is faster.

Reading the response: where the data is and where the cost is

After the first success, the next question is how to parse the response, and the two wrappers differ a lot. Every TikHub endpoint shares one wrapper. From the ResponseModel in openapi.json and the demo response we counted 15 top-level fields. They are code, message, message_zh, request_id, support, time, time_stamp, time_zone, docs, cache_message, cache_message_zh, cache_url, router, params and data. The data sits in data, and its shape depends on the endpoint.

Most of the time it looks like the platform's own response. For a TikTok profile, for example, it sits under data.userInfo.user and data.userInfo.stats, with the platform's own camelCase names. The upside is completeness: you get whatever the platform returned. The cost is that every platform and every endpoint version needs its own parser.

TikHub's wrapper does not say what the call cost. Its docs say a call is billed when it returns 200. To see what you spent, you call its user endpoints. The TikHub-User-API group on the docs site has one for daily usage and one for calculating prices. EveryInfra's wrapper has id, platform, action, results, billing and quota.

The results field uses the field names from the catalog's response_fields; a TikTok profile has username, follower_count and video_count. billing.charged_usd is the US dollar amount this call actually cost, and balance_after_usd is the balance after it. In a batch you add up charged_usd to get the total; that is how we checked the cost of the three calls in this article.

A small price check

Two of our articles cover price in depth, so here we only put the three scenarios side by side. Each one reads a single object, so the price per 1,000 calls and the price per 1,000 results are the same number.

At list price TikHub costs 1.8 times as much as we do in all three scenarios, so we are about 44% lower. This matches the $0.000556 price tier in our catalog. TikHub is cheaper in two cases. The first is volume. TikHub's llms.txt describes a daily discount ladder that reaches half price above 30,000 calls a day. The TikTok profile endpoint allows discounts, so at the top tier it costs $0.50 per 1,000, below our $0.556.

The second is an undocumented endpoint. TikHub's price list has a v5 Xiaohongshu note endpoint at $0.001 per call. That is one tenth of the app V2 endpoint its docs recommend, and our price is 5.6 times this one. But v5 is not in openapi.json, so it has no parameter docs, and we cannot judge how stable it is. For the full price comparison, see TikHub pricing explained and the 37 Douyin capabilities priced one by one.

Your first bill should also count the calls that went wrong, and while you are learning an API there are usually many. Our call with no key at 00:18:54 and our wrong-parameter call at 00:19:24 Singapore time both returned errors with charged_usd at 0. We check parameters before we charge, so a misspelled name is never charged and then refunded. TikHub's FAQ says it bills "only successful requests". A request is billed when it returns 200, and failed requests are not charged. Prices run from $0.001 to $0.01 per request.

By that rule, 401, 403 and 422 errors cost nothing there either, although without a key we could not test it. The real difference is "200 with no data". We refund empty results under the same charge_id. We found no TikHub page that describes a refund for empty results, and its refund policy says top-ups are final.

So while an AI agent is trying parameters, error calls on either side probably cost nothing. The gap shows up on calls that succeed with nothing inside. A renamed account or a deleted video is an example, because the platform still answers 200. The more of those targets a batch has, the further the two bills drift apart.

When TikHub is the better choice

Without this section, the comparison above would not be fair. Every row below comes from the public material cited in this article.

TikHub has one more design that we lack. Each successful response carries a cache_url that reopens the raw JSON of that call for free for 24 hours. Its tutorials page says a parsing bug then does not cost a second call. A teammate can also reproduce what you saw. On our side you can look up a call record and its charge by request_id, but you cannot see the full response from that time.

In the other direction, we refund failures and empty results automatically and show response fields before the call. We also offer per-product switches on each key, cost estimates before sending, and breadth. Our catalog's 106 platforms include ecommerce, local reviews, maps and job sites as well as social media. TikHub's MCP platform list has 15 platforms plus an "Others" group. The catalog is the place to check the current list.

Choosing by situation

Here is the comparison turned into a few decisions. First, maybe you have settled on Python and need very specific endpoints from TikHub's 1,055, such as Xingtu or Douyin Index. If you can write a parser for each one, TikHub's Python SDK is a ready path. The docs are thick, but each endpoint page is detailed.

Second, if you write JavaScript, Go or Java, TikHub's SDKs will not help much, and on both sides you will send HTTP yourself. The difference is how much you must read first. Our per-platform catalog is about 1,870 tokens, and it tells you the response fields before the call. Third, if an AI agent will make the calls, three questions matter most.

Can it look up parameters and prices first? Does a wrong call cost money? Can it leak the key into a file?

In our test, our 401 and 422 cost nothing and told the agent what to do next. Our command line can also estimate the cost before it sends. TikHub's demo endpoints let an agent see one real response first, and its 401 carries the standard header. Fourth, you may make tens of thousands of calls a day to one endpoint that allows discounts.

Or you may accept an endpoint that has a price but no docs. In both cases TikHub's unit price can be lower. Run your numbers against its price list before you decide.

Recent changes, October to November 2026

• November 3, 2026: TikHub's openapi.json has 1,058 paths, 2 more than on November 2, still labeled V5.3.2. What it means for you: if you generate or sync an SDK from it, do not rely on the version number to detect changes.
• November 1, 2026: EveryInfra's Python and npm SDK 0.3.0 shipped, and the catalog grew from 91 to 106 platforms the same day. What it means for you: check the SDK type list against the live catalog; in our test this version matched.
• October 28, 2026: GitHub push protection can now block AI-detected secrets. It is a public preview, off by default, and only for organizations with Secret Protection or Advanced Security. What it means for you: a key with no fixed format can now be stopped at push time. But the organization must turn this on. In a personal repo, you still must keep the key out yourself.
• October 20, 2026: GitHub's custom pattern API for secret scanning now returns 422 instead of 500 for invalid arguments. Callers can now tell input errors from server errors. What it means for you: on TikHub and on our API, write retries the same way. Fix the request on a 4xx, and retry only on a 5xx. Both services use 422 for bad parameters.
• October 13, 2026: GitHub described its new secret detection model. Regex rules first collect candidates, then a small model reads the file path, variable names and nearby code. User acceptance went up 11.5% and the median scan time went down 86%. What it means for you: keys with no fixed prefix are getting easier to catch. But the safest key is still one that never enters the repo.

FAQ

The questions come from Google search suggestions for these keywords and from forum posts, read on November 3, 2026. Each answer names its source.

Where do I create a tikhub api key?

Log in at user.tikhub.io, open the user center and create a token in the API token menu. The steps are in the "Get API Token" section of the docs README (suggestion: "tikhub api key", "tikhub api token"). Confirm your email first, or calls return 403. Each user can create up to 100 keys. Keys for the AI proxy at ai.tikhub.io are a separate set and do not open the data endpoints.

What is the difference between the tikhub api doc site and Swagger?

They show the same openapi.json (suggestion: "tikhub api doc", "api tikhub io"). docs.tikhub.io has one page per endpoint and is best for looking up parameters. api.tikhub.io is a Swagger page where you can paste a token and try a call; paste it without the "Bearer" prefix. Neither lists the response fields of most endpoints, because 1,052 endpoints document only the generic wrapper, so you learn the fields by calling.

Which SDK on tikhub github still works?

The Python SDK (suggestion: "tikhub github", "tiktok api python github"). Version 2.2.0 from October 3 covers 99.2% of today's endpoints. The TypeScript, Go, Java and C++ SDKs have not changed since March 2025 and cover 32.3%. They contain 245 methods whose endpoints are gone from the docs. In those languages, plain HTTP is the safer choice.

Is there a TikTok API documentation with Python examples?

Yes, on both sides (suggestion: "tiktok api documentation python"). TikHub's tutorials page has Python, JavaScript, Go, Java, PHP and cURL samples, and its Python SDK README shows calls by resource name. Our docs have curl examples, and pip install everyinfra gives you a typed client. The short example above is the whole first call.

Does TikTok have an API, and is there a free tiktok api key?

TikTok has its own APIs, but with limits (suggestion: "does tiktok have an api", "tiktok api key free"). The Display API, updated on August 4, 2026, reads only the profile and videos of a user who authorized your app. The Research API needs an application from a qualifying research body. To read public accounts and other people's videos, you need a third-party API. Most offer a small trial: TikHub adds $0.05, and we give $1 for starring two repos, valid for 24 hours.

Can I use TikHub with Claude or n8n?

Yes. TikHub runs one MCP server per platform and has a Claude Code plugin repo and an n8n integration repo (source: TikHub's MCP page and GitHub). TikHub's own account also posted a Claude, n8n and TikHub workflow on Reddit. Note that the n8n repo had its last push 393 days ago. Our remote MCP server works in any client that supports remote MCP with a header, and the config example above is all you need.

Is TikHub legit?

A Reddit user asked "Is TikHub AI legit" (r/Seedance_AI thread), and the replies gave no clear answer. TikHub's tutorials page says it provides only public data and does not own it. Its refund policy says sales are final unless an endpoint truly does not work. We do not judge its compliance. We suggest that you try the demo endpoints and the $0.05 credit first, then decide how much to top up.

Getting started

1. Find the capability you need in the capability catalog or the infrastructure market, for example tiktok/profile. Check its parameters, response fields and price. No key is needed.
2. Sign up and create a key in the console. The full key is shown once, so store it in the environment variable EVERYINFRA_API_KEY.
3. Send your first request with the curl example in the docs quickstart. You can also run pip install everyinfra and use the SDK, or paste the MCP config above into your client. Read billing.charged_usd in the response.
4. If you get a 401 or 422, read next_steps in the response first. For more platforms, see the TikTok, Douyin and Xiaohongshu pages and the MCP setup guide.

References

1. Getting Started: First API Call in 4 Steps, TikHub, read 2026-11-03, https://tikhub.io/getting-started
2. Social Media API Tutorials and Code Examples, TikHub, read 2026-11-03, https://tikhub.io/tutorials
3. Pricing, TikHub, read 2026-11-03, https://tikhub.io/pricing
4. FAQ: Billing, Rate Limits and Platform Support, TikHub, read 2026-11-03, https://tikhub.io/faq
5. llms.txt, TikHub, read 2026-11-03, https://tikhub.io/llms.txt
6. llms-full.txt, TikHub, read 2026-11-03, https://tikhub.io/llms-full.txt
7. MCP Integration Guide, TikHub, read 2026-11-03, https://tikhub.io/mcp
8. Social Media API Reference, TikHub, read 2026-11-03, https://tikhub.io/api-reference
9. README - English, TikHub docs site, read 2026-11-03, https://docs.tikhub.io/4592766m0
10. README (Chinese edition), TikHub docs site, read 2026-11-03, https://docs.tikhub.io/4579297m0
11. Getting Started (merchant onboarding), TikHub docs site, read 2026-11-03, https://docs.tikhub.io/5432442m0
12. llms.txt (docs-site index), TikHub docs site, read 2026-11-03, https://docs.tikhub.io/llms.txt
13. Get user profile (TikTok Web API), TikHub docs site, read 2026-11-03, https://docs.tikhub.io/186826057e0
14. Demo: fixed TikTok user, TikHub docs site, read 2026-11-03, https://docs.tikhub.io/337619232e0
15. Get all endpoints information, TikHub docs site, read 2026-11-03, https://docs.tikhub.io/186826055e0
16. About TikHub AI API, TikHub docs site, read 2026-11-03, https://docs.tikhub.io/7781112m0
17. TikHub Refund Policy (updated 2026-07-20), TikHub docs site, read 2026-11-03, https://docs.tikhub.io/9453198m0
18. openapi.json (V5.3.2), TikHub, read 2026-11-03, https://api.tikhub.io/openapi.json
19. Swagger UI, TikHub, read 2026-11-03, https://api.tikhub.io/
20. Price list endpoint get_all_endpoints_info, TikHub, read 2026-11-03, https://api.tikhub.io/api/v1/tikhub/user/get_all_endpoints_info
21. Demo endpoint demo/tiktok/web/fetch_user_profile, TikHub, read 2026-11-03, https://api.tikhub.io/api/v1/demo/tiktok/web/fetch_user_profile
22. MCP platforms list, TikHub, read 2026-11-03, https://mcp.tikhub.io/platforms
23. TikHub GitHub organization, GitHub, read 2026-11-03, https://github.com/TikHub
24. TikHub-API-Python-SDK, GitHub, read 2026-11-03, https://github.com/TikHub/TikHub-API-Python-SDK
25. Commit 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, read 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 capability catalog, EveryInfra, read 2026-11-03, https://api.everyinfra.com/api/v1/social/catalog
40. EveryInfra capability catalog, compact=1, EveryInfra, read 2026-11-03, https://api.everyinfra.com/api/v1/social/catalog?compact=1
41. EveryInfra OpenAPI 2.0.0, EveryInfra, read 2026-11-03, https://api.everyinfra.com/openapi.json
42. EveryInfra llms.txt, EveryInfra, read 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 release 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, read 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, read 2026-11-03, https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
50. MCP specification: Authorization (2026-07-28), Model Context Protocol, read 2026-11-03, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
51. The /llms.txt file proposal, llmstxt.org, read 2026-11-03, https://llmstxt.org/
52. About secret scanning, GitHub Docs, read 2026-11-03, https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
53. Display API Overview (updated 2026-08-04), TikTok for Developers, https://developers.tiktok.com/doc/display-api-overview
54. Research API: access and eligibility, TikTok for Developers, read 2026-11-03, https://developers.tiktok.com/products/research-api/
55. DIY: turning a full API doc into a Claude Code skill (in Chinese), Juejin, read 2026-11-03, https://juejin.cn/post/7595096774546096137
56. Is TikHub AI legit and works?, Reddit r/Seedance_AI, read 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, read 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, read 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/