How to report a bug or request a feature#

To report a bug in the APITube News API, email [email protected] or open the live chat on this help center, and include the request that failed: the endpoint URL (with your key removed), the HTTP status code, and the ER… error identifier from the response. To request a feature, email [email protected] and describe what you want to do. There is no separate bug-tracker form or dashboard button — reports go to a person, so a clear, reproducible example gets you a faster answer.

Before you file a bug, it is worth a quick check that the failure is really a bug and not a key, quota, or rate-limit issue on your side — those are the most common “the API is broken” reports, and they have their own fixes.

How do you report a bug in the APITube API?#

Send a bug report to [email protected], the address for bug reports, feature requests, and new-source requests, or use the live chat widget available on this help center for a faster back-and-forth. There is no self-serve form: each report is read by the team, so the more precisely you describe the failing request, the quicker they can reproduce and fix it.

The single most useful thing you can attach is the exact request that failed, with the API key stripped out. Never paste a working key into an email or chat — replace it with YOUR_API_KEY. A report the team can copy, run, and see fail is worth far more than a description of the symptom.

What should you include in a bug report?#

Give the team everything needed to reproduce the failure in one message:

• The endpoint and full request — for example GET /v1/news/everything?title=election&language.code=en, with the key masked.
• The HTTP status code and ER… identifier — APITube returns a specific code (like ER0214 or ER0057) for client-side problems; the identifier tells the team exactly which check failed. See the full error-code reference.
• What you expected versus what you got — the actual response body, or the part of it that looks wrong.
• When it happened — an approximate timestamp helps correlate with logs. You can copy the failing call straight from your dashboard request logs.
• Whether it is reproducible — does it fail every time, or only sometimes?

A powerful debugging aid to run before reporting is the debug parameter. Set debug=1 and the response includes a user_input object that shows every parameter exactly as the API parsed it — the fastest way to catch a misspelled parameter or a URL-encoding problem that looks like an API bug:

curl "https://api.apitube.io/v1/news/everything?title=election&debug=1&api_key=YOUR_API_KEY"

Use debug=1 only while investigating, not in production. If the user_input object shows your parameter parsed differently than you intended, the fix is in your request, not the API. For more, see how to debug your API requests and the canonical debugging guide.

How do you request a new feature?#

Feature requests and product suggestions go to [email protected] — the same address that handles new-source requests. Describe the outcome you are after, not just the parameter you wish existed: what are you trying to build, and what is blocking you today? A concrete use case (“I need to filter articles by X so I can do Y”) gives the team the context to weigh it against their roadmap. There is no published turnaround, so treat the reply as the confirmation. If your request is specifically to add a publication to the index, follow the dedicated flow in how to request a new news source.

Is it actually a bug? Check these first#

Most reported “bugs” are configuration or account issues that resolve without a fix. Read the HTTP status code first — a 401, 402, 403, or 429 is on your side, not a platform fault, and each has a specific cause listed in the error-code reference. Three cases in particular are not bugs:

• Masked or placeholder article text. That is the test key or the Free plan truncating content for preview, working as designed — see why results are masked.
• A broad outage or 500 responses. Check the status page at status.apitube.io and ping the unauthenticated health endpoint (GET /ping, which answers pong) before reporting — a platform incident is already known, not something to file.
• A missing news source. If a domain returns ER0214, the site simply is not indexed yet; that is a source request to [email protected], not a bug.

Common Questions#

• Where do I report a bug versus a feature?
• Where do I report a bug in an APITube SDK?
• Is there a bug-tracker or feature-request board?
• How do I know if it is a real bug before reporting?

Where do I report a bug versus a feature?#

Report a bug — something returning the wrong result or failing when it should work — to [email protected] or the live chat, with the failing request attached. Send a feature request or product suggestion to the same address, [email protected], describing your use case. Both are handled by the team directly; there is no form to fill in.

Where do I report a bug in an APITube SDK?#

APITube publishes its open-source SDKs and examples on GitHub at github.com/apitube (for example the Node.js and PHP News API clients). If the bug is in a client library rather than the API itself, opening an issue on the relevant repository is the most direct route, because it reaches the code the team maintains. For a bug in the API’s behavior or data, email [email protected] instead.

Is there a bug-tracker or feature-request board?#

No public bug-tracker or feature-voting board is exposed. Bug reports and feature requests are both handled over email at [email protected] and through live chat, and library-specific issues go to the GitHub repositories. This is the same person-reviewed model APITube uses for adding new sources.

How do I know if it is a real bug before reporting?#

Read the response. A 4xx status with an ER… code is a client-side problem — a key, quota, scope, or parameter issue — and the error-code reference tells you which. Masked content means a test or Free-plan key, not a bug. A 500 across many requests points at the platform, so check status.apitube.io and GET /ping first. If the request is well-formed, returns a 500 on its own, or produces data that is clearly wrong, that is a genuine bug worth reporting.