You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/rest-api/overview.md
-42Lines changed: 0 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -148,48 +148,6 @@ HTTP/1.1 200 OK
148
148
You do not need to be authenticated to access this route.
149
149
:::
150
150
151
-
## Fair-usage protection
152
-
153
-
Our API facilitates the integration of Akeneo PIM with external systems. To maintain optimal user experience and platform stability, our platform employs various protection mechanisms to prevent over-usage.
154
-
Please adhere to the following usage guidelines:
155
-
156
-
### Maximum Concurrent API Calls
157
-
158
-
- Per PIM Connection: Up to 4 concurrent API calls are allowed for each individual PIM connection.
159
-
- Per PIM Instance: Up to 10 concurrent API calls are allowed across the entire PIM instance.
160
-
161
-
162
-
### Rate Limits Within a Specific Amount of Time
163
-
164
-
- General API Requests: up to 100 API requests per second per PIM instance.
165
-
-[updating & creating attribute options](https://api.akeneo.com/api-reference.html#patch_attributes__attribute_code__options): up to 3 API requests per second per PIM instance.
166
-
167
-
168
-
### Handling Over-Usage
169
-
170
-
If your API usage exceeds these limits, the platform’s protection mechanisms may be triggered, resulting in blocked requests and HTTP status code 429 responses.
171
-
As a REST API consumer, you have to keep in mind that your integration with Akeneo PIM should anticipate this throttling and should be able to handle failures.
172
-
173
-
Bursts are allowed, but continuous over-usage will trigger the protection sooner.
174
-
175
-
To effectively manage and mitigate over-usage, we recommend implementing the following strategies:
176
-
177
-
**Check for "Retry-After"**
178
-
179
-
If the HTTP 429 response includes a "Retry-After" header, wait the specified number of seconds before retrying.
180
-
181
-
**Implement Exponential Backoff**
182
-
183
-
Use increasing delays between retry attempts (e.g., 10s, 30s, 60s) to reduce the load on the API.
184
-
185
-
**Use Batch Endpoints**
186
-
187
-
Combine multiple requests into a single API call using batch endpoints to minimize the number of calls.
188
-
189
-
**Implement a Cache Layer**
190
-
191
-
Cache frequently accessed data on the client side to reduce repetitive API requests and improve response times.
0 commit comments