Different Lifecycle payloads have different format AuthTokens

The payload sent to the SmartApp handler is documented as follows:

Annotation 2020-06-04 103852 Annotation 2020-06-04 103812

What’s the difference between the authTokens in the UPDATE lifecycle and the EVENT lifecycle?

Despite giving them the same name and the same description they are clearly different.

At run time the one received in UPDATE is a short format (like a GUID), is accompanied by a refresh token, and works like a SmartApp token in accordance with the documentation. However, the one received at EVENT is an 800 odd character token. How is this to be used?

Given that it’s a common pattern to call the API during the event lifecycle, am I expected to “remember” the authToken received during the UPDATE cycle or is there some way I should be using the longer token? Is there a different authorization scheme that can be used in the API call.

Naturally, it wouldn’t be ideal to expect SmartApps (with their millions of users) to hold on to the authTokens they receive, since they would have no idea when the next lifecycle handler will be called, and being stateless would be a lot easier to implement than having to store millions of trusting users authTokens somewhere. So I’m hoping that in the payload passed in during the EVENT lifecycle, there is everything I need to make a call to the API.

Tagging @jody.albritton as recommended by @erickv

The authToken you are sent with the event body is a short lived (5 minute) disposable token. You can use this token to take immediate action when an event is received. This short lived token allows you to take an action without using your longer tokens that require refresh. You can use the tokens as bearer tokens like the other tokens to perform any actions that have been permitted by the smartapp. You should not store or need to manage the tokens that arrive with an event as they are intended to be disposable.

1 Like

Thanks, so to clarify:

the 800ish char long token I get in the EVENT body can be used as a Bearer Token in the same way as the much shorter GUID like (20 ish char) token I get in the UPDATE body?

I can see there’s no reason why they should be in the same format as I’m going to lose them after the call anyway, but the key thing to understand is that they can be used in the same way (as long as it’s used within the handler that is presented it).