Survey of API Limits Across 56 Business Systems Finds Half Do Not Disclose Upper Limits

According to a report by songchong on Qiita, a survey was conducted on the actual state of publicly available information directly related to the design and operation of API integrations, covering 56 business systems used in Japan. Published on September 1, 2026, the survey verified one by one from official documentation the upper limits on the number of calls, methods of announcing specification changes, disclosure of outage information, and availability of support channels. As a conclusion, only 28 of the 56 systems disclose an upper limit on calls per minute or per day, revealing that for the remaining half, the permissible frequency cannot be determined at the design stage.

“Only 28 out of 56 systems disclose the upper limit on the number of calls per minute or per day. Exactly half.”

This result shows that API integration is not complete at the point of connection, but is an area that presupposes ongoing maintenance. It also calls for a re-examination of the basis for maintenance costs in quotations, from the perspective of responding to changes in the counterparty’s specifications and operational constraints.

Overview of API Disclosure Across 56 Systems

The survey aggregated data from four perspectives: upper limits on the number of calls, notification of specification changes, disclosure of outage information, and availability of support channels. The results are as follows.

28 systems disclose an upper limit on the number of calls, equivalent to half of the total. Notification of specification changes could be confirmed in some form for 40 systems, disclosure of outage information for 51, and mention of a support channel for 55. Conversely, there are 28 systems for which the call limit could not be confirmed, 16 for which the means of notifying specification changes could not be confirmed, and 5 for which the method of disclosing outage information could not be confirmed.

The survey clearly defines that “no mention” is not synonymous with “no limits or outages exist.” It is a category indicating the fact that it could not be confirmed from publicly available materials, and it should be noted that undisclosed areas remain as uncertainties at the time of design.

The breakdown is further subdivided. For call limits, 18 systems were classified as “disclosed by count,” 4 as “unit other than count,” 6 as “stated only as determined by contract,” and 28 as “no mention.” For notification of specification changes, 4 were “deprecation date is set,” 10 were “means to track available,” 26 were “no means to track,” and 16 were “no mention.” For outage information, the composition was 22 with “dedicated page available,” 4 with “included in overall page,” 25 with “notices/emails,” and 5 with “no mention.” In every category, there is a significant difference in the granularity of information and its traceability.

Call Limits Vary in Units and Conditions

API rate limiting is a speed restriction to prevent server load caused by a large concentration of requests in a short period of time. When the limit is exceeded, it is common for the HTTP status code 429 Too Many Requests to be returned. A 429 is a signal indicating excessive call frequency and serves as a starting point for isolating the cause on the development side.

Even among the 18 systems classified as “disclosed by count” in this survey, the units are not standardized. Looking at the specific examples presented in the report by songchong on Qiita, the extent of the variation becomes clear.

board sets a composite limit of 3,000 requests per day, 3 requests per second, and up to 4 concurrent requests for the list retrieval API, and explicitly states that it does not accommodate limit increases. Google Workspace has different limits for each API and operation, with the default for the Directory API being 2,400 queries per minute per user per project. SmartHR imposes multi-layered limits of 5,000 per hour and 10 per second per access token, and 50,000 per minute per subdomain, and provides a mechanism to check the remaining count via response headers.

Money Forward Cloud Expense sets limits by plan: 300 per hour for Team, 3,600 per hour for Corporate, and unlimited for Enterprise, while noting the possibility of individual contact or forced suspension depending on load. HubSpot allows 110 requests per 10 seconds per target account for publicly distributed OAuth apps, and 250,000 to 1,000,000 per day per account, with increases possible via additional purchase. Salesforce Sales Cloud uses a method where the total allowance for 24 hours is determined by edition and number of licenses; for Enterprise with 15 licenses, the limit is 115,000, calculated as 100,000 plus 15 × 1,000. It also notes a constraint of up to 25 concurrent requests taking 20 seconds or more in the production environment.

Meanwhile, Zoho CRM adopts a credit system rather than a count, adding a user-proportional amount to 5,000 for the free version and 50,000 for the paid version per 24-hour period. Shopify adopts a leaky bucket method that limits based on processing weight rather than count, with a design where GraphQL has an upper limit of 1,000 points per call and bulk processing uses Bulk operations that are exempt from the limit.

“They are all different. In other words, the upper limits of different services cannot be simply compared by the size of the numbers.”

As this observation indicates, because different denominators such as per day, per second, per minute, per 10 seconds, per 24 hours, credits, and points are mixed, a simple numerical comparison is not valid. At the time of design, it is necessary to interpret the definition of each service individually.

Furthermore, the 6 systems classified as “stated only as determined by contract” only state that the limit is determined by plan or edition, without disclosing specific numbers. A structure where the upper limit is only revealed after the contract is signed directly affects the accuracy of estimates and processing design.

Whether the upper limit can be raised also differs by service. HubSpot allows increases via additional purchase, board explicitly states it does not accommodate limit relaxation, and Google Workspace states that limits per Workspace account cannot be raised. Whether the disclosed figure is a fixed value or may vary through negotiation or additional fees is also an element that should be confirmed as part of operational planning.

Disclosure of Specification Changes and

Outage Information

Notifications of specification changes were divided into four levels. The easiest for maintenance planning are the 4 systems classified as “Type 1: Deprecation date is set,” where the cutoff is indicated by date or version, making it clear by when action must be taken. Next, the 10 systems classified as “Type 2: Means to track available” have channels in place to detect changes via update histories, RSS, GitHub, etc.

On the other hand, the largest group, the 26 systems classified as “Type 3: No means to track,” have a policy or version notation, but no specific means to track changes can be discerned from the specifications. The 16 systems with “no mention” are those for which the frequency of changes or the notification method itself could not be confirmed in public materials. The fact that nearly half are in a state that is difficult to track proactively is a factor that increases the maintenance burden after integration.

The situation is somewhat different for outage information. 22 systems publish a dedicated page, including examples that list the API as an independent item. 4 provide it as part of a dashboard for the entire service, and 25 use an operational model of notifying via a news section or email. For the latter group without a dedicated page, it is difficult to incorporate mechanical monitoring or automatic detection, leading to situations that depend on polling or manual checks on the operational side. There were 5 systems for which the method of disclosing outage information could not be confirmed in public materials.

For support channels, a mention was confirmed for 55 systems, meaning almost all services provide a contact route. However, the presence of a support channel does not necessarily correlate with the degree of disclosure of detailed information regarding rate limits or specification changes.

Basis for Maintenance Costs and Design

Considerations

The survey organizes post-integration events into three categories: hitting the call limit, specification changes, and the counterparty’s system going down. In the report by songchong on Qiita, the last of these — “the counterparty’s system going down” — is defined as an outage and positioned as a mode of failure within the measure of stability.

The response to each differs. For hitting the call limit, controls such as designing call frequency, retry intervals, queuing, and batch splitting are required. For specification changes, monitoring deprecation notices, planning version migrations, and modifications to maintain compatibility are necessary. For outages, operational design is required, including grasping the counterparty’s operational status, retries and fallbacks, and notifying users.

None of these are tasks that end once built; continuous handling premised on changes and outages on the counterparty’s side is essential. As the survey results show, in an environment where the units for limits are inconsistent and there is variation in notification methods and the availability of outage pages, it is important to scrutinize publicly available information before design and to confirm unclear points as contractual conditions. It is appropriate to view maintenance costs in quotations as expenses for preparing for such uncertainties and for the series of tasks from change detection to modification, verification, and deployment.

In areas where public information is scarce, constraints may only become apparent through trial after implementation. Operational information such as the conditions for 429 errors, whether remaining counts are shown in headers, and whether limits can be raised needs to be supplemented not only with official materials but also by confirming behavior in a verification environment. For tracking specification changes as well, it is important to grasp in advance not only whether RSS or update histories are available, but also the granularity of notifications and the grace period until deprecation, in order to improve the accuracy of maintenance planning.

Editorial Opinion

In the short term, we expect to see a growing move to explicitly include the degree of disclosure of rate limits and change notifications as evaluation criteria in the quotation and design process for API integrations. The fact that half of the 56 systems do not disclose upper limits directly increases uncertainty in man-hour estimates. We assess that within 3 to 6 months, more development organizations will develop checklists for public information at the proposal stage and make pre-contract confirmation of limits mandatory.

In the long term, we believe the focus will be on whether standardization of information disclosure on the business system side progresses. The inconsistency of units and variation in notification methods is a structure that forces individual handling on the user side. From a 1- to 3-year perspective, we see the provision of dedicated status pages and machine-readable change histories becoming a competitive factor, with disclosure attitudes potentially influencing selection criteria.

As a question from the editorial team, there is the issue of how much the user side should cover through advance research. When public information is scarce, the choice is whether to require the upper limits and grace periods to be specified as contractual conditions, or to strengthen controls and monitoring on the implementation side. It seems the question is whether to redefine maintenance costs not as a fixed expense but as an operational design cost for absorbing changes on the counterparty’s side.

References

• “API連携、つながればOK？ 回数の壁・仕様変更・障害情報を業務システム56件で調べてみた”, by songchong — Qiita, 2026-09-01T19:08:55.000Z (ARR)
• Source URL: https://qiita.com/songchong/items/1a599320ecb21cc4dd05?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items