In order to interact with the API, your application must authenticate. Mobingi API handles this through OAuth. An OAuth token functions as a complete authentication request. In effect, it acts as a substitute for a username and password pair.
Compares the resource changes between two Mobingi Alm templates.
POST /v3/alm/template/compare
Parameters
Type
Required
Detail
id
array
conditional
items contain stack id and version information
body
array
conditional
items contain template body source
Note: You can compare two templates by retrieving them from their version id and stack id. Or, you can compare a target template body (posted in json format tobodyparameter) with a source template retrieved by its version id and stack id.
The current API version only supports two templates comparison, and you always should retrieve the source template by its version id and stack id. That being said, you have to always pass at least one item in parameteridarray. Below are two examples:
1. **Describe Current Logged In User Roles**
```text
Lists all roles attached to current user.
_This endpoint is requested by users instead of master account, and returns the roles that attached to them._
<div class="callout callout-info">
GET <code>/v3/user/role</code>
</div>
Request Header
```bash
Authorization: Bearer eyJ0eXAiOiJQiL...CJhbGciOMeXzQfME
Content-Type: application/json
### Attach Role to User {#rbac-attach-user-role}
Attach an existing role to a user.
**Note:** _This endpoint is denied to all users except master account, defined by_ [_default RBAC scope_](https://learn.mobingi.com/enterprise/rbac-reference#default-roles)_, and this scope cannot be overwritten._
POST `/v3/user/role`
| **Parameters** | **Type** | **Required** | **Detail** |
| --- | :---: | ---: | :--- |
| username | string | Yes | target user |
| role\_id | string | Yes | Mobingi Role Id |
Request Header
```bash
Authorization: Bearer eyJ0eXAiOiJQiL...CJhbGciOMeXzQfME
Content-Type: application/x-www-form-urlencoded
This endpoint listens to the notifications sent by Mobingi alm-agent for self status registration.
For example, when an instance is launched and Mobingi alm agent is installed, the agent will first call this endpoint to register itself.
Another example, when an AWS spot instance is scheduled to be shutdown, the agent will send notice to this endpoint and allow Mobingi system to perform other necessary actions (such as spot replacement).
POST /v3/alm/agent/agent_status
Parameters
Type
Required
Detail
stack_id
string
Yes
The stack id which this server instance is belonged to
This endpoint listens to the notifications sent by Mobingi alm-agent with the status updates during a container's lifecycle. Possible status examples: starting, updating, restarting, running, terminated, etc.
POST /v3/alm/agent/container_status
Parameters
Type
Required
Detail
stack_id
string
Yes
The stack id which this server instance is belonged to
agent_id
string
Yes
The agent's unique identifier
container_id
string
Yes
The container unique id. _Sometimes, this value could be an instance's id.
This endpoint is used by Mobingi alm-agent to describing container section of the layer configuration from Mobingi Alm Template, identified by flag name.
This value is either client_credentials or password. If you grant with password, you are interacting the same as working around Mobingi UI; If you grant with client_credentials, you are acting as an Alm-Agent, and most resource related permissions are denied by .
Note:This endpoint is denied to all users except master account, defined by, and this scope cannot be overwritten.
Note:This endpoint is denied to all users except master account, defined by, and this scope cannot be overwritten.
Note:This endpoint is denied to all users except master account, defined by, and this scope cannot be overwritten.
Note:This endpoint is denied to all users except master account, defined by, and this scope cannot be overwritten.
Note:This endpoint is denied to all users except master account, defined by, and this scope cannot be overwritten.
Note:This endpoint is denied to all users except master account, defined by, and this scope cannot be overwritten.
In this section, all endpoints are designated to work with Mobingi alm-agent in order to perform application lifecycle automation by Mobingi. Mobingi alm-agent is the Linux server side program that automatically installed during instance launch and initialization. If you are a contributor to the OSS repo, you're looking at the right reference here. If you are a developer working on integrating Mobingi ALM with your client applications or contributing to Mobingi API/UI only, you can ignore this API references section.
