I have below code to get session id of another org and to connect it. Problem I am facing is not able to see session id .

HttpRequest request = new HttpRequest();
        request.setEndpoint('https://' + LOGIN_DOMAIN + '.salesforce.com/services/Soap/u/22.0');
        request.setHeader('Content-Type', 'text/xml;charset=UTF-8');
        request.setHeader('SOAPAction', '""');
        request.setBody('<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"><Header/><Body><login xmlns="urn:partner.soap.sforce.com"><username>' + USERNAME + '</username><password>' + PASSWORD + '</password></login></Body></Envelope>');
        Dom.XmlNode resultElmt = (new Http()).send(request).getBodyDocument().getRootElement()

        // Grab session id and server url (ie the session)
        final String SERVER_URL = resultElmt.getChildElement('serverUrl','urn:partner.soap.sforce.com').getText().split('/services')[0];
         System.debug('SERVER_URL ->'+ SERVER_URL);
        final String SESSION_ID = resultElmt.getChildElement('sessionId','urn:partner.soap.sforce.com').getText();

        // Load first 10 accounts via REST API
        final PageReference theUrl = new PageReference('https://xxx/services/apexrest/restCreateTaskForTrainings');
        theUrl.getParameters().put('vEmail','[email protected]');
        theUrl.getParameters().put('vSubject','Test Task Creation');
        request = new HttpRequest();
       System.debug('URL Clled :' + theUrl.getUrl());
        request.setHeader('Authorization', 'OAuth ' + SESSION_ID); 
         HttpResponse res = h.send(request);

I am getting this issue from today onwards.Any help would be appreciated.

  • 3
    I've reached out to Salesforce to see if we can get an official statement on why UserInfo.getSessionId() is being replaced with SESSION_ID_REMOVED. Commented Jun 21, 2017 at 20:20
  • @DanielBallinger We are also facing this issue. Did you get any response from Salesforce? Commented Jun 22, 2017 at 12:50
  • System.Debug(UserInfo.getSessionId()); results in 'DEBUG|SESSION_ID_REMOVED' from an executeAnonynous context. As a hack, you can set UserInfo.getSessionId() to a field from an executeAnonynous context and the session id will be there. Strange Commented Jun 22, 2017 at 14:36
  • There are other ways that are still working for me. I have a python script that I execute to get the SessionId.
    – abhi
    Commented Jun 23, 2017 at 14:50

3 Answers 3


Response from the Salesforce Security Team:

Since Summer '17 the SessionId will no longer be returned in Debug logs.

Instead in its place, SESSION_ID_REMOVED will be returned.

e.g. Prior to this patch

System.debug(UserInfo.getSessionID()); would return

18:44:36:004 USER_DEBUG [1]|DEBUG|00D3A0000000001!ARkAQApQe_Omitted_yGifr.u7.

after the patch, it now returns


Customers can request a temporary deactivation of this change be disabled for their organizations by providing System Admin approval and acknowledgment of the security risks to exposing sessionIds in Debug Logs Note that this permission can only be enabled for 2 weeks upon the customer's request.

So, the change was intentional for security reasons. It makes sense, as you don't want your Session Id's inadvertently being persisted in debug logs where others might pick them up. E.g. They might appear in debug logs without you explicitly including them there.

If you intentionally want the Session ID to appear in the debug log then you can slightly obfuscate it so it doesn't being recognised as a Session ID. This can be handy if you need the Session ID for testing API calls with external tools E.g.

// Remove the intermediate space to get the actual Session ID.
System.debug(UserInfo.getOrganizationId().substring(0, 15) + ' ' +  UserInfo.getSessionId().substring(15));

Obviously, take some care where you expose the Session ID. The above code can be handy in anonymous Apex, but you don't want it hanging around in triggers or Apex code that exists in the org.

With regards to the specific question, it appears that the patch has applied the same obfuscation of the Session ID to your SESSION_ID string. I suspect you will need to contact Salesforce Support to report it as a bug.

  • Wow, this sucks. Makes using postman to test out rest endpoints etc that much more difficult to use.
    – Eric
    Commented Jun 26, 2017 at 15:43
  • 1
    @Eric I can understand why they have done it. You don't want session ID's inadvertently getting into the logs, which might in turn get passed around. It wasn't too difficult to slightly modify how the Session ID is logged to get the actual value. Commented Jun 26, 2017 at 20:14
  • So...do they actually change the value held in the variable reference or just how it gets logged?
    – Adrian Larson
    Commented Jul 5, 2017 at 20:31
  • 1
    @AdrianLarson My understanding is that it is stripping out anything that looks like a Session ID from the debug log. Probably with a regex. E.g. It will get the following System.debug('00D000000000000!000000000000000000000000000000000000000000000000000000000000000000000O00000000000000000000000000');. Whatever generated that debug log should be unaffected. Commented Jul 5, 2017 at 21:08
  • Yeah I just confirmed by comparing a Session Id generated via Refresh Token Flow to my running user's session and they differed. Not sure if it's worth a separate question but good to know.
    – Adrian Larson
    Commented Jul 5, 2017 at 21:10

It is just issue with Debug statements where session id/access token is not visible. For verification, I added simple code that sends mail to my inbox where I am able to view it


We've just come across this situation. As Daniel Ballinger said, this is down to a Summer 17 update.

I can confirm Daniel's theory in regards to your Session_ID variable on the REST callout. Salesforce is obfuscating the Session ID in the debug log, there appears to be a bug when assigning the the Session ID to the header of the next API call. Therefore when the message is sent, Salesforce simply returns an incorrect session id error.

Interestingly this doesn't happen when using the SOAP API (partner and enterprise) if you have imported the WSDL to Salesforce. So obviously Salesforce is doing some magic behind the scenes that is currently causing issues with the REST API.

We are going to open a case with Salesforce in an attempt to resolve it or at least come up with a temporary workaround.

(I would have added this as a comment but I don't have enough reputation yet!)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .