stalwartlabs/stalwart · error · ScimError

The HTTP method is not supported by this endpoint, allowed…

Error message

The HTTP method is not supported by this endpoint, allowed methods are {allow}.

What it means

A SCIM 405 error built by `method_not_allowed(allow)` in crates/scim/src/request.rs. It is returned when an HTTP method is routed to a SCIM endpoint that does not support it, and the Allow variant also advertises the permitted methods via the HTTP Allow header.

Solutions

Use only the methods listed in the error detail / Allow header for that endpoint (e.g. GET/PUT/PATCH/DELETE on /Users/{id}; POST only on /Users).
Fix the client's request builder so the method matches the operation semantics (create = POST to collection, update = PUT/PATCH to resource).
Check RFC 7644 section 3 for the per-endpoint method matrix before integrating a new endpoint.

Example fix

// before
client.request(Method::POST, "/Users/2819c223...").body(user).send().await?;
// after
client.request(Method::PUT, "/Users/2819c223...").body(user).send().await?;

Defensive patterns

Strategy: validation

Validate before calling

const ENDPOINT_METHODS: &[(&str, &[Method])] = &[
    ("/Users", &[Method::GET, Method::POST]),
    ("/Users/{id}", &[Method::GET, Method::PUT, Method::PATCH, Method::DELETE]),
];
assert!(allowed_methods_for(path).contains(&method), "unsupported method for {path}");

Prevention

Encode the RFC 7644 method-per-endpoint matrix in your client wrapper.
Parse the Allow header on 405 responses to self-correct.
Use distinct helper functions per operation (create/update/delete) so methods can't be mixed up.

When it happens

Trigger: `dispatch_scim_request` matches a valid SCIM path but the request's HTTP method is not one the endpoint supports (e.g. DELETE on /Users, POST on /Users/{id}, or PUT on /ServiceProviderConfig), so it calls this constructor with the allowed method list.

Common situations: A client uses PUT to update part of a user where only PATCH/PUT-on-full-resource is allowed; sending POST to an individual resource URL instead of the collection; automation scripts reusing the wrong method for an endpoint.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

AI-assisted analysis of stalwartlabs/stalwart@e962003857 (2026-09-06). Data as JSON: /api/errors/cfc3a71e23d2b3cb. Report an issue: GitHub.

Appendix: source

Thrown at crates/scim/src/request.rs:281

    fetch_body(req, max_size, session.session_id)
        .await
        .ok_or_else(|| {
            ScimResponseError::Scim(Error::new(413).with_detail(format!(
                "The size of the request payload exceeds the maximum of {max_size} bytes."
            )))
        })
}

pub fn search_request(query: Option<&str>) -> Result<SearchRequest<'_>> {
    match query {
        Some(query) => SearchRequest::from_query(query).map_err(Into::into),
        None => Ok(SearchRequest::default()),
    }
}

pub fn method_not_allowed(allow: &'static str) -> ScimResponseError {
    ScimResponseError::Allow(
        Error::new(405).with_detail(format!(
            "The HTTP method is not supported by this endpoint, allowed methods are {allow}."
        )),
        allow,
    )
}

fn assert_unfiltered(req: &HttpRequest) -> Result<()> {
    if SearchRequest::from_query(req.uri().query().unwrap_or_default())
        .is_ok_and(|request| request.filter.is_some())
    {
        Err(Error::forbidden(
            "The discovery endpoints do not support filtering, remove the 'filter' parameter.",
        )
        .into())
    } else {
        Ok(())
    }
}

View on GitHub (pinned to e962003857)