andygunther | 2017-04-25 20:25:32 UTC | #1
Trying to use the API to create a user with this JSON body, and I'm getting a 400 back. Can anyone see what I'm doing wrong here? There are no details in the response body like I've seen in other 400 messages coming back:
{ "name":"API Test Account", "department":"API Department", "email":"abc@brighthorizons.com", "addresses":[ { "address":"abc@brighthorizons.com", "mediaType":"EMAIL", "type":"PRIMARY" }, { "address":"(42197)", "mediaType":"PHONE", "type":"PRIMARY" }, { "address":"+17209222976", "mediaType":"PHONE", "type":"WORK2" }], "title":"API Title", "password":"Welcome123!" }
tim.smith | 2017-04-25 20:32:27 UTC | #2
Can you provide the correlation ID from the response?
andygunther | 2017-04-25 20:46:17 UTC | #3
5928751c-b06a-49c9-a2a4-538c6567ab98
tim.smith | 2017-04-25 21:17:59 UTC | #4
I've created API-2528 to include the error information in the response.
The error you're getting is because of "type":"PRIMARY" on the addresses. If you change that to any other allowed type, the request should succeed. I'm not sure if that's helpful though since you probably need to be setting it as primary. I'm waiting on some further information to figure out what's causing that and will open a bug for it once it's tracked down, but wanted to let you know of a possible workaround now.
andygunther | 2017-04-25 21:30:05 UTC | #5
Thanks - I'll look to see how it gets set when someone clicks the Primary radio button. Maybe I can do them all as WORK, and then go back and UPDATE.
tim.smith | 2017-04-25 22:01:11 UTC | #6
Two things:
- There's no need to specify the email in the
addresses property. The email property already designates the user's primary email. - User extensions should be set by using the
extension property on a Contact (the members of the addresses array). However, the Contract object lacks that property. I've created API-2529 to add the extension property. That will be a quick fix, but won't be available until the next API deployment to prod.
andygunther | 2017-04-25 22:03:50 UTC | #7
So, with the fix for API-2529, this will be valid, correct?
{ "name":"API Test Account", "department":"API Department", "email":"abc@brighthorizons.com", "addresses":[ { "extension":"42197", "mediaType":"PHONE", "type":"PRIMARY" }, { "address":"+17209222976", "mediaType":"PHONE", "type":"WORK2" }], "title":"API Title", "password":"Welcome123!" }
tim.smith | 2017-04-25 22:06:10 UTC | #8
I believe so. The only ambiguity is what type should be. PRIMARY is an inferred value, so that may need to change to something else. I'll know for sure after the fix is in place and will update here.
andygunther | 2017-05-08 13:27:15 UTC | #9
Hey Tim,
Is there any update on this solution being available?
Thanks!
tim.smith | 2017-05-10 14:26:22 UTC | #10
The fix has been submitted and should be making it's way to production soon. Keep an eye out for the property to be added in the SDK release notes (readme in the repo).
tim.smith | 2017-05-23 14:01:15 UTC | #11
This fix has made it to prod. The developer center will be updated with the new docs this week. Here's the schema for the Contact object now:
"Contact": { "type": "object", "properties": { "address": { "type": "string", "description": "Email address or phone number for this contact type" }, "display": { "type": "string", "description": "Formatted version of the address property", "readOnly": true }, "mediaType": { "type": "string", "enum": [ "PHONE", "EMAIL", "SMS" ] }, "type": { "type": "string", "enum": [ "PRIMARY", "WORK", "WORK2", "WORK3", "WORK4", "HOME", "MOBILE", "MAIN" ] }, "extension": { "type": "string", "description": "Use extension instead of address for setting internal extensions" } }
andygunther | 2017-05-25 16:20:02 UTC | #12
Maybe I'm mis-reading this, but I'm getting a 400 back trying to update the extension for a user with this JSON:
{ "name":"Ronni Gee", "department":"CAM - Customer Service", "email":"rgee@cochlear.com", "addresses":[ {"extension":"8263"}, {"address":"+13032642863","mediaType":"PHONE","type":"WORK2"}], "version":12, "title":"Account Service Manager", "password":"xxxxxxxx" }
tim.smith | 2017-05-26 17:11:04 UTC | #13
I think the issue is that you need to specify mediaType and type along with extension. If you can provide a correlation ID, I can take a look (the fix for missing errors still isn't in prod yet).
andygunther | 2017-05-26 19:47:09 UTC | #14
Here you go.
inin-correlation-id: 366493ba-b7e4-44f1-bc7f-e45b378d9d10
URL: /api/v2/users/867d46b3-852a-4bb7-b322-4131bb91a3db
Body:
{ "name":"Robert Garza", "department":"CAM - Reimbursement", "email":"rgarza@cochlear.com", "addresses":[ { "extension":"8261", "mediaType":"PHONE", "type":"WORK"}, { "address":"+13032642161", "mediaType":"PHONE", "type":"WORK2"}], "title":"Test", "password":"Welcome1" }
tim.smith | 2017-05-26 19:49:18 UTC | #15
Make sure you include the entity's version when you update it.
Caught application error [API Exception 400:\"Bad Request\" : Validation error(s): [API Exception 400:\"Bad Request\" : Illegal value for field: version, Reason: Missing data for required field.]]
andygunther | 2017-05-26 19:49:47 UTC | #16
Oh, dang it! I knew that... Hold, please.
andygunther | 2017-05-26 19:50:44 UTC | #17
That was it, thanks!
andygunther | 2017-05-26 19:56:19 UTC | #18
Although, when I look at the user in admin, their contact info still doesn't look right... See screen shots in uploaded jpg.<img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/ceff67d26da0ab0688e70de40043bc6864839d4a.JPG" width="427" height="500">
tim.smith | 2017-05-31 14:12:36 UTC | #19
It looks like the extension isn't being saved quite correctly, so the UI is having a little trouble with it. I've opened API-2626 for this issue.
To work around, make your UI a little bigger and clear the first part of the phone number (it's populated with +1) and then you can edit the extension and save it.
andygunther | 2017-05-31 14:25:40 UTC | #20
The problem is that I have 150 users to update, which I plan to do with the API when it is working correctly. Can I do it as it sits today, or do I need to wait for this SCR to be resolved first?
tim.smith | 2017-06-01 16:20:42 UTC | #21
For it to work 100% correctly, you need to use the UI or wait for that bug to be fixed.
To work around, it looks like setting the extension through the API doesn't work from a telephony perspective. If you set the extension to 1234 and then try to dial 1234, it won't connect. However, if you're using the UI, you can type 1234 and it will find the user. As long as you select the user from the list and dial the user, as opposed to literally dialing the string 1234, the call will work.
andygunther | 2017-06-01 16:34:50 UTC | #22
Do you happen to have any ETA on the SCR?
tim.smith | 2017-06-01 16:35:43 UTC | #23
I don't. It hasn't been reviewed by the dev team yet.
andygunther | 2017-06-12 14:13:06 UTC | #24
Checking in on this. Is there any ETA on a fix here? Our current project is expected to hand over our import tool by the end of this week. We are hoping this will be working when we hand it over. Thanks!
tim.smith | 2017-06-13 12:57:57 UTC | #25
It's currently backlogged, but I've noted your request for priority.
andygunther | 2017-06-13 15:23:54 UTC | #26
Please let Dev know that this also prevents their import tool for users from working correctly. I'll attempt to escalate through Product Management as well.
andygunther | 2017-07-25 12:06:59 UTC | #27
I'm told this is fixed - do you happen to know if that means the user format we discussed earlier is expected to work as is:
andygunther, post:14, topic:1222
{ "name":"Robert Garza", "department":"CAM - Reimbursement", "email":"rgarza@cochlear.com", "addresses":[ { "extension":"8261", "mediaType":"PHONE", "type":"WORK"}, { "address":"+13032642161", "mediaType":"PHONE", "type":"WORK2"}], "title":"Test", "password":"Welcome1" }
tim.smith | 2017-07-25 15:28:06 UTC | #28
It's been marked as fixed, but it doesn't appear to have been deployed to production yet. I don't have any information on when it might get deployed. For reference, the ticket it was fixed under is CORE-6771.
tim.smith | 2017-08-03 15:05:54 UTC | #29
This has been deployed to prod and appears to be working. Let me know if you run into any issues with it.
system | 2017-08-28 19:34:07 UTC | #30
This post was migrated from the old Developer Forum.
ref: 1222