OGWUGO API DOCUMENTATION

  1. Home
  2. Docs
  3. OGWUGO API DOCUMENTATION
  4. Getting Started

Getting Started

THE API EndPoints

Main server: https://ogwugo.com/api/v2/app

International : https://i.ogwugo.com/api/v2/app

NB: for DEMO, we will be using ogwugo.net domain thus (https://ogwugo.net/api/v2/app). You are expected to query the endpoints and get the correct RESPONSE DATA, the response data listed in documentation may not be complete.

API and Server Authorization:

Most API call require authorization, you are to obtain  API KEY for all calls that require authorization, The Authentication key (token) returned during user login is not used for api header authentication and also to keep user session across the web apps..

curl --include \
     --request POST \
     --header "Content-Type: application/json; charset=utf-8" \
     --header "Authorization: Basic b2d3dWdvX3NlcnZpY2U6ZzU3ODI3NmRzZmZkYmE=" \
     --header "user-token: 1b089e7700bee7ad9fb8cdb57553a7b62ec316a4be7b1f5cb2814050806eca72" \

 test api auth data: define("api_user", 'ogwugo_service'); define("api_password", 'g578276dsffdba'); define("api_token", 'Basic b2d3dWdvX3NlcnZpY2U6ZzU3ODI3NmRzZmZkYmE=');
test api auth data: 

define("api_user", 'ogwugo_service'); 
define("api_password", 'g578276dsffdba'); 
define("api_token", 'Basic b2d3dWdvX3NlcnZpY2U6ZzU3ODI3NmRzZmZkYmE=');
 define define define return return; its not like we are coding here, but if you don't understand then do not continue. 

NB: Most Api request require authorization. Few with sensitive user data require both Api Header Authorization and user-token for Header Authentication

 User Authentication:

The response for every user in auth/register endpoints returns

“user_token”: “TYRgfhjdfsghfjkhlgjfhdgssdfgzI5NDBlNjJj”,

“user_token_expiry”: “2018-02-15 11:17:55”

IMPORTANT: it is expected that for every  request that involve user sensitive data you post

1. Request PARAMETER : user_id

2. Header: user-token

that is (HTTP_USER_TOKEN found as data.user_token in response for api authentication). --header "user-token:

3. API auth basic. --header "Authorization

WARNING: user_id must be posted as query PARAMETER in every request that involve user sensitive data regardless of the form the user_id is required by the endpoint. thus, sometimes the API may require user_id as Arguments, for the sake of API Authentication you will still post user_id as query Parameter.

eg: /app/v2/data/{user_id}/?user_id={user_id}

eg: /app/v2/data/{user}/?user_id={user_id}

lecture:

header authorization >> gives developer access to use the api.

header authentication >> logged on user needs api token to access his data.

//////////////////////////////
REPORT & RIDERS AUTHORIZATION KEY
Basic b2d3dWdvX2Rhc2hib2FyZDpiNmUzZjVlOTg2dXRmaGc2MWJl
//////////////////////////////

GENERAL RESPONSE FORMAT.

{
 "data": null,
  "status": "failed",
 "message": "Wrong Username and password",
"error": {
  "msq": "wrong username or password detected",
  "detail": "login using username or email with correct password..",
  "code": 205
 }
}

All response format are JSON with header 200, 401, 404 and 500 (the header status code  may  not always correct therefore you can get a success with code 401 —  and so… ):;  )

DID YOU NOTICE “data”: null, ?

if your request require any data, it will come from there. the “data”: null, can also come in this format “data”: “[]”, or “data”: “{}”, that is what we call empty array.. in anyway, don’t let the content in data confuse you.

DID YOU NOTICE “status”: “failed”, ?

there are two status that you can expect, mainly this status is what you should respect and take seriously, if you try to login and you get ‘failed’, you know what that means, another option is “success“, yea, so always check your response for “failed” or “success

DID YOU NOTICE  “message”: “Wrong Username and password”,

“message” part of the response is the only content that the user should see.

WARNING: I repeat, “message” is the only one the user should see.

the “error”: {  section is for debug purpose.  eg you notice   error.detail (error dot detail)  this detail can tell you things like Unable to connect to database on port 111>> whatever, just do not display this message to the app user., thats all..

NB: in your documentation: str. = string, req = required, int. = Integer, [] = array

The main server above being the endpoint henceforth will be referred to as *base/* that means base url.

API CALL FROM MOBILE APP.

AS you can see, our user_token is used for auto login into different Ogwugo Domain. it is expected that once the expiry time is reached on web the user is required to login again, but on mobile app this should not be the case. App user can not be forced to login all the time, so what should be done.

When user login in app, store in local storage the password and user_token_expiry. if user wish to make api request make sure the time not expired, if expired kindly call the login endpoint before making the request.  the token expiry can always be set to 720hrs by default. This process will allow the user to log out of all device from his dashboard too.

IMAGES AND FILES: all images and files come from CDN so if you see image url in the doc not containing https trail, ignore and use that way, the live server will return direct image url  there.

POST BODY

Content Type: application/x-www-form-urlencoded

where to go from here?

Was this article helpful to you? Yes No

How can we help?