Top
Manual

Limitations / Precautions

Last updated: 2026/09/07

Limitations

Limitations Regarding the Management Screen

Data size per content: approximately 200KB
Input upper/lower limits for numeric fields: 9007199254740991 /-9007199254740991

Information

You can check the current data usage at the top of the editing screen under "Content Available Space."
The content size holds values for two states when it is "Published and Draft," making it the largest. In the cases of "Published," "Draft," and "Published End," it can hold approximately 400KB, which is double.
The calculation of content size also includes information stored in the database internally, such as field types and rich editor structure information.

Limitations Regarding the Content API

GET API rate limit (per service): 60 requests / 1 second
WRITE API (POST / PUT / PATCH / DELETE) rate limit (per service): 5 requests / 1 second

Information

The rate limit is counted as a total per service. The count is based on the number of accesses to the origin. Responses from the Content API are sent via the CDN, so if they are returned from the edge server's cache, they will not count towards the limit. (For conditions on cache usage, please refer to the help.)
Due to the multi-tenant system, even if you are within the rate limit, you may occasionally receive status code 429 (Too Many Requests) or 500 series errors depending on the overall request situation. Implementing retry logic can reduce the occurrence of these errors. For more details, please refer to the help.
Since a Web Application Firewall (WAF) is in place, requests deemed malicious may be blocked regardless of the rate limit.
If the rate limit is exceeded, status code 429 (Too Many Requests) will be returned. In that case, the API response will include the following headers.

X-RateLimit-Limit: 60 # Number of requests allowed per second
X-RateLimit-Remaining: 13 # Number of remaining requests allowed
X-RateLimit-Reset: 1648014262 # Time when the request count will be reset (UNIX time)

Maximum request body size for POST / PUT API: approximately 300KB
Maximum request body size for PATCH API: approximately 90KB
Maximum length of request URL: 8KB
Maximum response size: approximately 5MB
Maximum response time: approximately 29 seconds

Information

If the maximum response time is exceeded for requests with complex filtering conditions, a 500 series status code error will be returned.

Limitations of the Management API (Beta)

Rate limit (per IP address): 10 requests / 10 seconds

Information

The rate limit is counted based on the total per IP address. Responses from the Management API are counted directly as they do not go through the CDN.
Due to the multi-tenant system, even if you are within the rate limit, you may occasionally receive status codes 429 (Too Many Requests) or 500 series errors depending on the overall request situation. Implementing retry logic can reduce the occurrence of these errors. For more details, please refer to the help.
Since a WAF (Web Application Firewall) is implemented, requests deemed malicious may be blocked regardless of the rate limit.
If the rate limit is exceeded, a status code 429 (Too Many Requests) will be returned.
As this is a beta version, additional constraints may be added as necessary.

Limitations Vary by Pricing Plan

The following items have different limitations depending on the pricing plan you are using.
Please check the Pricing Plan page for more details.

Data Transfer Amount
Number of Members
Number of APIs
Number of API Keys
Number of Contents
Number of Views
CSV Import Count
Capacity per Media
Number of IP Restrictions (Administration console)
Number of IP Restrictions (API) per API

Items Without Set Limitations

microCMS has items that do not have specific limitations. Examples include the following:

Number of Services
Number of Fields
Number of Custom Fields
Number of Items in Selectable Fields
Number of Roles
Number of Media
Number of Members (maximum when exceeded)
Number of APIs (maximum when exceeded)
Number of Content Update Histories Displayed

While we have confirmed that these values generally do not pose issues within typical usage, setting significantly higher numbers than expected may lead to cases where normal operation is not guaranteed.

If you encounter any problems, we kindly ask you to contact us via the chat section at the bottom right of the screen.

Note (Regarding API Schema Saving)

Depending on the type of fields and the structure of repeat fields, you may see a message stating "The number of schema fields exceeds the limit" when saving the API schema, which may prevent saving.
If an error occurs, please consider removing unnecessary fields or reviewing the structure.

Important Notes

Beta Features

Beta features may be less stable than regular features. Additionally, there is a higher likelihood of disruptive changes that do not maintain compatibility compared to features in the stable version.

When using these features, please consider the risks of potential instability and changes before making your decision.

Currently Available Beta Features

SDK Maintenance Policy

microCMS classifies SDK maintenance levels into three categories.
When using each SDK, please check the scope of support for each maintenance level before deciding on usage.
Additionally, maintenance levels are not fixed and may change based on usage and maintenance structure.

Active

Active is the SDK recommended for new use.

It includes bug fixes, security updates, and compliance with changes in the microCMS core specifications. It also ensures compatibility with LTS versions of target languages, runtimes, and frameworks, keeping the README and related documentation up to date.

As needed, it will also include feature additions, usability improvements, and updates to dependent libraries.

Maintenance

Maintenance is the SDK that maintains basic functionality for existing users.

It includes bug fixes, security updates, and compliance with changes in the microCMS core specifications. It also ensures compatibility with LTS versions of target languages, runtimes, and frameworks, keeping the README and related documentation up to date.

If there are disruptive changes in the microCMS core, it will respond as necessary. Updates to dependent libraries will occur if there are security issues or bugs related to SDK usage.

However, new feature additions and usability improvements will generally not be made. Updates to sample code or dependent libraries used only during development will be handled on a best-effort basis.

Deprecated

Deprecated is the SDK not recommended for new use.

As a rule, it will not include bug fixes, security updates, feature additions, usability improvements, or compliance with changes in the microCMS core specifications. Additionally, it will not generally comply with the latest versions of target languages, runtimes, and frameworks.

For new development, please consider using alternative solutions.

Items Without Detailed Descriptions

microCMS has items that do not have detailed descriptions. Examples include the following:

API Response Headers
Status Codes for API Errors
Webhook Request Headers

For these items, we assume operation in accordance with standard specifications of various technologies such as Web, Internet, and HTTP. Additionally, there may be changes in operation within the scope of compliance with specifications.

If you have any questions, please contact us via the chat section at the bottom right of the screen.

Contents

Limitations
Limitations Regarding the Management Screen
Limitations Regarding the Content API
Limitations of the Management API (Beta)
Limitations Vary by Pricing Plan
Items Without Set Limitations
Important Notes
Beta Features
SDK Maintenance Policy
Items Without Detailed Descriptions