The AtomSphere API is intended to add programmatic access to functionality that is normally accessed through the AtomSphere UI.
For information on the Partner API and how it differs from the the AtomSphere API, please visit the Partner API page.
The AtomSphere API is built around an Object/Verb hierarchy. The Verbs are the various operations (GET, UPDATE, etc) which can be executed for each Object (Account, etc) in the AtomSphere API. This is a parallel to the basic Object Oriented Programming paradigm as well as the web service implementation theory behind REST
. The Object/Verb hierarchy will be referred to in terms of Object-based Operations. Those "verbs" that don't fall into this Object/Verb hierarchy (executeProcess, deployProcess, etc) are designated as Actions in the AtomSphere API.
The AtomSphere API has been developed with both a SOAP and RESTish implementation. Follow the links below in the Object-based Operation and Action sections to find out detailed information about performing each API call using both the SOAP and RESTish implementations.
AtomSphere API Object-based Operations
An object-based operation deals with a specific object (i.e. Account) that one or more operations can be performed on. These operations are limited to GET, QUERY, CREATE, UPDATE, UPSERT, and DELETE.
The following table will show the Objects that are available in the AtomSphere API and the allowed operations for each Object. Follow the Object links to get detailed information about how to make API calls for each of the supported operations.
AtomSphere API Actions
An action deals with an operation that doesn't fit in the Object-based Operations described above. The following table lists the actions available in the AtomSphere API along with a short description. Click on the Action to see detailed information about the API call.
| Action |
Description |
| Deploy Process |
The deployProcess operation is used to copy a process deployment from one environment to another. |
| Execute Process |
The executeProcess operation is used to asynchronously execute a process on a particular Atom. |
| Generate Widget URL |
The generateWidgetUrl operation is used to retrieve the URL for a widget manager with optional pre-loaded extension values. |
| Get Widget List |
The getWidgetList operation is used to get a list of installed widget instances based on a managerID and partnerUserID. |
SOAP API
The SOAP API's WSDL is located at https://platform.boomi.com/api/soap/v1/{accountID}?wsdl where accountID is your AtomSphere Account ID. The WSDL is protected by Basic Authentication so your AtomSphere user name and password will be required to access it. Each SOAP call is protected by WS-Security using a UsernameToken where the password is passed as PasswordText.
RESTish API
The RESTish API calls all begin with https://platform.boomi.com/api/rest/v1/{accountID} where accountID is your AtomSphere Account ID. The rest of the URL is dependent upon the operation you are trying to perform. The full URLs are discussed in the documentation for each Object-based Operation and Action. The RESTish calls are protected by Basic Authentication.
The schema used by the RESTish API is the same as the one used by the SOAP API. The schema is located at https://platform.boomi.com/api/soap/v1/{accountID}?xsd=1 and is protected by Basic Authentication.
API Usage Rate Limit
Both the SOAP and RESTish implementations of the API limit the rate of requests to five requests per second. If usage of the API exceeds this limit, the user will receive an HTTP 503 response indicating that the server is temporarily unable to fulfill the request.
API Usage Request Limit
Both the SOAP and RESTish implementations of the API limit the number of requests that can be served per day. The limit is account specific and usage is calculated based on a rolling 24 hour period with usage calculated every hour. If usage of the API exceeds this limit, the user will receive an HTTP 503 response indicating that the server is temporarily unable to fulfill the request.
To provide a simple example of how this works, assume that an account has a limit of 200 requests per day. If, starting at noon on Monday, the account makes 10 requests per hour, the account will reach it's limit of requests per rolling 24 hour period during the 7am hour on Tuesday (20hrs * 10 requests/hr = 200 requests). The user will not be able to make requests again until the previous 24 hour period has fewer than 200 requests. This will not happen until noon on Tuesday, when the previous days requests from the noon hour fall out of the previous 24 hour period.