I'm not sure if you just didn't copy it or it's actually missing in the request, but you're missing the trailing } in the data. This is what it came out as when I tried to format the JSON.
{
"user": {
"name": "Mary Alvarez Nutting",
"sortable_name": "Alvarez Nutting Mary"
},
"pseudonym": {
"unique_id": "Mary_AlvarezNutting",
"sis_user_id": "1033587"
}I didn't try this with Guzzle, but when I added the } to the end, I was able to create a new user using a different REST client. It came back with a 200 OK.
I want to think that you're not generating the JSON manually, but using json_encode() so it would include the closing brace for you. But if you are manually generating that, don't.
I don't think that's the issue, because when I tried it with the missing }, I got a 422 unprocessable entity error instead. You were getting 400 bad request.
If the account was incorrect, you would get a 401 unauthorized error.
I was finally able to get 400 Bad request. Here's the full error I got -- yours was truncated. Note the "SIS ID is already in use" message.
{
"errors": {
"user": {
"pseudonyms": [
{
"attribute": "pseudonyms",
"type": "invalid",
"message": "invalid"
}
],
},
"pseudonym": {
"sis_user_id": [
{
"attribute": "sis_user_id",
"type": "taken",
"message": "SIS ID "1033587" is already in use"
}
],
},
"observee": {
}
}
}In my testing, I was able to successfully create the account. I then wanted to do more testing, so I went in and deleted the account. Yet the login still exists. When I search for it from the admin page, it doesn't come up. I can't find it by the SIS ID or by the unique_id for the pseudonym. If I try the API call to get the user information by the sis_login_id, it comes back as the resource not existing. The same failure happens for fetching the logins for that user. Luckily, I'm doing all my testing on the beta instance, so it will all disappear in a few days when it's reset.
Now, I didn't happen to write down the ID of the user the first time it was created, so I don't know the user_id to try and go through and delete the login. There is probably something I'm missing since I don't work on the admin side of the web interface that much, but to get the ID, I ran the users portion of the provisioning report.
There, I was able to ascertain the Canvas ID as 8694975.
That was not helpful. Searching by the Canvas user_id failed to turn up any results, either.
Finally, I created a SIS import for the users.csv
user_id,login_id,first_name,last_name,status,password,email
1033587,Mary_AlvarezNutting,Mary,Alvarez Nutting,active,,
After I imported that, I had Mary back.
I went into her user page to edit the login information. Since that's the primary login for her, I can't delete it, but I can remove the SIS ID.
Now, when I try to create the count, I still get a 400 bad request message, but with a different response.
{
"errors": {
"user": {
"pseudonyms": [
{
"attribute": "pseudonyms",
"type": "invalid",
"message": "invalid"
}
],
},
"pseudonym": {
"unique_id": [
{
"attribute": "unique_id",
"type": "taken",
"message": "ID already in use for this account and authentication provider"
}
],
},
"observee": {
}
}
}This time, the Mary_AlvarezNutting is already taken.
Basically, it looks like you might have already created the account and rather than trying to create it again, you need to move on to another account. If Mary's login is bad, then you can fix it, but you can't recreate it.
The SIS import trick does wonders though and let me do things I couldn't do through the API.
If that's not the issue, you need to look at that "truncated" part and figure out what is buried in there.
I hope you're doing all this in your beta instance as well. That's where you test things until you know they're working and then you move them into production.
The other thing I would recommend is adding the Authorization: Bearer to the header rather than including it in the query parameters. That wouldn't fix the error, but it's the recommended method.
