Bulk API 2.0 and Bulk API Developer Guide
jNewer Version Available
Configure Salesforce CORS Allowlist
| Available in: Salesforce Classic (not available in all orgs) and Lightning Experience |
| Available in: Developer, Enterprise, Performance, and Unlimited Editions |
| Available with API access enabled in: Professional Edition |
| User Permissions Needed | |
|---|---|
| To create, read, update, and delete: | Modify All Data |
- Apex REST
- Bulk API
- Bulk API 2.0
- Connect REST API
- Lightning Out
- REST API
- Salesforce IoT REST API
- Tableau CRM REST API
- User Interface API
Add an origin serving the request code to the CORS allowlist. If a browser that supports CORS makes a request to an origin in the allowlist, Salesforce returns the origin in the Access-Control-Allow-Origin HTTP header along with any additional CORS HTTP headers. If the origin isn’t included in the allowlist, Salesforce returns HTTP status code 403.
- From Setup, in the Quick Find box, enter CORS, and then select CORS.
- Select New.
-
Enter a resource in Origin URL Pattern.
- Save your changes.
The origin URL pattern must include the HTTPS protocol (unless you’re using your localhost) and a domain name. It can also include a port. The wildcard character (*) is supported and must be in front of a second-level domain name. For example, https://*.example.com adds all subdomains of example.com to the allowlist.
The origin URL pattern can be an IP address. But an IP address and a domain that resolve to the same address aren’t the same origin, and you must add them to the CORS allowlist as separate entries.
Google Chrome™ and Mozilla® Firefox® browser extensions are allowed as resources in API version 53 (Winter ‘22) or later . Chrome extensions must use the prefix chrome-extension:// and 32 characters without digits or capital letters, for example chrome-extension://abdkkegmcbiomijcbdaodaflgehfffed. Firefox extensions must use the prefix moz-extension:// and an 8-4-4-4-12 format of small alphanumeric characters, for example moz-extension://1234ab56-78c9-1df2-3efg-4567891hi1j2.
You can get a successful response when requesting a REST resource in a CORS preflight test, but receive an unsuccessful response to the actual request. This discrepancy can occur when the resource is deleted after the preflight test and before the request is made. It can also occur if the resource doesn’t exist. A CORS preflight confirms if resources can be passed between servers, but doesn’t check if a specific resource exists or not. CORS preflight requests are typically issued automatically by a browser.