REST Resources

REST Resources Supported by Tooling API

For details on usage, syntax, and authentication, see the REST API Developer Guide.

For examples, see REST Resource Examples.

For information on how to minimize the number of round trips between client and server, see Improve Performance with the Composite Resource.

The base URI for each Tooling API REST resource is http://domain/services/data/vXX.X/tooling/ where domain is a My Domain or a custom domain and vXX.X is the API version number. For example: https://MyDomainName.my.salesforce.com/services/data/v35.0/tooling/

Like the REST API, Tooling API uses the following resources.

/completions?type=

Supported methods: GET

Retrieves available code completions of the referenced type for Apex system method symbols (type=apex). Available from API version 28.0 or later.

Retrieves available code completions of the referenced type for Visualforce markup (type=visualforce). Available from API version 38.0 or later.

/executeAnonymous/?anonymousBody= <url encoded body>

Supported methods: GET

Executes Apex code anonymously. Available from API version 29.0 or later.

/query/?q=SOQL_Query_Statement

Supported methods: GET

Executes a query against an object and returns data that matches the specified criteria. Tooling API exposes objects like EntityDefinition and FieldDefinition that use the external object framework. That is, they don’t exist in the database but are constructed dynamically. Special query rules apply to virtual entities.

If the query result is too large, it’s broken up into batches. The response contains the first batch of results and a query identifier. The identifier can be used in a request to retrieve the next batch.

/runTestsAsynchronous/

Supported methods: POST

Runs one or more methods within one or more Apex classes, using the asynchronous test execution mechanism. In the request body, you can specify test class names and IDs, suite names and IDs, the maximum number of failed tests to allow, and the test level, as comma-separated lists or as an array. You can also indicate whether to opt out of collecting code coverage information during the test run (available in API version 43.0 and later).

1/runTestsAsynchronous/ Body: 
2{"classNames":
3   "comma-separated list of class names",
4"classids":
5   "comma-separated list of class IDs", 
6"suiteNames":
7   "comma-separated list of test suite names",
8"suiteids":
9   "comma-separated list of test suite IDs", 
10"maxFailedTests":
11   "integer value",
12"testLevel":
13   "TestLevel enum value", 
14"skipCodeCoverage":
15   "boolean value"}

OR

1/runTestsAsynchronous/ Body: 
2{"tests":tests array}

Example tests array:

1[{
2   "className":
3      "YourClassName",
4   "testMethods": [
5      "testMethod1",
6      "testMethod2",
7      "testMethod3"
8   ]
9}, {
10   "className":
11      "ManagedPackageNamespace.ManagedClassName",
12   "testMethods": [
13      "testMethod1",
14      "testMethod2",
15      "testMethod3"
16   ]
17}, {
18   "classId":
19      "01pD0000000FhyEIAS",
20   "testMethods": [
21      "testMethod1",
22      "testMethod2",
23      "testMethod3"
24   ]
25}, {
26   "maxFailedTests": "2"
27}, {
28   "testLevel":
29      "RunSpecifiedTests"
30}]

• You must provide classNames, classids, suiteNames, suiteids, or a tests array. If you provide classNames, classids, suiteNames, or suiteids, you can’t also provide a tests array. However, you can provide classNames, classids, suiteNames, and suiteids.
• tests array is an array of objects that represent Apex test classes—each of which has a className or classId and a testMethods parameter. The tests array also includes optional maxFailedTests and testLevel parameters.
• Multiple occurrences of a test method name in a testMethods array are ignored. Test methods that don’t exist are skipped. A null or missing testMethods array specifies that all test methods in the test class are run.
• To allow all tests in your run to execute, regardless of how many tests fail, omit maxFailedTests or set it to -1. To stop the test run from executing new tests after a given number of tests fail, set maxFailedTests to an integer value from 0 to 1,000,000. This integer value sets the maximum allowable test failures. A value of 0 causes the test run to stop if any failure occurs. A value of 1 causes the test run to stop on the second failure, and so on. Keep in mind that high values can cause slow performance. Each 1,000 tests that you add to your maxFailedTests value adds about 3 seconds to your test run, not including the time that the tests take to execute.

• The testLevel parameter is optional. If you don’t provide a testLevel value, we use RunSpecifiedTests.

  Permissible values include:

  RunSpecifiedTests

  Only the tests that you specify are run.

  RunLocalTests

  All tests in your org are run, except the ones that originate from installed managed packages.

  Omit identifiers for specific tests when you use this value.

  RunAllTestsInOrg

  All tests are run. The tests include all tests in your org, including tests of managed packages.

  Omit identifiers for specific tests when you use this value.

/runTestsSynchronous/

Supported methods: POST

1/runTestsSynchronous/ Body:
2{"tests":tests array}

Example tests array with Apex class names:

1[{
2   "className":
3      "YourClassName",
4   "testMethods": [
5      "testMethod1",
6      "testMethod2",
7      "testMethod3"
8   ]
9}, {
10   "maxFailedTests": "2"
11}]

Example tests array with Apex class IDs:

1[{
2   "classId":
3      "01pD0000000Fhy9IAC",
4   "testMethods": [
5      "testMethod1",
6      "testMethod2",
7      "testMethod3"
8   ]
9}, {
10   "maxFailedTests": "2"
11}]

• Runs one or more methods within an Apex class, using the synchronous test execution mechanism. All test methods in a synchronous test run must be in the same class.
• For API version 40.0 and later, running Apex tests synchronously using the POST method for /runTestsSynchronous/ requires the View Setup user permission.
• tests array is an array of an object that represents an Apex test class—which has a className or a classId, and a testMethods parameter—and an optional maxFailedTests parameter.
• Multiple occurrences of a test method name in a testMethods array are ignored. Test methods that don’t exist are skipped. A null or missing testMethods array specifies that all test methods in the test class are run.
• To allow all tests in your run to execute, regardless of how many tests fail, omit maxFailedTests or set it to -1. To stop the test run from executing new tests after a given number of tests fail, set maxFailedTests to an integer value from 0 to 1,000,000. This integer value sets the maximum allowable test failures. A value of 0 causes the test run to stop if any failure occurs. A value of 1 causes the test run to stop on the second failure, and so on. Keep in mind that high values can cause slow performance. Each 1,000 tests that you add to your maxFailedTests value adds about 3 seconds to your test run, not including the time that the tests take to execute.

/search/?q=SOSL_Search_Statement

Supported methods: GET

Search for records containing specified values.

/sobjects/

Supported methods: GET

Lists the available Tooling API objects and their metadata.

/sobjects/SObjectName/

Supported methods: GET, POST

Describes the individual metadata for the specified object or creates a record for a given object.

• To retrieve the metadata for the ApexExecutionOverlayAction object, use the GET method.
• To create a ApexExecutionOverlayAction object, use the POST method.

/sobjects/SObjectName/describe/

Supported methods: GET

Completely describes the individual metadata at all levels for the specified object.

For example, use this resource to retrieve the fields, URLs, and child relationships for a Tooling API object.

/sobjects/SObjectName/id/

Supported methods: GET, PATCH, DELETE

Accesses records based on the specified object ID.

Use the GET method to retrieve records or fields, the DELETE method to delete records, and the PATCH method to update records.

/sobjects/ApexLog/id/Body/

Supported methods: GET

Retrieves a raw debug log by ID. Available from API version 28.0 or later.