About
This is the reference for the Exepron REST API. This API is the primary way to interact with Exepron remotely, whether you are building an app, scripting interactions with Exepron or developing any other integration. This page documents the REST resources available in Exepron , along with expected HTTP response codes and sample requests.A note about the V1 API
The v1 API is currently in beta. Note that while all endpoints from the v1 API are available, they are currently under development. This means that any endpoint can change at any time, although we will not introduce breaking changes without advanced notice.Getting Started
If you haven't integrated with Exepron before, start by reading "Integrating with Exepron" guide. The guide will introduce you to the Exepron Connect framework, as well as Exepron features and services that you can use when building an app. Then, read our Getting started guide to learn how to set up a development environment and build a Exepron app.Authentication
Autheticatication with Exepron Rest API is done using OpenID Connect protocol which is a layer on top of OAuth 2.0, so some understanding of OAuth 2.0 terms and flows is helpful.
OpenID Connect specifies four roles: resource owner, resource server, client, and authorization server. The following table defines the roles and shows how the roles work in the context of Exepron API.
Exepron APIs use the OpenId Connect protocol for authentication and authorization. Exepron supports common authentication scenarios such as those for a client trying to access Exepron REST Api through a web server and client-side applications.
To begin, obtain a client id from the Exepron Development website. Then your client application requests an access token from the Exepron Identity Server, extracts a token from the response, and sends the token to the Exepron API that you want to access. For an interactive demonstration of using Exepron Identity Server with Exepron API click “Test” on the menu on the left.
This page gives an overview of the authorization scenarios that Exepron supports, and provides links to more detailed content. For details about using OpenId Connect protocol for authentication, see OpenID Connect Protocol definitions.
Basic steps
All applications follow a basic pattern when accessing an Exepron API using OpenId Connect protocol. At a high level, you follow four steps:
1. Obtain development credentials from the Exepron API Development Site.
Visit the Exepron.com to obtain development credentials such as a client ID and client secret that are known to both Exepron and your application. The set of values varies based on what type of application you are building. For example, a JavaScript application does not require a secret, but a web server application does.
2. Obtain an access token from the Exepron Identity Server.
Before your application can access private data using an Exepron API, it must obtain an access token that grants access to that API. A single access token can grant varying degrees of access to multiple APIs. A variable parameter called scope controls the set of resources and operations that an access token permits. During the access-token request, your application sends one or more values in the scope parameter.
There are several ways to make this request, and they vary based on the type of application you are building. For example, a JavaScript application might request an access token using a browser redirect to Exepron, while an application installed on a device that has no browser uses web service requests.
Some requests require an authentication step where the user logs in with their Exepron account. After logging in, the user is asked whether they are willing to grant the permissions that your application is requesting. This process is called user consent.
If the user grants the permission, the Exepron Authorization Server sends your application an access token (or an authorization code that your application can use to obtain an access token). If the user does not grant the permission, the server returns an error.
After an application obtains an access token, it sends the token to an Exepron API call in an HTTP authorization header. It is possible to send tokens as URI query-string parameters, but we don't recommend it, because URI parameters can end up in log files that are not completely secure. Also, it is good practice to avoid creating unnecessary URI parameter names.
Access tokens are valid only for the set of operations and resources described in the scope of the token request.
3. Refresh the access token, if necessary.
Access tokens have limited lifetimes. If your application needs access to an Exepron API beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.
note: Save refresh tokens in secure long-term storage and continue to use them as long as they remain valid. Limits apply to the number of refresh tokens that are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens to go over one of the limits, older refresh tokens stop working.OData protocol operations
Exepron suppprt a variety of OData operations. The following table depicts those operations
| Option | Description |
|---|---|
| $expand | Expands related entities inline. |
| $filter | Filters the results, based on a Boolean condition. |
| $inlinecount | Tells the server to include the total count of matching entities in the response. (Useful for server-side paging.) |
| $orderby | Sorts the results. |
| $select | Selects which properties to include in the response. |
| $skip | Skips the first n results. |
| $top | Returns only the first n the results. |