Iskra API Reference
    Preparing search index...

    Interface RateLimitConfig

    interface RateLimitConfig {
        handler?: (c: Context) => Response;
        keyGenerator?: (c: Context) => string;
        max?: number;
        maxKeys?: number;
        name?: string;
        passOnStoreError?: boolean;
        skip?: (c: Context) => boolean;
        skipHealthChecks?: boolean;
        standardHeaders?: boolean;
        store?: "memory" | "cache";
        windowMs?: number;
    }
    Index
    handler? keyGenerator? max? maxKeys? name? passOnStoreError? skip? skipHealthChecks? standardHeaders? store? windowMs?
    handler?: (c: Context) => Response
    keyGenerator?: (c: Context) => string
    max?: number
    maxKeys?: number

    Most clients the memory store tracks at once (default 100 000). Past it the oldest are dropped, and they start a new window.

    name?: string

    Feature name, 'rate-limit' by default. Feature names are unique, so a second limiter (e.g. a stricter one for login) needs its own; its counters are kept apart from the other limiter's.

    passOnStoreError?: boolean

    What happens when the store fails (store: 'cache' with Redis down): true (default) lets the request through without a limit, logging an error at most once a minute; false answers 503 with Retry-After.

    skip?: (c: Context) => boolean
    skipHealthChecks?: boolean

    Leave the health feature's routes (/health, /health/ready, /health/live or the ones it is configured with) out of the limit (default true): orchestrator probes come often and from one IP.

    standardHeaders?: boolean
    store?: "memory" | "cache"
    windowMs?: number

    Settings
    Member Visibility

    On This Page
    Properties