Bronto API

Understand REST and SOAP API clients.

The API was originally designed using the SOAP API protocol, a standard method for enabling interoperability. Bronto’s newest offerings leverage the convenience and flexibility of REST. With our REST API client, you can access and work with your product and order data.

On this site, you will find complete documentation of the SOAP and REST API calls, as well as sample code in a variety of languages.

With the Bronto API you can:

  • Synchronize contacts on a regular basis
  • Create, edit, and manage lists of contacts using external data stores
  • Read delivery metrics and subscriber activities for use in CRM systems
  • Deliver transactional and triggered messages from external systems
  • Record customer conversions whether from email or other sources
  • Create and update contact field data
  • Import a product data feed (REST)
  • Update a product (REST)
  • Get the data associated with a product (REST)
  • Add a cart (REST)
  • Get, update, or delete a cart (REST)
  • Find orders associated with a customer (REST)
  • Add a new order (REST)


When Bronto began the development of our API, we built it on the current industry standard SOAP (Simple Object Access Protocol). Our newest services have use REST (Representational State Transfer ) APIs. While there are no immediate plans to move our current SOAP APIs to REST, any future services will provide REST APIs.

So how do you know which API you need to use? If you are working with Product or Cart data, you will need to use REST calls. When you are working with Order data you will also want to use REST API calls, though you can add, update, or delete orders using SOAP functions. Everything else – contacts, lists, deliveries, messages, webforms, workflows, etc – is based on SOAP.


Use the following tips to troubleshoot the Bronto API:

  • Consult the descriptive key, code, and message that the Bronto API returns when it encounters an error.
    Tip: Certain error types indicate temporary problems that might resolve on their own. Examples are SHARD_OFFLINE and READ_ERROR. Other error types require intervention. Examples are INVALID_REQUEST and INVALID_ACCESS.
  • Use retry logic to store and retry requests that encountered temporary errors and to log more permanent errors.
    Note: Temporary errors can occur during maintenance periods or if there are connectivity issues.

To read the full blog post, see Tips for API Troubleshooting.