Version 2.0

Released July 2020

New features

• Members can now have multiple email addresses.
• Members can now have multiple magic links.
• A member can have email addresses and magic links at the same time.
• A member can now be associated to multiple groups, with each association having its own start and end date/times.

Having multiple email addresses is useful for hotel room reserves where you have multiple guests in the same room. Now you can create the reserve as a single member that grants access to all guests.

Per-group start/end times is useful for room reservations: the same member can have multiple reservations for different rooms at different times, and he'll only be able to enter each room during the allowed time.

API changes

• Removed member fields: type, email, member_group_ids
• Removed endpoints /members/{member_id}/magic_link
• Added endpoints /members/{member_id}/emails
• Added endpoints /members/{member_id}/magic_links
• Added endpoints /members/{member_id}/group_associations

Version 1.0

Initial API release

The major version is indicated in the URL. For example https://api.akiles.app/v2 vs https://api.akiles.app/v2. The minor version is not indicated anywhere, since minor versions only do backwards-compatible changes. A client designed for API version v2.0 should work unmodified on version v2.1, provided it follows the compatibility policy outlined below.

We will release new minor versions with only backwards-compatible changes. We consider the following changes backwards-compatible:

• Adding new endpoints.
• Adding new HTTP methods to existing endpoints.
• Adding new optional fields to request objects.
• Adding new fields to response objects.
• Adding new possible values to enum fields.
• Relaxing request validation rules. For example, a field couldn't be null before and now it can.

Keep these in mind when developing your integration. For example, when parsing API responses, ignore unknown received fields instead of erroring.

Ocasionally, when backwards-incompatible changes are necessary for the healthy evolution of the platform, we will also release new major API versions. In this case, the previous major version will be supported for at least 6 months after the launch of the new major version.

There are many ways of integrating Akiles into your existing platform or service. There are two main categories:

-Sync integration (non whitelabel): The user end user will login with the Akiles app or website (magic link, without downloading any app). You can still customize and change all the related paramenters such as membership validity, permissions, sites, etc. The integration consists in syncing your existing objects (users, reservations) with Akiles so user creation and management can be fully automatic.

-Whitelabel integration: The end user will be able to access the diferent spaces through a custom experience in your app or website. You can implement any logic that will end up opening a door. This integration has extra cost and is only available with the whitelabel feature. If you plan to publish your integration and make it available to all Akiles customers, we suggest you to use the non whitelabel option.

Sync integration (non whitelabel)

In this kind of integration, the user will use the Akiles app and environment to interact with your spaces. The idea behind this integration is directly creating or editing other Akiles objects from your backend as needed. You will be able to create, edit and delete members or any other object or parameter based on your business logic.

The end user will have to login once the required member is created using any of the valid login methods. You will have to use the already flexible Akiles permission system to implement your logic.

This kind of integration is recommended for Property Management Systems, Booking systems, etc.

Example flow:

1. You get a new reservation. Just gather all the relevant details.
2. Perform a member create API call. Remember to store the returned member_id in your database

POST https://api.akiles.app/v2/organization/{organization_id}/members
Content-Type: application/json;charset=UTF-8

{
  "name": "John Doe",
}

3. Based on the reservation or booking parameters, associate a group to the recently created member. The group will determine which set of spaces the guest will have access. Do a group association create API request.

POST https://api.akiles.app/v2/organization/{organization_id}/members/{member_id}/group_associations
Content-Type: application/json;charset=UTF-8

{
  "member_group_id": "mg_3merk33gt1692dk2p2m1",
  "starts_at": "2018-03-13T16:56:51.766836837Z",
  "ends_at": "2018-03-13T16:56:51.766836837Z",
}

4. Choose a login method for the user and send an invite. For temporary applications we recommend using the magic link rather than the email. Do a magic link create API request.

POST https://api.akiles.app/v2/organization/{organization_id}/members/{member_id}/magic_links
Content-Type: application/json;charset=UTF-8

{}

5. Reveal the link. Warning: Remember that the link is able to grant access to your space. You should protect it and distribute it using a secure channel. In order to reveal the link do a magic link reveal API request.

POST https://api.akiles.app/v2/organization/{organization_id}/members/{member_id}/magic_links/{member_magic_link_id}/reveal
Content-Type: application/json;charset=UTF-8

{}

6. Send the link to the final user or display it somewhere.

Whitelabel integration

For this kind of integration the user will directly interact with the gadgets, going through a custom experience. You will be responsible for implementing a proper UX/UI and or equivalent business logic.

As an example, the final user will typically login in your platform. You will have to implement all the permissions and conditions before granting the user access to the gadget. Finally, if theese conditions are met, your backend will call the gadget action endpoint in order to perform the action. You will prevously need to call gadget list endpoint in order to get the ids.

Example flow:

1. The end user logs in into your app or website
2. Your platform checks against your backend or database if the end user meets certain requirements before accessing the action button (have a valid reservation, plan, account, etc...)
3. The user clicks the action button. Your backend does the gadget action API call with the gadget id of the gadget related to the space you want the action to happen

POST https://api.akiles.app/v2/organization/{organization_id}/gadgets/{gadget_id}
Content-Type: application/json;charset=UTF-8

{
  "id": "open",
  "name": "Open"
}

4. Handle response or error

There are two ways to authenticate to the API: API keys and OAuth.

Use API keys if you're developing integrations that you will only use with your own Akiles organization. This is the easiest and simplest way to get started, and the security benefits of OAuth don't apply to you anyway.

Use OAuth if you want other people to use your integration. The most common use case is if you are developing a SaaS and want your customers to be able to enable your integration with their own Akiles organizations.

Additionally, OAuth is required to get your application/integration listed in the Applications tab in the Akiles admin panel. Listing your application will make it discoverable to all Akiles customers.

API keys are static keys that can be used to make calls to the Akiles API.

To create an API key, login to the Akiles admin panel, and go to API -> API keys and create one. For security, you will only be able to see the full value of the API key once, when creating it.

To use the API key, include an Authorization: Bearer header with it:

Authorization: Bearer ak_3pbzqfe...

All API keys have full read-write permissions, equivalent to organization administrators. All the actions performed with the API key are attributed to it in the events.

OAuth authentication uses the standard RFC-6479 OAuth 2.0 protocol. It allows your app to interactively request access to customers' Akiles organizations and obtain access tokens for them. This makes the experience smoother and more secure, since the customer doesn't have to manually copy and paste a sensitive API key.

This section is not intended to be a full explanation on how OAuth works, just a quick reference to get started. For more info, consult online documentation about OAuth.

Client ID and Client Secret

Your OAuth application needs a Client ID and a Client Secret to operate.

• The Client ID is considered public, it is OK to expose it to frontends (and is in fact necessary to do so).
• The Client Secret must be maintained confidential since it is used to obtain access tokens. Always use it from your server, never send it or expose it to your frontend.

To obtain your application's Client ID and Secret, contact support.

Token types

• Access token: used to make API calls, expires 1 hour after issuance.
• Refresh token: used to obtain new access tokens when they expire.

There are multiple types of Access and Refresh tokens depending on how they've been obtained

• Session access/refresh token: This token is associated to an organization and a particular user's session. They get revoked in these cases:
  • The user logs out
  • The user's session expires due to inactivity
  • The user is removed as an admin from the organization
  • The application is deauthorized from the organization
• Organization access/refresh token: This token is only associated to an organization. They get revoked in these cases:
  • The application is deauthorized from the organization

When doing the authorization flow you will receive session access/refresh tokens. If you need persistent access to the organization (e.g. after the user logs out), you can do so by requesting the offline scope, and exchanging the session token for organization access/refresh tokens (see below).

Authorization flow

1. Generate a cryptographically-secure random string state and store it somewhere you can access it later (e.g. a cookie)
2. Start the flow by redirecting the user to the following URL:

https://auth.akiles.app/oauth2/auth?client_id=CLIENT_ID_HERE>&redirect_uri=https://your-app.example.com/redirect&response_type=code&scope=full_read_write&state=STATE_HERE

3. The Akiles authorization server will prompt the user to choose a user account and organization.
4. The Akiles authorization server will ask the user to authorize your requested scopes.
5. The user gets redirected to your redirect_uri:

https://your-app.example.com/redirect?code=CODE_HERE&scope=full_read_write&state=STATE_HERE

6. Check the state you have received matches the original state you stored. If it doesn't, abort. This is necessary to protect against CSRF / session poisoning attacks.
7. Exchange the authorization code for the access and refresh tokens.

POST https://auth.akiles.app/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
client_id=CLIENT_ID_HERE
client_secret=CLIENT_SECRET_HERE
code=CODE_HERE

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "access_token": "ACCESS_TOKEN_HERE",
  "expires_in": 3599,
  "refresh_token": "REFRESH_TOKEN_HERE",
  "scope": "full_read_write",
  "token_type": "bearer"
}

8. You're done! Save the access token and refresh token.

You can now use the access token to make API calls on behalf of the user's organization. The access token expires in 1 hour. You can obtain new, fresh access tokens with the refresh token.

Refresh token flow

POST https://auth.akiles.app/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
client_id=CLIENT_ID_HERE
client_secret=CLIENT_SECRET_HERE
refresh_token=REFRESH_TOKEN_HERE

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "access_token": "NEW_ACCESS_TOKEN_HERE",
  "expires_in": 3599,
  "refresh_token": "NEW_REFRESH_TOKEN_HERE",
  "scope": "full_read_write offline",
  "token_type": "bearer"
}

Store both the new access and refresh tokens. The old refresh token, once used, is no longer guaranteed to keep working forever.

Token exchange flow

If you want to exchange a session acess token for an organization access token (see "Token types" above), do the following request:

POST https://auth.akiles.app/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=token_exchange
exchange_to=organization
client_id=CLIENT_ID_HERE
client_secret=CLIENT_SECRET_HERE
refresh_token=SESSION_REFRESH_TOKEN_HERE

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "access_token": "ORGANIZATION_ACCESS_TOKEN_HERE",
  "expires_in": 3599,
  "refresh_token": "ORGANIZATION_REFRESH_TOKEN_HERE",
  "scope": "full_read_write offline",
  "token_type": "bearer"
}

Store the new access and refresh tokens. Note that unlike a normal refresh, a token exchange does not "use up" the original refresh token. You may store both session and organization tokens, and keep using and refreshing both independently.

Scopes

• full_read_write: read-write access to all the objects. Same as a regular API key, or an administrator user.
• full_read_only: read-only access to all the objects.
• offline: allows offline access. You need this to obtain refresh tokens, and to exchange session tokens for organization tokens.

Webhooks

Webhook objects are scoped to your OAuth application. That is, webhooks created with API keys or manually from the admin panel won't be visible to you, and webhooks you create won't be visible to API keys or in the admin panel.

All your application's webhooks in an organization will be deleted when your app gets deauthorized.

You must create/edit/delete webhooks with an organization access token, not with a session access token.

Even if you have read-only access, you can still create/edit/delete webhooks. This allows you to receive real-time updates in an application that only needs to read data from the Akiles organization.

The API uses cursor-based pagination. All list endpoints return data in reverse chronological order, and have the following common structure:

GET parameters

• limit: How many items to fetch, between 1 and 100
• cursor: Value of cursor_next from a previous request. If not given, it will fetch the most recent items.

Response data

• data: The received items, in a JSON array.
• has_next: Whether there are more items to fetch.
• cursor_next: Cursor to fetch the next page of items. Only present if has_next is true.

Most API objects allow you to attach your own, arbitrary key-value metadata in the metadata field. You can use it to store references to primary keys of your database, custom states, etc.

Metadata is visible to anyone with admin or API access to your organization. There is a storage limit of 1024 bytes of metadata per object.

Everything in Akiles APIs belongs to an Organization. An organization represents one Akiles customer and can handle multiple sites, gadgets, etc.. API keys are tied to organizations too, and they give access only to the objects belonging to the organization.

A site is a physical place where Akiles gadgets are installed. For example, it can be a building, a floor... Gadgets belong to a particular site.

End users will see one "card" in their app's home screen per site. The site information (email, contact, etc) is displayed in that card.

A gadget is a "thing that can be controlled" by a physical device. Gadgets can be doors, lights, heating, window blinds...

Gadgets are not "physical devices": some devices can have multiple gadgets (gateway_controllers and controllers). Others can have only one (smart locks, for example).

Gadgets can have multiple actions depending on what they are. For example, a normal door will just have an open action, but a blind can have raise and lower actions, and a light can have on and off actions. Actions are identified by their string ID, and they also have a human-friendly name for display in the UI.