1

I am trying to do an API within my Salesforce to get the describe metadata, from winter 19 release notes and this idea that was marked as already delivered (Allow Apex to call Salesforce REST and SOAP API's without a Remote Site Setting), I understood that I dont required to do the API to retrieve the session ID and I can use System.UserInfo.getSessionId(), also I will not need to set up the remote site.

However, this still not the case I still have to set up remote site setting and if I try using System.UserInfo.getSessionId(), I get the error:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/2006/04/metadata">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:INVALID_SESSION_ID</faultcode>
            <faultstring>INVALID_SESSION_ID: This session is not valid for use with the API</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

Is there something else that I need to add to the System.UserInfo.getSessionId() to avoid having to ask an already signed user for their username, password and security token? in order to use this when calling making a call to the metadata endpoint? (https://xxxxx--sandbox.cs6.my.salesforce.com/services/Soap/m/46.0/00DN0......)

  • In what context is your code running? What is the API version? What Describe information are you trying to obtain from the Metadata API rather than the Apex Describe API? – David Reed Oct 7 at 23:42
  • @DavidReed: API: 46; running from aura component (there is an actual session ID as I can print it in console.log); the org metadata: <soapenv:Envelope xmlns:soapenv="schemas.xmlsoap.org/soap/envelope" xmlns:met="soap.sforce.com/2006/04/…> – manza Oct 8 at 0:01
2

Lightning Components' Apex controllers do not receive an API-enabled session:

By security policy, sessions created by Lightning components aren’t enabled for API access. This prevents even your Apex code from making API calls to Salesforce. Using a named credential for specific API calls allows you to carefully and selectively bypass this security restriction.

The restrictions on API-enabled sessions aren’t accidental. Carefully review any code that uses a named credential to ensure you’re not creating a vulnerability.

You do get a session Id, it's just not API-enabled. The recommended route, as alluded to above, is to use a Named Credential.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.