Building
How to connect a Telegram bot to an external API
By the Botable team
A bot calls an external API from the server side, with the key held in an environment variable, results cached so repeated requests do not hit the provider, and a clear message to the user when the provider is unavailable.
Watch it
Giving your bot an API key without pasting it into the code: the agent asks for the value, it is stored as an environment variable, and the bot calls the outside service with it.
Read the transcript
Everything said in the video, in order.
A bot that only talks to Telegram is a small bot. The useful ones read a weather service, look up an order, or call a language model — and each of those needs a key that must not end up in the code.
Botable handles that inside the same chat you build in. Here is where a key goes, who gets to see it, and what a bot is allowed to install.
This is Lumen Support. It was built entirely in this thread, and connecting it to something outside Telegram is not a different kind of task — it is the next message.
You describe the outcome rather than the plumbing. No endpoint, no auth scheme, no library name. What should happen when someone sends an order number.
One earlier build in this thread already needed a credential. This is where most tools send you off to edit a file. Botable does not — it asks you here, and prints every step it took.
It names the exact variable it needs and where the key is issued, takes it in the message you are already reading, and carries on. No settings screen, no file to open.
What you type is written straight into the bot's own environment file on the server. The code refers to it by name, so the key is never a literal in a source file.
One line comes back to the agent — saved, use it by name — and the copy that carried it is deleted. The step reads Secret added, with the key name and nothing else.
The step above it is the check. It reads what is already in the environment first, so a key you handed over on an earlier build gets reused rather than asked for twice.
Most integrations need no new package at all. Every bot is handed an HTTP client, a scheduler, date helpers, and the database you are looking at, before a line of its own code runs.
When one genuinely is missing — HTML parsing, spreadsheets, image work, the OpenAI client — it is written into a package file and the runner installs it on the next reload. You never run a package manager.
A wrong or expired key does not fail while you build. It fails while the bot runs, and Logs is where that lands — live output with the errors in red, in the order they happened.
Ask for the integration, hand over the key once, and it stays out of the code. Start free at botable dot I O.
The short version
Connecting a Telegram bot to an external API is straightforward and has three failure modes worth designing against before writing any of it. Credentials belong on the server, in an environment variable, a key that reaches a chat message is a key that has been published, and screenshots travel. Caching is not an optimisation but a requirement: without it, a bot with a hundred users asking for the same weather calls the provider a hundred times, and free tiers are measured in requests per minute. Caching one response for a short window turns that into a single call. And every external call fails eventually, so the bot needs a timeout and a plain message saying the provider is unavailable. Silence is the worst outcome, because the user cannot distinguish a broken provider from a broken bot and will report the wrong thing.
Step by step
Where do API keys go?
In an environment variable or a secrets manager, read at startup and used only server-side. Never in the code, never in a message, never in a log line, logs get pasted into support threads more often than anyone expects.
Why is caching mandatory rather than optional?
Because identical requests multiply by your user count. Cache by the parameters of the request for a window that suits the data, a minute for prices, an hour for weather, a day for reference data. One cached response serving fifty users is the difference between a free tier that works and one that is exhausted by lunchtime.
How should a failing API be handled?
Time out fast, retry once at most for a transient error, and then tell the user plainly that the data source is unavailable and to try shortly. Serving a stale cached value with a note about its age is often better than an error, an old price with a timestamp beats no price.
What about APIs that push instead of being polled?
Expose an endpoint the provider posts to and have the bot relay it, which is instant and costs nothing while idle. Verify a shared secret on every incoming request, because a public endpoint that relays into your chat is an open pipe otherwise.
What catches people out
- One uncached lookup per user multiplies your request count by your audience
- A silent failure is indistinguishable from a broken bot; always say something
- Log lines containing keys end up in support threads, redact before you log
Questions
Can a bot call an API that needs OAuth?
Yes, but the user has to authorise it, which means a web step outside the chat and somewhere to store the resulting token per user. That is a materially bigger build than a shared API key and worth scoping deliberately.
What if the API is slow?
Acknowledge immediately, a short "fetching…" that you then edit with the result, so the user is not staring at nothing. A reply that takes eight seconds with no acknowledgement reads as a failure.
Want a bot that does this?
Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you, the token, the webhook, the storage, the hosting.