Tokens

The client-service creates and manages multiple tokens (JWT) to handle the state of the client and the associated contact. These tokens are typically passed back and forth between the client and the service as requests headers. See more details for each token below.

Common for all tokens is that they are fully managed on the service side and the client should only store them locally and pass them back to the service as instructed.

Client State

Communicated via the X-Client-State (v3) or EC-Client-State (v4) header both in request and response. The content of the token is the combined state of the whole client. The properties from the client-endpoint, the push-token as well as the contact information.

The token is among other things used by the Device Event service to do client-level filtering for in-app messages.

Contact

Communicated via the X-Contact-Token (v3) or EC-Contact (v4) header both in request and response. It’s created when the contact is set via the contact endpoint and updated via the contact-token when needed in case of expiry.

Header

  • kid - the version of the key used to encrypt the token. This property is always present when the token is encrypted.

Payload

  • contactReference - the reference to a contact in the client-service. This property is always present.

  • contactId - The numeric id of the contact in Emarsys. This property is set after the contact has been properly identified.

  • businessAreaId - The id of the business area the contact is associated with in the current application context.

  • exp - the expiry date of the token. A contact-token is typically valid for 8 hours, but might be valid less time if the contact has not yet been identified.

  • disabled - boolean flag indicating if the contact-token is disabled. If it’s true the request will be dropped as soon as possible in the device-event service. It will be true if the contact has been removed or if anonymous contacts are disabled.