Fusion RESTful APIs use HTTPS to serve API requests and acknowledge them with appropriate status codes. Each API is supplemented with syntax, description, and examples, helping you build your banking product.

HTTP methods

Standard HTTP verbs/methods are used to make requests to Fusion server. For example, POST is used to create resource and GET is used to fetch resource details.

Data format

All Fusion API requests and responses are in JSON data format. Hence, specify the header parameter Content-Type as application/json when making requests.

API versioning

APIs on Fusion are versioned using URI path versioning—API version is included in the endpoint URI in the format vX, where X is the version number. APIs are up-versioned when a breaking change is made, like change in the response data format for one or more requests.

Example: /api/v1/ifi/{ifiID}/bundles

API idempotency

Fusion APIs are idempotent. Making repeated requests will not change the result beyond the first try. This prevents duplication and also allows you to safely retry a request in case of failure. Fusion platform supports unique idempotent key for each API request.

Authentication

Fusion uses OAuth with bearer tokens to authenticate and authorize API requests. Fusion uses the tokens to identify the calling application/user and also verifies if they have the necessary permission to make the request. Tokens are provided to you on request and carry an expiration. To use your token, assign it to X-Zeta-AuthToken parameter in the authorization header when making requests. All API requests must be made over HTTPS; requests over HTTP and without authentication token will fail.

Environments

Fusion provides separate environments to test and launch your Fusion product. Each environment requires different access privileges and authentication tokens. 

User Acceptance Testing (UAT)

Fusion provides a fully-functional UAT environment that allows you to safely experiment with Fusion's services before going live. It is a replica of the production environment, where you can interact with Fusion APIs to understand the platform and ecosystem. You can build your banking product and simulate various transaction scenarios and functionalities.

Production

Production is where you go live with your Fusion product. This is the server that your application interacts in the real-world to provide your users Fusion-powered banking functionalities. While the Production environment provides complete access to Fusion banking, the capabilities accessible to you depend on the business agreement between you and Zeta.

Service Uptime Dashboard

Service Uptime Dashboard publishes status information of Zeta's customer services. The status page consists of three sections:

• Uptime Showcase: For every individual service, a color-coded bar displays the daily status and overall uptime percentage over a 90-day period. You can also view historical service availability segregated month-wise.
• System Metrics: Daily, weekly and monthly performance report of individual service based on response time.
• Past Incidents:  Incidents reported over a 15-day period are listed in this section. You can also view history of reported incidents segregated month-wise.

You can subscribe to status updates via email, SMS, or Atom/RSS feeds to receive notifications regarding incidents reported for various services.

Response codes

Fusion uses standard HTTP status codes to indicate the status of your API request. The codes are categorized into:

• 2xx (Successful): Call is executed successfully.
• 4xx (Client error) : Error due to the provided information in the request.
• 5xx (Server error) : Error with Fusion server.

Fusion API library