50,000 times a month? The API's excessive calls have finally been resolved.
Recently, a friend came to me and said he found a serious problem in the backstage of the flying book developer: /open-apis/bot/v3/info, this interface is called hundreds of times a minute, and 50,000 times a month it's going to run out!
How did you find out?
Friends in the "API Call Statistics" backstage of the Flying Book Developer saw an exceptionally high number of calls for this interface:
| Indicators | Value |
| Number of daily calls | 43200+ times |
| Call every minute | ~ 300 times |
| Estimated monthly consumption | Close to 50,000 times. |
He's gone: I'm a robot. How can I call so often?
The root causes of the problem
I ran OpenClaw's flybook extension code and found it in two places:
1. Status check trigger API call
The probeFeishu() function calls the botinfo interface for flying books every time you ask about robot status. This function is called in the following scenarios:
- Get OpenID on startup
- When external system query status
- When WebSocket is disconnected
2. Lack of a cache mechanism
The original code was "Ask every call", and there was no cache. Even if you ask for a state of 10 times, you will have 10 API calls.
Solutions: 5 minute cache mechanism
I added a simple cache to the probe.ts:
// 缓存配置：5分钟内不重复调用 API
const CACHE_TTL_MS = 5 * 60 * 1000;
const botInfoCache = new Map();The core logic is simple:
- First Call ♪ Request for flying books API ♪ Cache results
- Call again in 5 minutes. ○ Direct back cache (no new request initiated)
- The failure also clogged. → Avoid repeated requests when failure
Modified effects
| Contrast | Before Modify | modified |
|---|---|---|
| Every status query | Call API | Direct Cache |
| Failed to try again | Unlimited Retry | Cache 5 Minutes |
| Estimated monthly consumption | 50000+ times | ~ 300 times |
It's simple.: A maximum of 1 call per 5 minutes, 24 hours per day = 288 times/month, approximately 3,500 times a year. The original 50 grand/month limit, it's not gonna run out!
Apply scene
This programme is particularly suitable for:
- Users extended with OpenClaw
- Develop your own flying book robot and call the botinfo interface frequently
- The API scale is urgent and wants to optimize the number of calls
Summary
Flying Book API's over-allocation problem is essentially caused by the lack of a cache mechanism. The solution is simple: call the interface with a cache.
Sometimes the simplest optimization is the most effective.