Looking to get started integrating your solution with Salesforce? There’s a lot of information out there, so it can be difficult to know where to start. We’ve put together some useful information below to provide a quick rundown on what to consider when starting to integrate with Salesforce.
Commonly-used APIs when integrating with Salesforce data
For additional APIs, please reference: https://help.salesforce.com/HTViewHelpDoc?id=integrate_what_is_api.htm
Authentication
Using SOAP To log in to Salesforce using cURL:
1. Create a text file called login.txt containing the following text:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<env:Envelope xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”>
<env:Body>
<n1:login xmlns:n1=”urn:partner.soap.sforce.com”>
<n1:username>your_username</n1:username>
<n1:password>your_password</n1:password>
</n1:login>
</env:Body>
</env:Envelope>
2. Replace your_username and your_password with your Salesforce user name and password.
3. Using a command-line window, execute the following cURL command: curl https://login.salesforce.com/services/Soap/u/33.0 -H “Content-Type: text/xml; charset=UTF-8” -H “SOAPAction: login” -d @login.txt
4. The Soap/u/ portion of the URI specifies the partner WSDL. You can use Soap/c/ to specify the enterprise WSDL.
*The Web Services Description Language (WSDL) is an XML-based interface definition language that is used for describing the functionality offered by a web service5.
5. Salesforce returns an XML response that includes <sessionId> and <serverUrl> elements. Note the values of the <sessionId> element and the first part of the host name (instance), such as na1-api, from the <serverUrl> element. Use these values in subsequent requests to the REST or SOAP API.
Reference: http://www.salesforce.com/us/developer/docs/api_asynch/Content/asynch_api_quickstart_login.htm
Using OAuth
OAuth (Open Authorization) is an open protocol to allow secure API authorization in a simple and standardized way from desktop and web applications. The Force.com platform implements the OAuth 2.0 Authorization Framework, so users can authorize applications to access Force.com resources (via the Force.com REST and SOAP Web Service APIs) or Chatter resources (via the Chatter REST API) on their behalf without revealing their passwords or other credentials to those applications. Alternatively, applications can directly authenticate to access the same resources without the presence of an end user.
What is a Connected App?
A connected app integrates an application with Salesforce using APIs. Connected apps use standard SAML and OAuth protocols to authenticate, provide Single Sign-On, and provide tokens for use with Salesforce APIs. In addition to standard OAuth capabilities,connected apps allow administrators to set various security policies and have explicit control over who may use the corresponding applications.
A developer or administrator defines a connected app for Salesforce by providing the following information:
- Name, description, logo, and contact information
- A URL where Salesforce can locate the app for authorization or identification
- The authorization protocol: OAuth, SAML, or both
- Optional IP ranges where the connected app might be running
- Optional information about mobile policies the connected app can enforce
For connected apps that use OAuth service providers, define the OAuth scopes and callback URL for the connected app. In return,Salesforce provides an OAuth Consumer Key and a Consumer Secret for authorizing the connected app.
Reference: https://help.salesforce.com/apex/HTViewHelpDoc?id=connected_app_overview.htm
API Access in Group and Professional Editions
API access is not normally supported in GE/PE organizations; however, once your app passes the security review, you’re eligible to use some APIs for building composite applications.
- Currently, only the standard SOAP and REST APIs are supported for GE and PE apps. You can also request that a connected app be allowlisted to use the REST API in GE or PE organizations.
- Other APIs such as the Metadata API, Bulk API, and Apex Methods exposed using the SOAP Web service remain unavailable.
- REST based Web services can be enabled by connected app consumer allowlisting
- SOAP based Web services can be enabled using an API token called a Client ID, which needs to be appended to your SOAP headers in integration calls. This special key enables your app to successfully make calls to GE/PE even if the customer does not have API access.
*Note, allowlisting can sometimes take up to 24 hours for the replication to be completed
Check out this link to learn more about the APIs accessible in GE/PE, and the method of access:
http://www.salesforce.com/us/developer/docs/packagingGuide/Content/dev_packages_api_access.htm
Considerations with the recent changes
After September 10, 2014, only users who have the “API Enabled” profile permission turned on will have access to the identified connected apps.
For more information:
https://help.salesforce.com/apex/HTViewSolution?urlname=API-Access-Change-for-Connected-Apps&language=en_US Salesforce
REST API Developers Guide: https://www.salesforce.com/us/developer/docs/api_rest/
Salesforce SOAP API Developers Guide: https://www.salesforce.com/developer/docs/api/
Salesforce Bulk API Developers Guide: https://www.salesforce.com/us/developer/docs/api_asynch/
A special thanks to Martin Ko, Nick Poirier, and Tim Kohrumel from the ISV Technical Enablement team for contributing to this documentation.