Skip to main content

Introduction

This is a API reference for the EIPAAS REST service.

Security/Authentication

EIPAAS REST API utilizes Bearer authentication (also called token authentication). This HTTP authentication schema involves security tokens called bearer tokens. The Bearer authentication scheme was originally created as part of OAuth 2.0 in RFC 6750, but is sometimes also used on its own. The client must send this token in the Authorization header when making requests to protected resources:

Authorization: Bearer <token>

There are two different options in order to obtain the bearer token: EDICOM Accounts or EIPAAS Api Keys, described in the Security/Authentication section.

You can also obtain and set a Bearer token in order to use the HTTP test calls that you will find in this documentation.

Required headers

Header NameDescription
AuthorizationThe access token that allows you to make request to the API on behalf of a user
X-Eipaas-DsA string indicating the datasource

IMPORTANT: Include these headers in every API request.

Example request with headers

GET /api/v1/domain/DOMAIN HTTP/1.1
Authorization: Bearer iOiJtdWx0aWFkbWluIiwiYXpwIjoiYmMyNDEwYWMtYjVjYy00NTViLTkxNmYtMmJhY2NlYjgxNjJkIiwiaXNzIjoiaHR0cDpcL1wvbG9jYWxob3N0OjkwODBcL29wZW5pZFwvIiwiZXhwIjoxNTEwNTg5Mzg4LCJpYXQiOjE1MTA1ODU3ODgsImp0aSI6IjgyY2NlOTM4LWY3N2QtNGJkOS05Yzk4LTgyZTZhMDZjMDE4NCJ9.T3aEdv_aXHpQbqfRBv_VM85wJjrU6xVR8fQYCPytMKmCNXST0015JSaCrYTeNe3PWqKDGQ43l1B70Bgaq5WnihzuH5MlMUFXYssAcLpUdEFhZ5-z65JDKzrWpRP1xuu-iIkdP4ze67DQBRPEq707Q4Q1Yrg_Hvb-o4MKy-wBI_UGNWUDQbIsAgHDtTnRUXOFnqlpWFoD3hB-8gQ_PTu7YHeQpb6fBgBbxwTl19hcWyqpO8sFzUTdKLx3u6voH0XGkl5eR6qGodWr_M-0IDtziK8BGzP_9RGOfHD7Tk2dh9q-d-_B7jLFdMEYiqaOLwkGxLwEbGRFQISfhWMScaIkmw
X-eipaas-ds: ASPEDIXX
Host: ipaasgw.edicomgroup.com
$ curl 'https://ipaasgw.edicomgroup.com/api/v1/domain/DOMAIN' -i -X GET \
-H 'Authorization: Bearer iOiJtdWx0aWFkbWluIiwiYXpwIjoiYmMyNDEwYWMtYjVjYy00NTViLTkxNmYtMmJhY2NlYjgxNjJkIiwiaXNzIjoiaHR0cDpcL1wvbG9jYWxob3N0OjkwODBcL29wZW5pZFwvIiwiZXhwIjoxNTEwNTg5Mzg4LCJpYXQiOjE1MTA1ODU3ODgsImp0aSI6IjgyY2NlOTM4LWY3N2QtNGJkOS05Yzk4LTgyZTZhMDZjMDE4NCJ9.T3aEdv_aXHpQbqfRBv_VM85wJjrU6xVR8fQYCPytMKmCNXST0015JSaCrYTeNe3PWqKDGQ43l1B70Bgaq5WnihzuH5MlMUFXYssAcLpUdEFhZ5-z65JDKzrWpRP1xuu-iIkdP4ze67DQBRPEq707Q4Q1Yrg_Hvb-o4MKy-wBI_UGNWUDQbIsAgHDtTnRUXOFnqlpWFoD3hB-8gQ_PTu7YHeQpb6fBgBbxwTl19hcWyqpO8sFzUTdKLx3u6voH0XGkl5eR6qGodWr_M-0IDtziK8BGzP_9RGOfHD7Tk2dh9q-d-_B7jLFdMEYiqaOLwkGxLwEbGRFQISfhWMScaIkmw' \
-H 'X-eipaas-ds: ASPEDIXX'

HTTP status codes

Person-service tries to adhere as closely as possible to standard HTTP and REST conventions in its use of HTTP status codes.

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.

201 Created

The request has been fulfilled and resulted in a new resource being created.

204 No Content

The server successfully processed the request, but is not returning any content.

400 Bad Request

The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

401 Unauthorized

The request did not include an authentication token or the authentication token was expired

403 Forbidden

The client did not have permission to access the requested resource.

404 Not Found

The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

409 Conflict

The request could not be completed due to a conflict with the current state of the target resource. More info may be returned in response body.

500 Internal Error

The server encountered an unexpected condition which prevented it from fulfilling the request due to an internal error on the server side.