Tooling API

Introducing Tooling API
SOAP Calls
Tooling API Objects and Namespaces
Tooling API Objects
SOAP Headers for Tooling API
REST Headers for Tooling API
PDF

Newer Version Available

This content describes an older version of this product. View Latest

SOAP Calls

Use SOAP if you’re using a strongly typed language like Java that generates Web service client code. For details about usage, syntax, and authentication, see the SOAP API Developer Guide.

To access the Tooling API WSDL, from Setup, enter API in the Quick Find box, then select API and click Generate Tooling WSDL.

Like the Salesforce SOAP API, Tooling API uses the following calls.

create()
Adds one or more records to your organization’s data. When creating objects with the Metadata field, only one object can be processed in a request.
delete()
Deletes one or more records from your organization’s data.
describeLayout()
Retrieve metadata about page layouts for a specified SOjbect.
describeGlobal()
Lists the available Tooling API objects and their metadata.
describeSObjects()
Describes the metadata (field list and object properties) for the specified object or array of objects.

Call describeGlobal() to retrieve a list of all Tooling API objects for your organization, then iterate through the list and use describeSObjects() to obtain metadata about individual objects.

describeValueType()
Describes the metadata for a specified namespace and value type. For information about describeValueType, see the Metadata API Developer Guide.
describeWorkitemActions()
Describes which actions are available for a specified work item.
executeanonymous(string apexcode)
Executes the specified block of Apex anonymously and returns the result.
query()
Executes a query against a Tooling API object and returns data that matches the specified criteria.
queryMore()
Retrieves the next batch of objects from a query().
retrieve()
Retrieves one or more records based on the specified IDs.
runTests()
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.
The synchronous runTests() call accepts a RunTestsRequest object.
For sample code and more information, see runTests().
runTestsAsynchronous()
Runs one or more methods within one or more Apex classes, using the asynchronous test execution mechanism.
This example shows a call to a class that calls the runTestsAsynchronous endpoint.

For more runTestsAsynchronous() example code, see ApexTestQueueItem.

All parameters are mandatory. To provide values for only some parameters, specify the others as null.
  • The classids, suiteids, classNames, and suiteNames parameters must all be specified. To provide values for only some of these parameters, specify the others as null. To use TestLevel.RunLocalTests or TestLevel.RunAllTestsInOrg, specify all class- and suite-related parameters as null.
  • A value for maxFailedTests is mandatory. To allow all tests in your org to run, regardless of how many tests fail, set maxFailedTests 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 available and required in API version 37.0 and later, but its value can be null. Other 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.
  • The tests parameter is available and required in API version 41.0 and later, but its value can be null. This property is an array of type TestsNode.
  • The skipCodeCoverage parameter is available in API version 43.0 and later, but its value can be null. This property is a boolean that indicates whether to opt out of collecting code coverage information during the test run.
search()
Search for records that match a specified text string.
update()
Updates one or more existing records in your org’s data. When updating objects with the Metadata field, only one object can be updated per request.
upsert()
Creates records and updates existing records; uses a custom field to determine the presence of existing records. To upsert objects with the Metadata field, pass in only one object per request.

SOAP Headers

The SOAP headers available in the Tooling API WSDL are described in SOAP Headers for Tooling API.

Examples

These examples use C#, but you can use any language that supports Web services.

To compile Apex classes or triggers in Developer Edition or sandbox organizations, use create(). The next sample uses ApexClass to compile a simple class with a single method called SayHello.

The IsCheckOnly parameter on ContainerAsyncRequest indicates whether an asynchronous request compiles code but doesn’t execute or save it (true), or compiles and save the code (false).

The next example expands upon the first by modifying the SayHello() method to accept a person’s first and last name. This example uses MetadataContainer with ApexClassMember to retrieve and update the class, and ContainerAsyncRequest to compile and deploy the changes to the server. You can use the same method with ApexTriggerMember, ApexComponentMember, and ApexPageMember.
To test your code, modify the IsCheckOnly parameter in the next sample, and log in to your organization after a successful execution to verify the results.
  • When IsCheckOnly = true, the SayHello() method remains the same. ApexClassMember contains the compiled results, but the class on the server remains the same.
  • When IsCheckOnly = false, the SayHello() method shows the change to accept a person’s first and last name.

Note

To access Apex class and trigger data in a structured format, use a SymbolTable.

The next sample queries the ApexClassMember object created in the previous example to obtain the SymbolTable of the modified class.

The SOQL statement used depends on when the data is retrieved.

  • To execute the query from within the previous sample, use the ID of the ContainerAsyncRequest. For example, SELECT Body, ContentEntityId, SymbolTable FROM ApexClassMember where MetadataContainerId = '" + requestId + "'"
  • Otherwise, use the ID of the modified class as shown in the next sample. For example, SELECT ContentEntityId, SymbolTable FROM ApexClassMember where ContentEntityId = '" + classId + "'"

Note

To add checkpoints to your code for debugging, use ApexExecutionOverlayAction.

This sample adds a checkpoint to the class from the previous samples: