Currently, this can be safely achieved by replacing ctx.telegram.callApi in every request (see https://github.com/KnightNiwrem/telegraf-throttler/blob/master/src/index.ts), but I agree that it'd be nice to have a proper API for it.

Yes i know and I'm using this method

This will be a significant internal change (I'd expect it to ship in 4.2 5.0).

We will need a proposal, so here's mine. To keep the discussion manageable, please post any concerns about my proposal as a reply to this, and any alternatives as a standalone comment, so it can be discussed separately.

ApiClient already contains a lot of complexity. Let's wrap it instead of adding more.

interface ApiClientInterface {
  callApi: <M extends keyof Telegram>(
    method: M,
    payload: Opts<M>,
    { signal, response }: ApiClient.CallApiOptions = {}
  ) => Promise<ReturnType<Telegram[M]>>
}

type Interceptor = (client: ApiClientInterface) => ApiClientInterface

ApiClient would ignore response, but an interceptor could use it to perform webhookReply.

It'd be great if some way to access response headers (Date to be specific ) was introduced.

Breaking: Telegram would need to accept and contain ApiClientInterface rather than accept token and inherit from ApiClient.

Breaking: that breaks Telegram::getFileLink, so it needs to be replaced with something. cc @AndrewLaneX

This decoupling would allow to write MockApiClient (#224).

bot.intercept(interceptor) would apply the interceptor to bot.telegram and all future ctx.telegrams.

In case anyone is still interested in this, an alternative package that I created (called grammY) features exactly what this discussion is asking for.

https://grammy.dev