sessionID parameter in Delivery API request | Community
Skip to main content
Level 3
February 14, 2022
Solved

sessionID parameter in Delivery API request

  • February 14, 2022
  • 2 replies
  • 5287 views

What exactly is the sessionID parameter in the Delivery API request call?

 

https://clientCode.tt.omtrdc.net/rest/v1/delivery?client=clientCode`&sessionId=d359234570e04f14e1faeeba02d6ab9914e\
  -H 'Content-Type: application/json' \

 

Best answer by Gokul_Agiwal

Hi @rjbu 

Session ID is a unique ID for a user session. By default, this ID lasts 30 minutes.

You can able to see this unique ID in cookie name called mbox dropping by Adobe target JS library in browser. 

 

In terms of Server side implementation where you're using Delivery API for deliver the experience through different channels, API user needs to generate and maintained the sessionID for the current session The sessionId can be any printable string except a space, ?, or /. It should be between 1 and 128 characters in length.

 

Hope this helps. 

2 replies

Gokul_Agiwal
Community Advisor
Gokul_AgiwalCommunity AdvisorAccepted solution
Community Advisor
February 14, 2022

Hi @rjbu 

Session ID is a unique ID for a user session. By default, this ID lasts 30 minutes.

You can able to see this unique ID in cookie name called mbox dropping by Adobe target JS library in browser. 

 

In terms of Server side implementation where you're using Delivery API for deliver the experience through different channels, API user needs to generate and maintained the sessionID for the current session The sessionId can be any printable string except a space, ?, or /. It should be between 1 and 128 characters in length.

 

Hope this helps. 

RJBuAuthor
Level 3
February 14, 2022

Thanks!

 

So in this context would "session" be referring to browser session, or Adobe session (or some other session)?

Gokul_Agiwal
Community Advisor
Community Advisor
February 14, 2022

Hi @rjbu 

It's a user session for that current activity. 

Level 4
February 14, 2022

hi

Follow the details
"For a particular session, its value must stay the same across multiple requests for the same user since routing to a particular node in the edge cluster, which contains the user profile, is done using the sessionId. The session is active for 30 minutes on the server side. Therefore, you shouldn’t use a different sessionId for a particular tntId or thirdPartyId within 30 minutes of the last request made with the same tntId or thirdPartyId. Otherwise, changes to the profile could be inconsistent and unpredictable."

 

For API implementation "Session id" management is your responsibility. Adobe is expecting 30min retention of this ID from the last active session. 

 

If session id is not maintained correctly you will have the following issues 

- cache segment is served (not real-time segment)

- frequency capping is not working

There is a limit on how many time real-time segment is pulled in a session is session is not manage correctly you will hit the limit and end up getting cache segment

 

Thanks

Abu

RJBuAuthor
Level 3
February 15, 2022

So what is the recommended pattern on how to access/persist the sessionID on a pure server side solution?  Is this even possible?

 

Is the VisitorID service (JavaScript) required to fetch information required for user persistence/bucketing (sessionID, ECID, etc.)?  If so it seems that the Delivery API cannot be a pure server side solution, unless there is something I'm missing here.

 

The specific use case I'm thinking of is when a user comes to site and has not yet been identified as a particular visitor (i.e., user clears cookies on close of browser).  In these cases the inbound request will not have ID cookie information.  However each request (in same session) after that should.  This means that said user could potentially get two different versions of the same test for each browser session.  

 

Does this make sense?

Level 4
February 15, 2022

In our case server side solution is required for financial institution due to content injection (via js implementation) is not allowed in our secure site or mobile apps.

 

Target API solution required 3 things (Visitor Id, Analytics & Audience manager).

 

The specific use case I'm thinking of is when a user comes to site and has not yet been identified as a particular visitor (i.e., user clears cookies on close of browser).  In these cases the inbound request will not have ID cookie information.  However each request (in same session) after that should.  This means that said user could potentially get two different versions of the same test for each browser session.  


Implement visitor id correctly should take care of the above concern.