Updating User expiration dates using API

[anne_sample_f5]

I'm using the "update users API" to change the expiration date for a batch of users.

I am getting a response when I send the post, and it is actually changing the users. But instead of changing to the date I have set in the request, it's changing to "null/never." I've looked at the documentation surrounding the date format (although it's somewhat limited) and I even tried setting one user to the date I wanted, then copying the value from a "get user" response and pasting it into my body, but the same thing keeps happening.

I'm sure I'm missing something obvious, anyone have any ideas?

Here is my post body:

{

"action": "createOrUpdate",

"input": [

 {

"expiresAt": "2023-12-31T06:00:00.000t+0000"

 }

 ]

}

[DavidK · Accepted solution]

If anyone is trying to update users, not leads the format for /management/v1/users/{userid}/update.json is 

yyyyMMdd'T'HH:mm:ss.SSS't'Z

Example: 20241118T14:29:56.222t+0000
Note that the time-zone does not contain the colon and Z is not accepted (which is really weird). 

[SanfordWhiteman]

That's really bizarre but you're right, for buggy reasons it doesn't accept the everyday ISO 8601 yyyy-MM-dd'T'HH:mm:ss'Z'. We were too confident that this endpoint works like all the others!

[SanfordWhiteman]

That's not valid ISO 8601. Use ISO UTC

yyyy-MM-ddTHH:mm:ssZ

[anne_sample_f5]

Sorry, I don't understand how to resolve that code into an actual date. I spent like two hours trying to figure it out yesterday. 

[Darshil_Shah1]

Here's the correct ISO 8601 format for the datetime you've in your question:

2023-12-31T06:00:00Z

Just for your reference, Z refers to the 0 time zone (UTC). You could optionally add the offset if your datetime is in other timezones than the UTC (e.g., 2023-12-31T06:00:00+05:30). The + or - values indicate how far ahead or behind a time zone is from the UTC zone.

Edit- Sandy already posted a reply for this a few seconds before me! People are so responsive on the community threads. 🙌

[SanfordWhiteman]

I wouldn’t advise using the offset in any case, because any library capable of accurately knowing the offset also knows how to use Z/UTC.

[Darshil_Shah1]

Yeah- that makes sense! Thank you, Sandy! Using the Z (UTC timezone) certainly does help to stick with a standard timezone and thus avoid any confusion. 😊

[SanfordWhiteman]

2023-09-01T12:34:56Z

Any datetime library can output this format. It’s the world standard!

[anne_sample_f5]

That was the date I tried using first! I even tried more than one date converter to generate it and none of them actually work. I feel like I'm losing my mind. I copied from your post to try again and it still doesn't work. I'm so confused. 

My post body:

{

"action": "createOrUpdate",

"input": [

 {

"expiresAt": "2023-12-31T06:00:00Z"

 }

 ]

}

keeps returning the response:

"expiresAt": null,

What on earth is happening to me 😂

[Darshil_Shah1]

Is expiresAt a date time field? Also, why don't you have any meaningful lookup field (like email, person id, etc.) in your POST body? Granted it's not mandatory and technically your Sync lead POST API endpoint should be successful as-is, but it'd just create a new person record with no email address every time you make an API call. Lastly to be sure, you're the Sync lead POST API endpoint only, right?

POST rest/v1/leads.json

[anne_sample_f5]

No, I am using Update User Attribute. I'm updating system users, not person records, which is why I don't have the ID - it's directly in the URL. It is a datetime according to the documentation: 

expiresAt (string) - Date and time when user login expires. Example: yyyy-MM-dd'T'HH:mm:ss.SSS't'Z

[Darshil_Shah1]

@anne_sample_f5, that makes sense! Thank you for getting back. Hope you were able to update the users and the expiresAt datetime format worked for you. If not, feel free to let us know and we'd be more than happy to help. 🙂

[Jo_Pitts1]

@anne_sample_f5 , what language are you coding in?  Can you share the relevant code that is producing the payload?

Then we might be able to determine why the datetime info you are generating isn't valid.

Regards

Jo