Version: On prem: 15.0.0

OData REST API

DISCLAIMER

This page contains third-party references. We strive for our content to always be up-to-date, however, the content referring to external vendors may change independently of Omada. If you spot any inconsistency, please report it to our Helpdesk.

Overview

Omada Identity utilizes REST API based on OData 4.0.

info

For information on OAuth Authentication method with OData API, refer to the OAuth Authentication section in the documentation.

Headers

The Accept and Content-Type request headers are required for proper data formatting. These request headers have the following valid values:

Accept: application/json
Content-Type: application/json

POST, PUT, and PATCH operations require you to provide both headers. The GET and DELETE operations require only the Accept header. Failing to provide the required headers results in the error message 415 Unsupported Media Type.

If the Omada Identity website is configured for basic authentication, an Authorization HTTP header must be present for a registered Omada Identity user, for example:

Security

Authentication

By default, user credentials or an OAuth bearer token must be included in a REST request. The REST API supports basic authentication, integrated security, and OAuth for enforcing access controls to web resources. The user record that is used for authentication is subject to access control in the same way as the interactive user. Each request requires the proper authentication information.

To be available in the API, Data Object Types must be “Enabled for OData”. It can be done on the Data Object Type configuration page by checking “Enable for OData” option.

Moreover, the user record used for authentication is subject to access control in the same way as the interactive user. This means that:

All data objects are protected by the data object security model and access modifiers.
All master data (built-in data) are protected by authentication roles.

Authorization

The user record must have an Omada Identity Authentication Role with the OData element enabled for either Create, Read, Update, or Delete depending on the required access rights.

To be available in the API, Data Object Types must be Enabled for OData. It can be done on the Data Object Type configuration page by checking Enable for OData option.

Moreover, the user record used for authentication is subject to access control in the same way as the interactive user. This means that:

All data objects are protected by the data object security model and access modifiers.
All master data (built-in data) are protected by authentication roles.

Conventions

Here you can find information on conventions how different values and fields are represented in the API.

DateTimes

All datetime values are represented as DateTimeOffsets. This means that the time zone offset is part of the value, for example, CreateTime: 2016-10-07T12:45:40+02:00.

Multilingual fields

A multilingual field is represented as an ordinary string where the value is in the active user’s language.

On some objects, an extra field named [fieldname]MultiLang that contains the values in all languages is also available.

Example:

The multilingual field NameSingular (on a data object type) is represented both as NameSingular (holding the name in the active user’s language) and as NameSingularMultiLang (holding the name in all languages where it has been defined).

Entity and complex type reference

The OData API has two endpoints:

one for built-in object entities
one for data object entities.

This section explains the built-in entities and complex types that are exposed by the OData API.

Built-in object entities

Functions and actions

Functions can have side effects in the Omada Identity data store. All functions in Misc are in the Functions namespace. All actions in Misc are in the Actions namespace.

ChangePassword

Changes the password of an account belonging to the active user. The method is blocking and it returns only when the target system has reported a success or failure of changing the password.

Parameters

Name	Type	Notes
currentPassword	string	The user's current password in Base64.
newPassword	string	The desired new password in Base64.
accountKey	string	Not used currently. Reserved for future use. Specifies the RoPE AssignmentKey of the account for which the password must be changed.

HTTP method(s):

POST

Response list

Status code	Description
200	Indicates success.
500	Indicates that operation was unsuccessful.

Response body

Property name	Type	Description
value	string	Success

Example:

http://.../OData/Builtin/Misc/Actions.ChangePassword

Body:

{"currentPassword":"cXdlcnR5", "newPassword":"bXluZXdwYXNzd29yZA==", "accountKey":""}

CheckPasswordStrength

Checks if a password complies with the requirements of a specific password policy.

Parameters

Name	Type	Notes
password	string	The password (in Base64) to check.
policyId	string	Id or UId of a password policy data object.
identityId	string	Id or UId of the identity data object that the password is for. Is used to check that the password does not contain, for example, the first or last name of the identity.Is ignored if null/empty/0.

HTTP method(s):

POST

Response list

Status code	Description
200	Indicates success.

Response body

Property name	Type	Description
value	Bool	Returns true if the password meets the requirements of the policy.

Example:

http://.../OData/Builtin/Misc/Actions.CheckPasswordStrength

Body

{"password":"cXdlcnR5", "policyId":"da04fb27-5dc4-48f6-bf81-a91696e2850b", "identityId":"1000566"}

ConvertId

Converts the (Guid) UId of an object to its (integer) Id or vice versa.

Parameters

Property name	Type	Description
id	string	(Guid) UId or (int) Id of an object.
objectType	string	Example: "DataObject", "Timer".

HTTP method(s):

Response list

Status code	Description
200	Indicates success.

Response body

Property name	Type	Description
value	string	The converted id.

Example:

http://.../OData/Builtin/Misc/Functions.ConvertId(id='13866833-27D9-4277-93AC-AB67CE172B48',objectType='DataObject')

ResetPassword

that the caller knows the challenge ID – (s)he does so because (s)he has received it in an email.

The email challenge is updated by the method with EOC_SUCCESS=true to ensure that it can only be used once. The method is blocking and it returns only when the target system(s) has reported the success or failure of resetting the password(s).

The use of ResetPassword requires that the CIAM "standard application" package has been installed.

Parameters

Name	Type	Notes
challengeId	string	UId of an Email ownership challenge data object. The challenge must have `EOC_CAUSE="Password reset request"` and `EOC_SUCCESS=false` and must not be expired.
newPassword	string	The desired new password in Base64.

HTTP method(s):

POST

Status code	Description
200	Indicates success.
500	Indicates that operation was unsuccessful.

Response body

Property name	Type	Description
Value	string	Success

Example:

http://.../OData/Builtin/Misc/Actions.ResetPassword

Body:

{"challengeId":"D8DE8ADE-CBDF-4BFD-8301-72FBE2C95981", "newPassword":"cXdlcnR5"}

VerifyPassword

Verifies the password of an account belonging to the active user.

Parameters

Name	Type	Notes
password	string	The user's password in Base64.
accountKey	string	Not used currently - reserved for future use. Specifies the RoPE AssignmentKey of the account for which the password must be verified.

HTTP method(s):

POST

Response list

Status code	Description
200	Indicates success.
500	Indicates that operation was unsuccessful.

Response body

Property name	Type	Description
Value	string	Contains the value Success if the correct password was specified and Incorrect password if not.

GetTermsDocumentIdsPendingAcceptance

Returns the ids of terms documents, which the authenticated user has not yet accepted.

Parameters

No parameters

HTTP method(s)

Response list

Status code	Description
200	Indicates success.
500	Indicates that operation was unsuccessful.

Response body

Property name	Type	Description
value	Collection(Edm.Int32)	Returns an array of id’s of Terms Document objects not yet accepted by the active user.

Example:

http://.../OData/Builtin/Misc/Functions.GetTermsDocumentIdsPendingAcceptance()

GetAuthenticatedUserGroups

Returns the IDs of the user groups that the authenticated user is member of (considering her AuthLevel).

Parameters

No parameters

HTTP method(s)

Response list

Status code	Description
200	Indicates success.
500	Indicates that operation was unsuccessful.

Response body

Property name	Type	Description
value	Collection(Edm.Int32)	Returns an array of user group id.

Example:

http://.../OData/Builtin/Misc/Functions.GetAuthenticatedUserGroups()

AllowCIAMPortalAccess

Returns true if a specified identity's user is allowed to use the CIAM portal.

Parameters

Name	Type	Notes
identityId	string	UId or Id of an identity.

HTTP method(s)

Response list

Status code	Description
200	Indicates success.
500	Indicates that operation was unsuccessful.

Response body

Property name	Type	Description
value	bool	Returns true if the specified identity's user is allowed to use the CIAM portal.

Example:

http://.../OData/Builtin/Misc/Functions.AllowCIAMPortalAccess(identityId=’B151B6B9-5A86-4E3F-9938-441747E74C6B‘)

Data object entity and complex type reference

The OData API has two endpoints: one for built-in object entities and one for data object entities. This chapter explains the data object entities and complex types that are exposed by the OData API.

The endpoint for data objects has a dynamic schema which reflects the configuration of data object types in the Omada Identity portal. This should be considered if the API is accessed using a proxy generator as the proxy must be rebuilt when the data object model is modified.

General information

You can query data objects by using an URL in the following format:

http://[Omada Identity server]/OData/DataObjects/[System name of data object type]

In the OData API, the system name of a data object type always starts with a capital letter and all other letters are in lowercase.

Data object types that you can only maintain via a workflow are not available via OData.

For batch processing of, for example, data objects, you can use the URL in the following format:

http://[Omada Identity server]/OData/DataObjects/$batch

Data object types

OData API supports the following data object types:

users entity type:
- Besides the Common fields described in the section below, users entity type supports the following properties: Inactive, Culture, LangId, TimeZoneId, and WorkWeekId.
  - To get the ID values for the LangID, TimeZoneId, and WorkWeekId properties, you must query against them using the BuiltIn endpoint and specifying the ID number (for example, 105, 1000, or 900):
    - http://[Omada Identity server]/OData/BuiltIn/TimeZones/105
    - http://[Omada Identity server]/OData/BuiltIn/Languages/1000
    - http://[Omada Identity server]/OData/BuiltIn/WorkWeeks/900
  - Culture property corresponds to the RegionalSettings field in Omada Identity. The cultures used for this property are the ones specified by Windows language culture names. The Culture property must have the following format: languagecode-country/regioncode, for example, en-US or da-DK. For more information, refer to the Menus and settings section in the documentation.
- This entity type excludes users marked as System.
user groups entity type:
- Supports the AuthLevel property and the Members and AuthRoles navigation properties.
  - To get the Members for a given user group, you must query using the user group ID (for example, 1058) for which you want to get the list of members, for example:
    - http://[Omada Identity server]/OData/DataObjects/Usergroup/1058/Members
  - For information on how to create or delete, for example, users in a selected user group, refer to the Supported operations section below.
- Reads existing memberships and writes user group memberships (however, it excludes personal groups and groups marked as Everyone, None, and System from the scope).

important

You cannot manage users with platform admin permissions (users themselves as well as their memberships).

Common fields

All data objects have the following fields:

Name	Type	Supports	Description
Id	Edm.Int32	GET	Unique id (across all data object types) of the data object.
UID	Edm.Guid	GET	Unique id (across all data object types) of the data object. Unlike .Id, the .UID is unique across all staging environments.
CreateTime	Edm.DateTimeOffset	GET	When was the data object created?
ChangeTime	Edm.DateTimeOffset	GET	When was the data object last updated?
DisplayName	Edm.String	GET	Display name of the data object.
DeleteTime	Edm.DateTimeOffset	GET	When was the data object deleted?
Deleted	Edm.Boolean	GET	Is the data object deleted?

Property representation

A data object has the properties that are defined on the data object type.

In the table you can see the types of properties that are supported and the format of the value(s).

Property names are always in uppercase.

Property type	Property data type	OData data type
Value	Text	Edm.String
Value	Integer	Edm.Int32
Value	DateTime	Edm.DateTimeOffset
Value	Decimal	Edm.Double
Value	Boolean	Edm.Boolean
Value	Hyperlink	Edm.Hyperlink
Value	TimeSpan	Edm.Duration
Value	MultiLangText	Collection(LangString)
Value	Xml	Edm.String
Set (single valued)	n/a	SetValue
Set (multi valued)	n/a	Collection(SetValue)
Reference (single valued)	n/a	ReferenceValue
Reference (multi valued)	n/a	Collection(ReferenceValue)

Navigation properties

The following are the navigation properties:

Members
AuthRoles

For information on how to obtain the values for the navigation properties, refer to the Data object types section above.

Supported operations

The following operations are supported (HTTP methods are listed in parentheses) on all data object types:

Create (POST)

example

If you want to create and add, for example, a new AuthRole to a selected user group, follow these steps:

Query the list of the existing AuthRoles in a given user group, for example: http://[Omada Identity server]/OData/Builtin/AuthRoles. When the list is displayed, check what's the latest ID number in use. For the new AuthRole ID, you must use the subsequent number.
Use the POST method, for example, http://[Omada Identity server/OData/DataObjects/Usergroup/1048/AuthRoles/901 where:
- 1048 is the user group ID for which you want to create the AuthRole
- 901 is the ID of the new AuthRole

Read (GET)
Delete (DELETE)

example

If you want to delete, for example, an AuthRole from a selected user group, use the DELETE method, for example, http://[Omada Identity server/OData/DataObjects/Usergroup/1048/AuthRoles/901 where:

1048 is the user group ID in which the AuthRole you want to delete is
901 is the ID of the AuthRole to be deleted

Update (PUT)

Use PUT when you want to modify a single resource that is already a part of resources collection. PUT replaces the resource in its entirety.

If you want to update a collection of properties (like ATTRIBVALUES), you have to put all the values from the collection, even the one you don't want to update.

If you want to update any property, you have to put all data in that property, since it is cleared of any value it had before we apply the changes user is giving Omada Identity in the request.

If you don't want to update a property, don't put it in the request.

Example

This request:

http://[Omada Identity server]/OData/DataObjects/Resourceassignment(1000960) 

PUT
{
  "Id":1000960,
  "UId":"[GUID]", 
  "ATTRIBVALUES":[
    {"Id":111,"UId":"[GUID]","AttributeValues":[{"Name":"ATTRIBVALUE","Value":{"valueText": "\"test\""}}]},
    {"Id":222,"UId":"[GUID]","AttributeValues":[{"Name":"ATTRIBVALUE","Value":{"valueText": "\"12345\""}}]},]  
}

returns this output:

{
  "@odata.context": "http://[Omada Identity server]/OData/DataObjects/$metadata#Resourceassignment/$entity",
  "Id":1000960,
  "UId":"[GUID]",
  "ATTRIBVALUES":[
    {"Id":111,"UId":"[GUID]","AttributeValues":[{"Name":"ATTRIBVALUE","Value":{"valueText": "\"test\""}}]},
    {"Id":222,"UId":"[GUID]","AttributeValues":[{"Name":"ATTRIBVALUE","Value":{"valueText": "\"12345\""}}]},]
}

Query options

OData supports two types of query options:

System OData Query Options
Custom Query Options, that is, viewId and deletedStatus.

Expand the following sections to learn on the available query options that can be used for querying data objects:

$select

Example Find user by Id and only return the first name and last name.

http://[Omada Identity server]/OData/DataObjects/User(1001247)?$select=FIRSTNAME,LASTNAME

$orderby

It is possible to sort on all properties except:

Value properties with data type ‘Hyperlink’, ‘MultiLangText’, and ‘Xml’
Multi-valued Set properties
Multi-valued Reference properties

Apart from properties, you can sort on: Id, CreateTime, ChangeTime and DisplayName. You can sort on the maximum of two properties.

Example:

http://[Omada Identity server]/OData/DataObjects/User?$orderby=LASTNAME desc

$filter

Example:

Find users with the first name “John” and the last name “Doe".

http://[Omada Identity server]/OData/DataObjects/User?$filter=FIRSTNAME eq 'John' and LASTNAME eq 'Doe'

Supported filter operators:

Operator	Description	Valid for properties
eq	Equals	Value – all data types Set Reference
ne	Not equals	Value – all data types Set Reference
gt	Greater than	Value – Integer Value – DateTime Value – Decimal
ge	Greater than or equals	Value – Integer Value – DateTime Value – Decimal
lt	Less than	Value – Integer Value – DateTime Value – Decimal
le	Less than or equals	Value – Integer Value – DateTime Value – Decimal

The following is not supported:

Using the or operator. This is treated as and.
The following other operators: not, add, sub, mul, div, mod.
Grouping using parenthesis
Functions (such as length and endswith)

note

Filters with EnumType values should use the Namespace and EnumTypeName prefix, for example:

http://hostname/OData/DataObjects/UserGroup?$filter=AuthLevel eq OIS.AuthLevel'Low'
http://hostname/OData/DataObjects/UserGroup?$filter=AuthLevel ne OIS.AuthLevel'High'
http://hostname/OData/DataObjects/UserGroup?$filter=AuthLevel eq OIS.AuthLevel'1'

$top

Example:

http://[Omada Identity server]/OData/DataObjects/User?$top=10

$skip

Example:

http://[Omada Identity server]/OData/DataObjects/User?$skip=5

$count

This count query option is only for data objects, and not for BuiltIn objects within OI.

Example:

http://[Omada Identity server]/OData/DataObjects/ResourceAssignment?$count=true

note

Getting a count of all objects ($count=true) may make a query more expensive.

viewid

When the viewid parameter is used, only the data objects that are in the specified view are returned. The specified view must filter on the queried data object type – if not, an http error 500 is reported.

The view controls the following:

How data objects are filtered, for example, via filter expressions (similar to if $filter was used).
Which properties are present on the queried data objects (in the same fashion as if $select was used).
Sorting of the data objects.
Whether to apply an access modifier.

Example:

http://[Omada Identity server]/OData/DataObjects/User?viewid=900

deletedstatus

The deletedstatus is a custom query option for the Identity DOT with the possible values of Both, Deleted, and NotDeleted.

note

The default value is NotDeleted to preserve the current behavior.

Example:

http://[Omada Identity server]/OData/DataObjects/Identity?$top=100&$select=Id,DisplayName,CreateTime,ChangeTime,DeleteTime,Deleted&$filter=DeleteTime gt 2023-06-17&DeletedStatus=Deleted

Metadata documents

The metadata documents can be obtained via the following url: http://[Omada Identity server]/OData/Builtin/$metadata.

The available entity reference and context type reference information is available in the metadata documents that can be obtained via the following url: http://[Omada Identity server]/OData//DataObjects/$metadata.

Data Object Version check and Optimistic Concurrency

Data object version

When querying for Data Objects, the service returns an attribute for each Data Object to indicate the current version. Clients can use this attribute to construct update requests with Optimistic Concurrency behavior described in the OData spec Use of ETags forr Avoiding Update Conflicts.

The ETag attribute value is derived from the Data Object CurrentVersion Id. The Current Version Id is also added as a property to the Data Object entity, and the property is annotated with the Concurrency Annotation.

The ETag attribute value is a weak reference to the CurrentVersion of the Data Object.

For more information on the ETag, please read here.

Example of metadata returned:

<EntitySet Name="Identity" EntityType="OIS.Identity"> 

                    <Annotation Term="Org.OData.Core.V1.OptimisticConcurrency"> 

                        <Collection> 

                            <PropertyPath>CurrentVersionId</PropertyPath> 

                        </Collection> 

                    </Annotation> 

                </EntitySet>

Example of returned Data Object with version information:

{ 

    "@odata.context": "http://localhost/OData/DataObjects/$metadata#Identity/$entity", 

    "@odata.etag": "W/\"MTAyMDIyNw==\"", 

    "Id": 1008986, 

    "UId": "6a3d910d-385c-4e37-8400-af9186037ea6", 

    "CreateTime": "2021-03-11T10:27:18.433+01:00", 

    "ChangeTime": "2021-03-11T11:36:02.88+01:00", 

    "DisplayName": "Last229b, First229b [TEST229B]", 

    "CurrentVersionId": 1020227, 

    "IDENTITYID": "TEST229B", 

    "FIRSTNAME": "First229b", 

    "LASTNAME": "Last229b", 

    "EMAIL": "TEST229B@megamart.com", 

    "JOBTITLE": "Test Job Title" 

}

Optimistic concurrency

When updating a Data Object, it is possible to ensure that the object has not been updated since it was read, resulting in the last update being discarded and the caller informed that the change could not be completed.

To enable this check, an ETag value is specified in an If-Match or If-None-Match header of a Data Modification Request. The operation MUST only be invoked if the If-Match or If-None-Match condition is satisfied.

The value of the ETag header is compared to the Data Object CurrentVersion Id of the Data Object to be updated. Omada Identity returns the 412 Precondition Failed response if the supplied ETag value does not match the current ETag value for the entity. If no version is provided in the request this check is discarded and the operation is applied to the Data Object.

The check is only executed if an ETag header is included in the update request headers. This will allow existing implementations to not respect the version by omitting the attribute.

Example of an update (PUT) request using the ETag If-Match header:

PUT /OData/DataObjects/Identity(1009056) HTTP/1.1 
Host: localhost:10123 
Content-Type: application/json 
If-Match: W/"MTAyMDIxMg ==" 
Authorization: Basic YWRtaW5pc3RyYXRvcjpPbWFkYTEyMzQ1 
Content-Length: 37 


{ 

    "JOBTITLE": "New Job Title" 

} 

Batch Processing

The OData endpoint supports OData batch processing. When submitting a batch of changes to OData, the batch is handled as one transaction, and if one or more objects fail, then the entire transaction is rolled back, and the batch is failed as a whole.

The format of batch requests must follow the specification detailed in Microsoft documentation.

The batch is composed of a JSON object with the “requests” attribute containing an array of request objects. Each request object consists of various attributes encompassing a single OData request:

url contains the URL to the specific object,
body contains the individual JSON object,
atomicityGroup contains an identifier for a transaction. The individual requests will be grouped by atomicityGroup, and a transaction will surround the group. For most uses, it can be a constant string.

The URL for data object batch requests has the following format: http://[Omada Identity server]/OData/DataObjects/$batch.

The response to a batch request is a JSON object with the “responses” array of response objects, each following the layout of the request object.

Configure Okta for use with Omada Identity OData API

Create the Application

Follow the Omada guide for OpenID Connect with OKTA. This guide only explains the steps that must be performed on top of it.

Open the registered application and open the Sign On tab.

The issuer must be configured to be Dynamic (based on request domain) – write down (copy) the Audience, you’ll need it for the creation of the Authorization Server.

Authorization Server

Create

Go to Security > API > + Add Authorization Server.
Enter a meaningful name and description. Provide the Audience from the earlier created application.

Add scope

The name can be freely chosen (but must be used later when requesting a token – so remember what you’re putting in).

Add access policy

Add a policy – the configuration here is only an example – you might want to limit who’s able to access the application further.

Add a policy rule

Add Machine2Machine application

Go to Applications > Create a new app integration.
Select API Services.
Provide a meaningful name.
Note down Client ID and Client Secret.

Configure the Omada Identity Cloud environment

Client ID

This is the ClientID from the first Application that you’ve created (The OIDC – OpenID Connect one).

OKTA Base URL

This is the Issuer URI from the Authorization Server that you created earlier without the https:// prefix

Apply the configuration. Once the configuration has been applied, continue with the creation of the user for the Machine2Machine in Omada Identity Cloud.

Create user for Machine2Machine in Omada Identity

Create a user Account for the Machine2Machine API Service. The Client ID of the Machine2Machine API Service is the Username.
Choose the required access – this is an example.

Retrieve token

Delete this text and replace it with your own content.

curl --location --request POST 'https://dev-505878.okta.com/oauth2/ausc0u4lq9sPySN5W4x7/v1/token' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=omadaIdentityCloud' \
--data-urlencode 'client_id=0oac0u9d6tyk2YNRZ4x7' \
--data-urlencode 'client_secret=K7OUT06zBsn-E2Csh8u-8t8ssMgKL3KdHWWZd8Ke'

The URL can be taken from the Authorization Server Metadata URI.

The client_id and client_secret are taken from the earlier configuration or creation of the Machine2Machine API Service.

Make a test OData Call

curl --location --request GET 'https://nbo.omadadev.cloud/OData/DataObjects/Identity' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Bearer eyJraWQiOiJCeXpVTzRtemlFTEZGTV81WG9uTlFrd2M4SmtCTVo4SU4xYkxFdHVfLVZJIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULnpUcUhHTDlfMUh1XzFTTkRjeTFGYlBIZHlwQnJGcHpWbEpLZjNpNkUyQlUiLCJpc3MiOiJodHRwczovL2Rldi01MDU4Nzgub2t0YS5jb20vb2F1dGgyL2F1c2MwdTRscTlzUHlTTjVXNHg3IiwiYXVkIjoiMG9hYzBzaGU5MlprTm5wOUM0eDciLCJpYXQiOjE2ODAyNjE3ODUsImV4cCI6MTY4MDI2NTM4NSwiY2lkIjoiMG9hYzB1OWQ2dHlrMllOUlo0eDciLCJzY3AiOlsib21hZGFJZGVudGl0eUNsb3VkIl0sInN1YiI6IjBvYWMwdTlkNnR5azJZTlJaNHg3In0.EsPt1r6QPp8VGkG9IKIZDqBtppbYEl4lI0vCP03KTn5Y8kpcapYS6hK0nEFwE7rky0UZTR2-9mtify20z1eFl8oFY3NzLdZ96kZixINcECFlMiLBSiSjDvFD4lA8f3xOfJjy_HxDEV6I5wfdFAUJaBm0SbpepDUEI6zFBJgsO_pI1n0omSWwseok-3GORJXTYlnvGEF-qJiUQvro6_89UJRDEDk-dhWizwk1UPvZ8CYUC9J-90OqPpMmdzxpMeQCIwmzY8HbRhmhuV0LO4VEry9g9pdPkLZhYSRm0SCBbqyW_dVzJ5aOUVBKrkh5daWbSlY6SZnWRe4GP8vMLR0nUw' \

Copy the access_token and use it for an Odata test call.

End result

Applications

Authorization Servers

Overview​

Headers​

Security​

Conventions​

DateTimes​

Multilingual fields​

Entity and complex type reference​

Built-in object entities​

Functions and actions​

Data object entity and complex type reference​

General information​

Data object types​

Query options​

Metadata documents​

Data Object Version check and Optimistic Concurrency​

Data object version​

Optimistic concurrency​

Batch Processing​

Configure Okta for use with Omada Identity OData API​

Create the Application​

Authorization Server​

Add Machine2Machine application​

Configure the Omada Identity Cloud environment​

Create user for Machine2Machine in Omada Identity​

Retrieve token​

Make a test OData Call​

End result​

Overview

Headers

Security

Conventions

DateTimes

Multilingual fields

Entity and complex type reference

Built-in object entities

Functions and actions

Data object entity and complex type reference

General information

Data object types

Query options

Metadata documents

Data Object Version check and Optimistic Concurrency

Data object version

Optimistic concurrency

Batch Processing

Configure Okta for use with Omada Identity OData API

Create the Application

Authorization Server

Add Machine2Machine application

Configure the Omada Identity Cloud environment

Create user for Machine2Machine in Omada Identity

Retrieve token

Make a test OData Call

End result