@supabase/server - v1.7.0
    Preparing search index...

    Interface ErrorResponseConfig

    Controls how much of an error goes in the response body. Accepted as errors by withSupabase and by every middleware that answers a request directly: withClaims, withRequiredClaims, withPostgresClient, withPostgresAdminClient and withOAuthProtectedResource.

    // Full payload: source, code, message, hint, docs, details
    withSupabase({ auth: 'user' }, handler)

    // Trimmed: code and message only
    withSupabase({ auth: 'user', errors: { detailed: false } }, handler)
    interface ErrorResponseConfig {
        detailed?: boolean;
    }
    Index

    Properties

    detailed?

    Properties

    detailed?: boolean

    Whether to include the diagnostic fields in the response body.

    hint names the likely misconfiguration, details reports the endpoint's accepted auth modes, which credential headers arrived, and the names of configured keys, and docs links the relevant reference. All three are aimed at whoever is building against the endpoint.

    Set to false to reduce the body to code and message alone. The x-supabase-server-error header and the HTTP status are unaffected, and message keeps its [@supabase/server] prefix — so the error stays traceable without the source field.

    This is a verbosity control, not a security boundary. code and message still describe the failure specifically (e.g. JWKS_NOT_CONFIGURED). Neither level ever includes key values or token payloads. To disclose nothing, format the response yourself with createSupabaseContext.

    true

    Settings

    Member Visibility

    On This Page

    Properties