eBill Userguide‎ > ‎

eBill API for Developers

REST Web Service API for eBill

Introduction

The BluSynergy eBill suite offers a contemporary REST based API that is agnostic of any programming language or operating system. Please refer to these three introductory sections about general usage patterns and programming practices before commencing development. Skip to the bottom of this page, to get to the API calls organized by business entity.

1.General Approach

The established conventions with regard to the HTTP verbs is shown below. 


RESTful Web Service HTTP methods
ResourceGETPUTPOSTDELETE
Collection URL,Such as 
https://example.com /invoices/
List the members of the collection, complete with their member URIs for further navigation. For examle, list all the cars for sale.Meaning defined as "replace the entire collection with another collection".Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation.Meaning defined as "delete the entire collection".
Element URL, such as 
https://example.com /payment/12345
Retrive a representation of the addressed member of the collection expressed in an approprite MIME typeUpdate the addressed member of the collection orcreate it with the specified ID.Treats the addressed member as a collection in its own right and creates a new subordinate of it.Delete the addressed member of the collection.

Table 1.1 - RESTful web service mapping [2]


Content Negotiation - eBill will use a "format" request parameter to indicate the format. In the future, this may be extended to the ACCEPT or CONTENT_TYPE HTTP headers as well. The ContentType will be set appropriately (application/pdf, text/xml, etc.) by the application for the return.

Retrieve Examples (HTTP GET):

Note that when a multiple entities are expected, the URL maps to the plural form (eg "invoices" with a "s" at the end)

NoHTTP Verb and URL patternSuccess Response and HTTP status codeFailure Response and HTTP status code
1GET /invoice/234?format=xmlInvoice with id=234 in XML format; 200 OKerror xml; 404 Not Found
2GET /invoice/234?format=pdfInvoice with id=234 in PDF format; 200 OKAs above
3GET /invoice?format=xml& invoiceNo=INV2001Invoice with invoiceNo=INV2001 in XML format; 200 OKAs above OR 400 Bad Request if params are invalid
4GET /invoices?format=xml& startDate=2009-12-01& endDate=2009-12-31Return a list of invoices between the indicated dates; 200 OKEmpty list of ; 200 OK


Create Examples (HTTP POST):

Note that when a multiple entities are expected to be created in a single call, the URL maps to the plural form. Note that all calls are atomic from a transactional standpoint.

NoHTTP Verb and URL patternSuccess Response and HTTP status codeFailure Response and HTTP status code
1POST /customer?format=xmlCreate a new Customer and returns the id in XML format; 201 Createderror xml; 400 Bad Request
2POST /customer/894/salesContact?format=xmlCreate a new salesContact for the Customer with id-894; 201 Createderror xml; 404 Not Found (if not found) OR 400 Bad Request
3POST /customer/salesContact?format=xml& extCustomerRef=CRM392Same call as above, except that the business key (extCustomerRef) is provided instead of the id.as above
4POST /order/345/activities?format=xmlCreate multiple Activity objects and add them to the Order with id=345 ;201 Createderror xml; 404 Not Found (if found) OR 400 Bad Request (atomic operation - either all objects are created or none)


Update Examples (HTTP PUT):

In the case of an update, the payload needs to contain the entire object graph and not just the changed values. In the use cases for eBill there is not a significant need for bulk updates, so only individual objects (along with their child objects) may be updated.

NoHTTP Verb and URL patternSuccess Response and HTTP status codeSuccess Response and HTTP status code
1PUT /invoice/341?format=xmlUpdate invoice with id=341; 200 OKerror xml; 404 Not Found (if not found) OR 400 Bad Request
2PUT /customer /894/salesContact?format=xmlUpdate the salesContact for the Customer with id-894; 200 OKas above
3PUT /customer/salesContact?format=xml& extCustomerRef=CRM392Same call as above, except that the business key (extCustomerRef) is provided instead of the id.as above
4PUT /order/345/activities?format=xmlerror xml; 405 Not Allowed (Unsupported by eBill)error xml; 405 Not Allowed (Unsupported by eBill)


Delete Examples (HTTP DELETE):

Delete operations are specified by id and in some cases by the unique business key. Currently, bulk deleted are not supported.

NoHTTP Verb and URL patternSuccess Response and HTTP status codeSuccess Response and HTTP status code
1DELETE /order/341?format=xmldelete order with id=341; 200 OKerror xml; 404 Not Found (if not found) OR 400 Bad Request
2DELETE /customer /894/salesContact?format=xmlDelete the salesContact for the Customer with id-894; 200 OKas above
3DELETE /customer /salesContact?format=xml& extCustomerRef=CRM392Same call as above, except that the business key (extCustomerRef) is provided instead of the id.as above
4DELETE /order/345/activities?format=xmlerror xml; 405 Not Allowed (Unsupported by eBill)error xml; 405 Not Allowed (Unsupported by eBill)


Complex Cases (HTTP POST):

In cases where the desired operation is an action, the REST approach has its deficiencies (when compared to SOAP). These cases are handled by a POST operation with an "action" query string parameter to indicate the desired operation. Additional parameters required by the operation are passed in the XML request payload. The result of the operation may return one or more objects depending on a case-by-case basis.

NoHTTP Verb and URL patternSuccess Response and HTTP status codeSuccess Response and HTTP status code
1POST /order/341?format=xml& action=suspendSuspend order with id=341; 200 OKerror xml; 404 Not Found (if not found) OR 400 Bad Request
2POST /order/341?format=xml& action=generateInvoiceGenerate an invoice for order with id=341; 200 OKas above



2. Security

Authentication

eBill utilizes HTTP Basic Authentication for authenticating each API call. A specific "system user" must be created for each client application that will integrate with eBill. The userid and password for this system user can then be used when making the API call. Note that the eBill application is restricted to communicating using HTTPS with 256-bit SSL certificates, implying that all data including the userid and password are sent encrypted and secured.


Authorization

The application authorizes REST requests only if the security credentials associated with the caller is in the "Web Service Programmatic Access" security role. A new user may be created with this security role by using the "System >> Staff Members" menu. Be sure to set the security role on this screen to "Web Service Programmatic (API) Access"

Multi-tenancy

The established approach of using the DNS domain prefix (eg: yourcompany.blubilling.com) will ensure that the requested operation pertains to objects owned by the appropriate "tenant" (i.e., Organization). If you get a HTTP 401 (Unauthorized) return code in spite of using a valid userid/password, then chances are that you have provided an invalid domain/url when performing the API request. All API access is logged and monitored and repeated attempts to access or "scan" entities belonging to other organizations will result in suspension and deactivation of your account per the terms of service.



3. Error Payload


The error response is usually accompanied by HTTP status code of 400

Sending malformed XML payloads will usually result in this type of response:
<status>
 <success>false</success>
 <errors>
  <error>org.xml.sax.SAXParseException: Closing tag for <customer> not found</error>
  <error>Premature end of file.</error>
 </errors>
</status>


Whereas a validation error will produce these types of response:

<status>
 <success>false</success>
 <errors>
  <error>
    The paymentMethodDTO/paymentMethod/type element must be set to 
    either Cash, ACH, CreditCard or Check
  </error>
 </errors>
</status>                                                                                     

API Calls by Business Group

The following links broadly organize the API calls into distinct groups. 

4. Customer API
5. Invoice API
6. Payments API