@lgriffin/esi.ts - EVE Online ESI API Client - v12.3.0
    Preparing search index...
    interface OperationMeta {
        operationId: string;
        method: "GET" | "POST" | "PUT" | "DELETE";
        path: string;
        scopes: readonly string[];
        pagination: OperationPagination;
        deprecated: boolean;
        deprecation?: OperationDeprecation;
        textResponse?: { accept: string };
        emptyWhenNoContent?: boolean;
        headers: readonly string[];
    }
    Index
    operationId: string
    method: "GET" | "POST" | "PUT" | "DELETE"
    path: string

    Path template with {name} placeholders, as in the spec.

    scopes: readonly string[]

    SSO scopes the spec's security block requires; empty for public routes.

    page: numbered pages counted by X-Pages. cursor: before/after tokens in the response body.

    deprecated: boolean

    The spec marks the operation deprecated: true.

    deprecation?: OperationDeprecation

    What the generator knows about a deprecated operation, beyond the spec's flag: why, what replaces it and when ESI stops serving it. Present on every operation the spec deprecates; the transport logs a warning on each call to an operation that carries it or has deprecated set.

    textResponse?: { accept: string }

    Read the body as text rather than JSON, asking for it with this Accept header. Set on the few ESI routes that are not JSON, such as meta/openapi.yaml.

    emptyWhenNoContent?: boolean

    The spec pairs a JSON 200 holding an array with a 204: ESI answers with no content (a 204, or a 200 with Content-Length: 0) when there is nothing to return, as for a public contract that expired or was accepted. The transport then resolves with [] (or yields nothing) instead of failing to parse.

    headers: readonly string[]

    Header parameters the spec accepts (X-Compatibility-Date, X-Tenant, If-None-Match and so on). They are client configuration, not call arguments: the transport supplies them.