Authentication in the adCenter API
 Warning |
|---|
| This topic has been removed because its content is either included in other topics, or is no longer valid. |
When you call the Microsoft adCenter API, you must supply authentication information, such as a user name, password, and developer token.
 Note |
|---|
| Passwords and developer tokens must be kept secure and should be encrypted whenever they are persisted to a storage device, such as a file, database, registry, disk, CD, or a USB storage device. If you capture your SOAP information for troubleshooting, make sure that any values for your credentials are not compromised. For example, do not send your actual password and developer token via e-mail. |
The user name and password are also used for the adCenter Web service user interface. Notice that in the different adCenter operating environments (sandbox and production) you will use different user names and passwords. However, in an operating environment, the same user name and password would be used for the API and the user interface.
The developer token is validated against an adCenter internal database. The developer token is generated for you when your account is created—you cannot change it. Similar to the user name and password, the developer token is different for the sandbox and the production environments. The developer token enforces stricter security when you access adCenter by using the API.
| Note |
|---|
| In addition to the developer token previously described, Microsoft can also provide a third-party user access key. Developers can use this developer token to create third-party tools that manage multiple accounts for advertisers. To obtain a third-party developer token, contact your adCenter Technical Support representative or account executive. |
The URLs for the adCenter API production and sandbox Web Services Description Language (WSDL) documents use the Secure Sockets Layer (SSL) protocol, as noted by https in the URL. The adCenter user interface also requires SSL.
If you want to capture your SOAP requests for troubleshooting, you must do so before the request is encrypted and sent to the Internet.
For more information about SOAP, see SOAP Request and Response Messages.
The Administration, Campaign Management, and Reporting Web services encapsulate the authentication information in the header of each of the request message objects. For an example of how to set these elements in C#, see How to Create Campaigns in C#.
The Customer Management and Notification Management Web services contain an ApiUserAuthHeader object that encapsulates the user name, password, and developer token. The following C# code example shows how to set your authentication information in an ApiUserAuthHeader object when you use the CustomerManagement Web service.
// Create an instance of the CustomerManagement Web service. CustomerManagement objCustMgt = new CustomerManagement(); // Create an instance of the ApiUserAuthHeader class. ApiUserAuthHeader authHdr = new ApiUserAuthHeader(); // Specify the values for the ApiUserAuthHeader elements. // Use your own values instead of the following example strings. authHdr.UserName = "your_user_name"; authHdr.Password = "your_password"; authHdr.UserAccessKey = "your_user_access_key"; // Assign the ApiUserAuthHeader variable to the // CustomerManagement value. objCustMgt.ApiUserAuthHeaderValue = authHdr; // Your credentials are now associated with your // instance of the CustomerManagement Web service, // so objCustMgt can now be used to call customer // management service operations, such as CustomerSignUp.
