API Documentation: Getting Started


The SubscriptionBridge XML APIs were designed to help developers integrate third-party applications with SubscriptionBridge (SB), a subscription management system developed by Early Impact, Inc.

This guide will provide a knowledgeable programmer with all the information needed to integrate a system with SB.

The XML APIs will work with any programming language or platform that is capable of sending and receiving XML documents over the HTTPS POST protocol.

If you're a “hands on” type of person feel free to skip on down to the resource section and grab some sample code.


The SubscriptionBridge APIs are a set of XML-based web services that allow third-party developers to integrate seamlessly with the SB system. APIs provide a vehicle for secure, bidirectional communication. Simply put… just about any application with internet access can be modified to work with the XML-based APIs. You can now create powerful, time-saving solutions that will streamline your business' recurring billing operations.

The SubscriptionBridge XML APIs are designed for…

Hit the Ground Running with Sample Code

Skill Requirements

The power of the SubscriptionBridge API is in the ability to have an external application communicate bidirectionally, without human interaction. Skills required:

  • a basic understanding of XML
  • ability to create (or have access to) an application that can send/receive XML communication
    Most programming languages include methods to send XML over HTTPS, and there is ample information available on the Internet.

In the following pages we will cover everything you need to know about the APIs. We will discuss the use of the APIs and the formation of the XML messages. You will also find technical information and sample code in this section.

Security Standards

To ensure that all personal information is handled securely:

  • We enforce Secure Socket Layering (SSL) on the SubscriptionBridge API. All requests must be send over the HTTPS protocol.
  • We ask that you strictly adhere to the PCI Data Security Standards. Since your application is “passing” information to SubscriptionBridge, the application (whatever it may be) is considered a “payment application” and must comply with the Payment Application Data Security Standard.

Using the APIs

Your First XML API Call

Get started in a snap with our sample code. Contact us for production ready examples in several languages.

The following sections will provide you will all of the knowledge needed to send your first XML Call.

Creating XML

All SB XML documents have the same basic elements. Here is an example of the basic XML structure for all requests/responses. In the example below “ActivationResponse” is the response container. “Ack” and “Timestamp” are the response elements.

<?xml version="1.0" encoding="utf-8"?>

Standard Request Elements

All XML calls will have a container element, such as “<ActivationRequest>” or “<ActivationResponse>”.

There are two elements that are required for every request transaction, in addition to the container element.

  • Username
    This is the API username, not your Merchant Center login.
  • Token
    The token is critical for authentication with the API. Click the link above for complete instructions.
All required elements must be present in your XML. The elements must also be sent in the correct order. If the XML request is not formed correctly the API will issue a HTTP Status Code of 400 (Bad Request) and send an ErrorResponse document with additional details.

Example XML:

<?xml version="1.0" encoding="utf-8"?>

Standard Response Elements

The following elements will always be returned with a response, in addition to the container element.

If the XML request is not formed correctly the API will issue a HTTP Status Code of 400 (Bad Request) and send an ErrorResponse document with additional details. In such a case the response elements may be different than the ones described in this section. For more information read over the ErrorResponse section.

Example XML:

<?xml version="1.0" encoding="utf-8"?>

Executing the Call


To make an API Call you need to find the EndPoint (or address) for the service. From the API Call Reference, click on the method name to find its EndPoint. A list of all the available EndPoints is listed below. You will need to replace the text in between the [] with your own.

Notification API:

Endpoint =[method_name]

Subscription API:

Endpoint =[method_name]

Management API:

Endpoint =[method_name]

The following is the EndPoint for an ActivationRequest:

The EndPoint must be HTTPS.
Call Guidelines

To make an successful call you must follow these rules:

  • ActivationRequest must be completed successfully before any other call can be made
  • All elements must be in the correct order
  • Username and Token are always the first elements in the request
  • Send the request over HTTPS
  • You must specify the correct EndPoint. If a call fails with a 500 HTTP Status Code this may be why
  • XML Elements are case sensitive
  • The “Content-Type” must be specified as “text/xml”
Sending API Requests with HTTPS POST

Almost every programming language has its own method for sending XML via HTTPS POST. There are a number of resources on the internet that will assist you with the requirement. You may also view our Sample Code for additional help.

Handling the Response

The following section outlines the procedure for dealing with SB responses.

After you send your XML Call the first thing you should do is check the response HTTP Status Code. View the following section for a chart of possible HTTP Status Codes.

If you get a 200 HTTP Status Code you can capture the response XML and check the Ack element for the results. The Ack element is the acknowledgment of your request. The value will be “Success”, “Warning”, or “Failure”. If you the Ack is “Success” you can proceed to parse the XML to complete the task.

If you get a 400 or 500 HTTP Status Code you should check for an ErrorResponse with additional details.

HTTP Status Code

The table below lists the HTTP Status Codes used by the SB system. HTTP Status Codes are used when processing responses.

Code Name Meaning
200 OK Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.
401 Unauthorized The username and/or password were incorrect. The session could not be authenticated.
500 Internal Server Error A generic error message, given when no more specific message is suitable.

Error Codes

Use the table below to lookup error codes returned by the SB system.

Code Type Meaning
10000 Authorization Authentication/Authorization Failed
10002 Authorization Username/Password is incorrect
20000 Internal Errors General Failure
90002 Notification API Malformed Value
90004 Notification API Unspecified Value


  • HTTP/1.1 411 Length Required
    The XML body of your request is not being sent to the API. In other words, your request is empty. The API requires the message to have a content length. To correct the error make sure you are sending valid XML.
  • HTTP/1.1 404 Not Found
    You did not type the Endpoint address correctly. Please make sure you add the trailing method name (e.g. /ActivationRequest).
  • HTTP/1.1 502
    You must POST your XML with HTTPS, not HTTP.
developer_guide/developer_guide.txt · Last modified: 2012/05/15 21:53 by matt