Why are my results masked or placeholder text?#

Masked content is expected behaviour on a free plan or a test key — it is not an error. When the article body, description and URLs come back cut short and end with ...[Upgrade subscription plan] or ...[Test mode — use a live key for full content], the API matched real articles and returned them, but trimmed the long text fields to a preview. The fix is to use a live key (prefix api_live_) on a paid plan; that returns the full body. Your request still succeeded — the HTTP status is 200, the article count and metadata are real, only the long text is shortened.

{
    "title": "Apple reports record quarterly revenue",
    "description": "Apple posted its strongest December quarter to date, driven by...[Upgrade subscription plan]",
    "body": "Apple Inc. said on Thursday that revenue rose across every product...(+1962 chars hidden)...[Upgrade subscription plan]",
    "href": "https://ww...(+41 chars hidden)...[Upgrade subscription plan]"
}

What triggers content masking?#

Two conditions trigger masking, and only these two: your key belongs to the free subscription plan, or your key is a test key. A live key on any paid plan returns full content. The server applies the exact same trimming in both cases — the only difference is the marker text it leaves behind.

• Free plan — content is trimmed and tagged with [Upgrade subscription plan].
• Test key — the same trim, tagged with [Test mode — use a live key for full content].

A test key is recognised purely by its prefix: anything starting with api_test_ is a test key. Test keys are deliberately useful for wiring up integrations — they do not consume your request quota and never hit the out-of-credits error — but they always preview the content. A live key starts with api_live_.

Which fields are masked and which stay full?#

Only the long free-text and URL fields are previewed. The structured metadata that you usually filter and sort on is returned in full, even on a free plan or test key, so you can still build and test most of an integration without a paid key.

Trimmed to a preview:

• body and body_html — cut to the first 200 characters, then the marker is appended.
• description — cut to the first 200 characters, then the marker.
• href, image, link and media URLs, and the source domain — cut to a few characters with a ...(+N chars hidden) note before the marker.

Returned in full (never masked):

• title — the headline is always complete.
• entities (people, companies, locations), categories, topics and industries.
• sentiment scores, published_at, language, country and the rest of the structured fields.

That split is why a masked response still looks mostly normal: the headline reads fine, the entity and sentiment data are real, and only the body and links are shortened.

How do I confirm it’s a key issue and not bad data?#

Read the response headers — the API tells you the key mode directly, so you do not have to guess from the body text. Every response includes:

• x-apitube-mode — test for a test key, live for a live key.
• x-subscription-plan — your plan, for example free or a paid tier.
• x-points-remaining — your remaining request quota.

If x-apitube-mode is test, you are using a test key; if x-subscription-plan is free, you are on the free plan. Either one explains the marker. You can see them with a verbose request:

curl -i "https://api.apitube.io/v1/news/everything?title=Apple&api_key=YOUR_API_KEY"

The -i flag prints the headers. Check x-apitube-mode and x-subscription-plan at the top before you read the body.

How do I get the full, unmasked content?#

Use a live key on a paid plan. Generate or copy your live key (it starts with api_live_) from the dashboard — see how to create, rename and revoke API keys — and send that key instead of the test key. On a paid plan the body, body_html, description and URLs come back complete, with no marker appended.

curl "https://api.apitube.io/v1/news/everything?title=Apple&api_key=api_live_YOUR_LIVE_KEY"

Masking is applied the same way across every delivery method, so switching to a live key fixes it everywhere: search endpoints, single-article lookups, exports, and the real-time SSE and WebSocket streams all preview content on a free plan or test key and return full content on a paid live key.

Common Questions#

• Is a masked result the same as an empty result?
• Do test keys cost a request or a credit?
• Why is the headline full but the body cut off?
• Does masking affect the streaming endpoints too?

Is a masked result the same as an empty result?#

No. A masked result still contains real articles — the results array is populated, the headline and metadata are present, and only the long text fields are previewed. An empty result is results: [] with no articles at all, which is a filter problem rather than a key problem. If you are unsure which one you are looking at, see why is my search returning no results.

Do test keys cost a request or a credit?#

No. A test key does not consume your request quota and never triggers the out-of-credits error, which is exactly why it is meant for development and wiring up integrations. The trade-off is that test keys always preview the content. When you need full article text, switch to a live key on a paid plan.

Why is the headline full but the body cut off?#

Because the title field is never masked — only the long free-text fields (body, body_html, description) and URLs are trimmed to a preview. So a masked article shows a complete, readable headline alongside a shortened body that ends with the upgrade or test-mode marker. That is normal masking behaviour, not a partial or corrupted record.

Does masking affect the streaming endpoints too?#

Yes. The same preview applies to the real-time SSE stream and the WebSocket stream when you connect with a free plan or a test key — each delivered article has its body, description and URLs trimmed and tagged with the marker. Connecting with a live key on a paid plan streams full content.