Feedback Aide applies default quotas, also called limits, to the requests you send, the content you submit, and the credits you use. Unless otherwise noted, quotas apply to your consumer.

This article lists the default request rate and size limits for Feedback Aide endpoints.

Use it to design an integration that stays within these quotas and remains reliable when many learners submit responses at the same time.

The values shown are the current defaults. If your solution needs higher limits, contact Learnosity support.

How rate limiting works

Feedback Aide counts requests per consumer, per endpoint, in a fixed window of 5 seconds. When a window ends, the counter resets to zero and a new window begins.

• Endpoint counters: Each endpoint has its own counter, so requests to one endpoint don't use the allowance of another. An endpoint is a combination of HTTP method and path. For example, GET /api/sessions/{session_uuid} and POST /api/sessions/{session_uuid} are counted separately.
• When a request is counted: A request counts when it arrives, whether it later succeeds or fails.
• Streaming endpoints: A streaming request counts once, however long the stream stays open.
• Global limit: A global limit of 1,000 requests per second applies across all consumers. The health check endpoint is exempt.

[Note] The 429 example in the endpoint reference shows "Rate limit exceeded: 10 per 5 second" for every endpoint. This is the default for most endpoints, but the limit for /api/token is higher.

Default limits per endpoint

All values are requests per 5-second window.

GET requests, 10 each:

• /api/essays/models
• /api/sessions/{session_uuid}
• /api/sessions/{session_uuid}/grader-rating
• /api/shortresponse/models

PUT and PATCH requests, 10 each:

• /api/sessions/{session_uuid}/grader-rating

POST requests:

• /api/token: 100
• /api/essays/evaluate: 10
• /api/essays/evaluate/stream: 10
• /api/rubric-practice/evaluate/stream: 10
• /api/sessions/{session_uuid}: 10
• /api/shortresponse/evaluate: 10
• /api/shortresponse/evaluate/stream: 10
• /api/docx-to-html: 10
• /api/utility/docx-to-html: 10
• /api/utility/generate-transcript/{transcript_uuid}: 10
• /api/utility/extract-text/single-response/{text_uuid}: 10
• /api/audio/evaluate/stream: 10

When you exceed a limit

Feedback Aide returns HTTP status 429 and doesn't process the request. No credits are consumed for a rejected request.

To recover, wait for the next window and retry:

• Treat 429 as retryable, not as a failed evaluation.
• Wait before retrying. With the default window, a 5-second pause is enough. If several workers share one consumer, use exponential backoff with random jitter.
• Don't retry in a tight loop. Retries within the same window are rejected.
• Log the endpoint and timestamp of each 429 to find which part of your integration is exceeding limits.

Designing your integration to stay within limits

Bulk jobs that submit a whole class or cohort at once are the most likely to reach limits.

• Queue bulk submissions on your side and release them at no more than 2 per second per endpoint. For example, send one request every 500 milliseconds, or send 10 requests followed by a 5-second pause.
• Use one shared queue if several workers or servers use the same consumer, because they share one allowance.
• Request a token once and reuse it until it expires, instead of requesting a new token for each evaluation. Tokens are valid for 2 hours.
• Keep reads separate from submissions. Each endpoint has its own counter, so reading a session doesn’t use your evaluation allowance.
• Avoid polling for results. Use the streaming endpoints where available.

Requesting higher limits

Learnosity can raise the defaults for an individual consumer and endpoint. Contact Learnosity Support with:

• The consumer keys involved.
• The endpoints you expect to exceed the default on.
• Your expected peak rate, in requests per second, and your typical batch size.
• When the peak occurs, for example, end-of-term bulk marking.

Learnosity reviews each request individually. Contact Learnosity Support well before a live assessment so any change is in place and tested beforehand.