Service status
Two things answer the question without waiting for us: the health route and the counters on your own responses.
Check the API yourself
One unauthenticated-looking call, the same two headers as any other request, and no quota worth speaking of:
curl -s https://telegram155.p.rapidapi.com/health \
-H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
-H "X-RapidAPI-Host: telegram155.p.rapidapi.com"{"status":"ok"}That is the whole response. It touches the upstream session, so a 200 here means the protocol layer is up, not merely that a web server answered.
Your quota is in every response
Every call comes back with its own metering, so you never have to guess how much of your plan is left:
| Header | What it tells you |
|---|---|
x-ratelimit-requests-limit | Calls your plan allows this month |
x-ratelimit-requests-remaining | Calls left, after the one you just made |
x-ratelimit-requests-reset | Seconds until the counter rolls over |
x-ratelimit-lookups-limit / -remaining | The separate discovery counter, spent by the four search routes: /v1/usernames/{username}, /v1/contacts/search, /v1/messages/search and /v1/channels/recommendations |
x-ratelimit-resolve-phone-number-endpoint-limit / -remaining | The phone-resolution counter, metered on its own |
Header names read exactly as printed; they arrive on every response, including /health. Which counter each route spends was measured route by route on 16 September 2026 at 07:22 UTC against the live API: reading a channel — /v1/channels/{peer_id} and /v1/peers/{peer_id}/history — spends no lookup at all.
Plan, billing and key state
Subscription, invoices and your key itself live on the RapidAPI listing, and that dashboard is the authority on all three. Rotating or revoking a key happens there and takes effect immediately.
Plans and what each one includes are on /pricing. Changes to the API are listed on /changelog.
Something is wrong and it is not your quota
Every non-2xx response carries a machine-readable code — the full list is in the error reference. If the behaviour contradicts the specification, that is a bug worth an email: starnikovoleg@gmail.com.