The ButterflyMX API V3 implements the Authorization Grant Type Flow and issues an access_token along with a refresh_token. The Authorization Code grant type is used by confidential and public clients to exchange an authorization code for an access token.

Obtaining an authorization code (Authentication)

To begin the authorization flow, your application will need to construct a URL like the following and open a browser to that URL: https://accountssandbox.butterflymx.com/oauth/authorize?client_id=$CLIENT_ID&redirect_uri=https://usersandbox.butterflymx.com/oauth/callbacks/butterflymx&response_type=code&client_secret=$CLIENT_SECRET

Obtaining an access_token

To obtain a valid access_token and refresh_token, your application will need to send the $CLIENT_ID, $CLIENT_SECRET and $code to the ButterflyMX token endpoint:

curl --location --request POST 'https://accountssandbox.butterflymx.com/oauth/token' \
--form 'grant_type=authorization_code' \
--form 'code=$code' \
--form 'client_id=$CLIENT_ID' \
--form 'client_secret=$CLIENT_SECRET' \
--form 'redirect_uri=https://usersandbox.butterflymx.com/oauth/callbacks/butterflymx'

Response sample in case of success:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJ0eXAi...TcV3Q",
    "token_type": "bearer",
    "expires_in": 7200,
    "refresh_token": "6d8cd1d...9f75",
    "created_at": 1506068201
}

Response sample in case that your $CLIENT_ID doesn't exist, or you didn't include your $CLIENT_SECRET in the request:

{
  "error": "invalid_client",
  "error_description": "Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method."
}

Renewal of the access_token

After access_token expiration, an app can call the same API authentication endpoint to exchange the refresh_token for a new, valid access_token:

curl -X POST "https://accountssandbox.butterflymx.com/oauth/token" \
  -d grant_type=refresh_token \
  -d refresh_token=6d8cd1d...9f75 \
  -d client_id=$CLIENT_ID \
  -d client_secret=$CLIENT_SECRET

Response sample in case of success:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJ0eXAi...",
    "token_type": "bearer",
    "expires_in": 7200,
    "refresh_token": "6d8cd1d...",
    "created_at": 1506068601
}

Note: After successful refresh action, the mobile app has to store new access_token and refresh_token (both are changed)!

Last issued refresh_token doesn't expire (it is valid indefinitely) but is still subject to invalidation for other reasons. In case that on the renewal request server responds with HTTP status 401, the app should immediately log-off user.

Response status 401, in this case, means that this refresh_token is invalid and refresh operation will not be possible. For example, if the mobile phone is stolen or compromised, the refresh_token can be invalidated on the server side.

User Password Change

Users can change their password by sending a PUT or PATCH request to the ButterflyMX Accounts API. All password change requests need to include the access_token in the Authorization header like this:

curl -X PUT 'https://accounts.butterflymx.com/api/v1/password' \
  -H 'Authorization:Bearer eyJ0eXAi...TcV3Q' \
  --data-urlencode 'account[current_password]=password' \
  --data-urlencode 'account[password]=new_password' \
  --data-urlencode 'account[password_confirmation]=new_password'

In case of the successful password change, the server will return HTTP status 204 No Content.

In case that current password was not correct, the server will respond with a ‘Wrong password’ message in the errors key, like this:

  HTTP/1.1 422 Unprocessable Entity
  Content-Type: application/json

  { "errors" : "Wrong password" }

In case of any other errors while updating password, full error messages will be returned. The most common (and probably only) case where this could happen is when there is a password and password_confirmation values mismatch, like this:

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{ "errors" : ["Password confirmation doesn't match Password"] }

User Roles

Authenticated user can have any of the following roles (authorizations):

• Tenant
• Unit Admin
• Zone Admin
• Building Admin

Data Models

ButterflyMX Building model is divided into zones (e.g., residential, business, etc.). Zones can't overlap. Each zone can contain many units. A unit can be apartment, office, garage, etc.

• building has many zones
• zone belongs to only one building
• zone has many units
• unit belongs to only one zone
• user can be a tenant in many units
• unit can have many tenants (users)

ButterflyMX API V3 implements latest JSON API Specification (v1.0) published at: http://jsonapi.org/format/

Pagination

Pagination use query parameters such as page[number] and page[size].

For example:

GET https://apisandbox.butterflymx.com/v3/door_releases?page[size]=10&?page[number]=2
Accept: application/vnd.api+json

Sorting

Note: Examples are not url-encoded for a better readability

Example:

GET https://apisandbox.butterflymx.com/v3/door_releases?sort=name,created_at
Accept: application/vnd.api+json

Multiple Sort You can sort on multiple fields like this:

GET https://apisandbox.butterflymx.com/v3/door_releases?sort=name,created_at
Accept: application/vnd.api+json

Descendant Sort Note: The sort order for each attribute is ascending unless it is prefixed with a minus (U+002D HYPHEN-MINUS, -), in which case it is descending.

You can make desc sort with the character - like this:

GET https://apisandbox.butterflymx.com/v3/door_releases?sort=-created_at
Accept: application/vnd.api+json

Multiple Sort with Descendant Sort

GET https://apisandbox.butterflymx.com/v3/door_releases?sort=-created_at,name
Accept: application/vnd.api+json

The above example should return the newest door releases first. Any door release created on the same moment then be sorted by their name in ascending alphabetical order.

Filtering

Examples:

GET https://apisandbox.butterflymx.com/v3/door_releases?filter[unit]=11
Accept: application/vnd.api+json

or

GET https://apisandbox.butterflymx.com/v3/door_releases?filter[unit]=11&filter[user]=22
Accept: application/vnd.api+json

Check each resource to see which fields can be filtered.

Inclusion of related resources

Some endpoints can have other resources included, check the endpoint documentation to see which resources can be included for that endpoint.

Example:

GET https://apisandbox.butterflymx.com/v3/me?include=buildings,units
Accept: application/vnd.api+json

You can read more about includes here

Note: symbol ✓ marks permission on all entries in the authorized scope (e.g. all buildings where the Building Admin is authorized for administration* etc.)

Fields that can be changed by the building admin:

• name (String)
• time_zone (String)
• building_type (String)
• display_name_strategy (String), one of the allowed values:
  • building
  • custom
  • first_name_and_last_name
  • first_name_initial_and_last_name
  • anonymous
  • first_name_and_last_name_initial
• send_panel_status_report (Boolean)
• panel_logo (File)
• mobile_logo (File)
• remove_panel_logo (Boolean)
• remove_mobile_logo (Boolean)
• qr_key_enabled (Boolean)
• door_release_pin (String)
• in_unit_phone_number (String)
• address_1 (String)
• address_2 (String)
• city (String)
• state (String)
• zip_code (String)
• phone_number (String)
• country (String)

Integrations

Allowed integrators:

• webhook

Allowed config attributes for integrators:

• webhook
  • url (String)
  • method (String get or post)

Allowed binding resource types:

• call
• door_release

When call is VOIP:

• initializing
• canceled
• timeout_online_signal
• voip_connected

When call is mobile:

• initializing
• canceled
• timeout_online_signal
• connecting_sip
• voip_rollover
• rejected

Sortable fields:

• created_at
• logged_at
• notification_type
• call_type

Filterable fields:

• unit -> integer
• notification_type -> enum(string)
• call_type -> enum(string)
• guid -> string

Enumerations:

• call_type:
  • voip
  • mobile
• notification_type:
  • visitor
  • delivery

Note: symbol ✓ marks permission on all entries in the authorized scope (e.g. all buildings where the Building Admin is authorized for administration* etc.)

Request Samples with Filter:

GET /v3/door_releases?unit_id=11

GET /v3/door_releases?user_id=22

GET /v3/door_releases?unit_id=11&user_id=22

GET /v3/door_releases?door_release_type=delivery

Request Samples with Sort:

GET /v3/door_releases?sort=created

GET /v3/door_releases?sort=-created,name

The sort order for each attribute is ascending unless it is prefixed with a minus (U+002D HYPHEN-MINUS, “-“), in which case it is descending.

Allowed values for:

• release_method:
  • mobile
  • panel
  • qr_key
  • nfc
  • voip
• door_release_type:
  • visitor
  • delivery
• panel_user_type:
  • default
  • doorman