Skip to content

Rate Limits and Fair Use

To ensure platform stability and fair usage across tenants, Minyu enforces explicit rate limits on API access. These limits are enforced at request time and apply to all API consumers.

Rate limits are independent of usage-based credits and are designed to protect the platform from excessive or abusive request patterns.

When rate limits apply

Rate limits are evaluated per tenant and apply to all API queries, all API mutations, and all read and write operations, regardless of request shape.

Limits are enforced continuously using rolling time windows.

Requests per second

Request rate limits control how frequently the API may be called.

Default limit: - 10 requests per second per tenant

This limit protects the platform from tight loops, misconfigured clients, excessive connection churn, and accidental request storms.

Short bursts above the limit may be tolerated, but sustained higher request rates are rejected.

Requests per hour

In addition to per-second limits, Minyu enforces a maximum number of API requests per hour.

Default limit: - 10,000 requests per hour per tenant

This limit prevents sustained background usage patterns that continuously load the system over long periods of time, even when per-second limits are respected.

Hourly limits reset automatically and apply regardless of request type.

Request execution time limits

In addition to request rate limits, Minyu enforces a maximum execution time per request.

Default limit: - 5 seconds per request

Requests that exceed this limit are terminated automatically.

This protects the platform from:

  • Long-running or unbounded queries
  • Inefficient bulk operations
  • Requests that hold resources for extended periods

Clients should design requests to complete well within this limit.

What rate limits do and do not protect against

Rate limits are designed to limit how often the API is called and how long individual requests may run.

They do not:

  • Limit how much data a single request may return
  • Prevent inefficient or overly broad queries
  • Replace usage-based pricing or credits

As a result, a small number of requests may still process large amounts of data. This is intentional and handled through usage-based pricing rather than request throttling.

Relationship to usage-based pricing

Usage-based credits control how much data may be processed over time.
Rate limits control how frequently requests may be made.

These mechanisms operate independently.

Having available credits does not bypass request rate limits.
Staying within request rate limits does not guarantee sufficient credits are available.

Usage is reconciled separately from request execution.

What happens when limits are exceeded

If a rate limit is exceeded:

  • The request is rejected with a rate-limit error
  • No partial mutations are applied
  • The client must retry after a delay

Repeated or sustained violations may result in temporary blocking to protect system stability.

To build reliable integrations:

  • Avoid tight polling loops
  • Avoid repeated full-table reads on fixed schedules
  • Prefer queries constrained by timestamps, status, or other business filters
  • Use Minyu’s notification system to react to changes instead of polling the API
  • Batch writes sensibly instead of issuing many small requests

These patterns reduce load, lower costs, and improve overall reliability.

Summary

  • Per-second limits control short-term bursts
  • Execution time limits control request cost
  • Hourly limits control sustained usage
  • Usage-based credits control total data volume

All mechanisms apply independently.