Yes it changed in 1.3 to ID. We're making the same API call as the admin console does only we're doing it right after the user is created if they don't meet certain criteria in client. These are social logins.

We're using MySQL but that shouldn't matter. Perhaps something Keycloack server side is holding reference to the user. I'll try to provide more information in a few days but wasn't sure if anyone saw this behavior before.

Thanks,
Scott

On Tue, Jun 30, 2015 at 8:27 AM Marek Posolda <mposolda@redhat.com> wrote:
Hi Scott,

I've just tried this with latest Keycloak master and deleting the user
from admin console works fine (I used default JPA with HSQLDB database).

Can you also check with admin console? If deleting through admin console
works fine, then there is likely something bad in the way you're
invoking the REST endpoint.

BTV. in latest master you're supposed to invoke the REST endpoint with
user id instead of "username" as last parameter. But I am not sure if it
was really username in 1.2.0 and it changed to ID in latest version...

Marek


On 30.6.2015 04:57, Scott Rossillo wrote:
> In 1.2.0, an HTTP delete on “/auth/admin/realms/{realm}/users/{username}” returns a 200 OK, but the user still exists. A second call usually succeeds at actually deleting the user. Seems like a bug.
>
> Thoughts?
>
> ~ Scott
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev