HomeGuidesAPI explorerSign upLog in

REST APIs 101

Suggest Edits

REST

The Jenga Payment Gateway APIs are organized to conform the design principles of Representational State Transfer (REST). We also use the JSON data format for requests and responses. Whether you will be using our APIs directly to make your own custom checkout or will interact with our SDKs for your mobile apps or JavaScript library for your website, it's still worth taking the time to familiarize yourself on how REST APIs work and what they can do for you.

Our REST APIs are designed to be simple to understand and use, as well as be predictable with standard HTTP response codes for any and all API errors to allow you to interact securely with the API from any client-side web or mobile application. Check out the API explorer for more information on specific endpoints, their parameters and response data formats.

All our APIs require authentication and you can read more about this on our Authentication guide.

We're pragmatic in our approach and not avid RESTafarians for the benefit of application developers. We put developers first and advocate for their success when using our APIs above conforming to design principles that may make our product less friendly to use. Through these guides and API reference, we try to make using our platform as simple as possible and our success is measured on how quickly developers can integrate and make use of our products 🤓.

📘

Have suggestions on how we can improve our guides and documentation?

We do our best to keep the simple things simple and intuitive.

If you feel that our guides or documentation need simplifying, feel free to let us know! Tap on the 'Suggest Edits' button at the top of any of our pages and provide your feedback! We'd love to hear from you!

Six Guiding Principles

There are six key principles and architectural constraints for REST APIs. You can scroll down to the section on Resources for more information about REST APIs.

Client-Server
This is the separation of the user interface from the backend application (for portability and flexibility)

Stateless
Information required for a request is provided without providing a context - therefore, sessions have to be maintained on the client

Cacheable
Response data is declared explicitly as cacheable or not

Uniform Interface
Four main constraints:

  • Identification of resources
  • Manipulation of resources through representations
  • Self-descriptive messages
  • Hypermedia as the engine of application state

Layered System
Each path in an API is independent of another and cannot "see" beyond

Code on Demand
Allowing download of resources like applets for additional functionality (optional)

GET, POST, PATCH, DELETE

Our APIs are HTTP-based and data sent and received securely over SSL. To retrieve data from the API, methods will require a GET request. To submit, change or destroy data will require a POST. DELETE will also be accepted for destroying data.

Versioning

We version all our API resources. Currently we only have one version available on our guides and tutorials - v2. Before we make a version obsolete or deprecated, we'll send out a communication and provide more information about what's changed in our What's New section of our guides and tutorials.

Not sure which version we're on? In our API explorer you'll find that our endpoints are structured in the following format:

{protocol}://{host}/{basePath}/{resource}

Below is an example for generating an access token where api.equitybankgroup.com is the host for all resources.

https://uat.finserve.africa/authentication/api/v3/authenticate/merchant

Resources

Below are some resources that we recommend for you to learn more about APIs and RESTful principles:

Updated almost 2 years ago