As we reach the end of 2024, there's a few things we want to let you know about before the holidays start.

API authentication deprecation 🌇

Back in July, we announced that Alloy's API authentication will only accept bearer tokens starting from next year. Therefore, this is one last reminder that token headers and token URL parameters will no longer work as of early January 2025.

If you haven't already, please update any integrations or tools you use accordingly!

Mobile developer account transfer 📲

As part of some new year housekeeping, we'll be transferring ownership of the Alloy Mobile app to new Causeway developer accounts on both the App Store and Google Play Store.

Don't worry, this won't affect Alloy Mobile's availability on either store! You won't need to reinstall the app and any unsynced data should be unaffected.

However, there may be some minor side effects:

• If you use your fingerprint to sign in, or rely on saved passwords, you may need enter your account details again.
• You may need to re-grant permission for Alloy Mobile to access your device's camera, gallery and location.

The developer transfer will be performed in January 2025. In the unlikely event that this causes any issues, please contact Support for assistance.

Alloy Mobile iOS map behaviour 🗺️

We will be improving the behaviour of the map in Alloy Mobile iOS:

• When selecting an item, the transition will be smoothly animated instead of abruptly jumping to the item.
• Selecting any part of an item's geometry will select the item. The map will pan and zoom so that the item's entire geometry is visible.
• With an item selected, selecting a marker on that item will zoom the map to that marker.
• If multiple item geometries overlap a location, selecting that location will cycle through those items.

Nothing too drastic but just so you know what to expect! These changes will be implemented in Alloy Mobile v2.66 on 9th January 2025. If you experience any issues with the new behaviour, please contact Support.

To interact with Alloy’s API, you must include your personal API key in every request you send. Currently, there are three possible methods for doing this. However, two of these methods can potentially expose your API key to attackers.

Therefore, we’re announcing the deprecation of these insecure methods, which will be blocked entirely from January 2025.

Going forward, please use the bearer authentication scheme to communicate with Alloy.

Who will be affected?

All users and implementations that don’t use Bearer authentication to access the Alloy API.

Details

The following authentication methods are now deprecated. They continue to work for now, but will no longer be accepted in the near future:

• A token URL parameter:
  https://uk.alloyapp.io/api/session/me?token={value}

• A token header:
  Token: {value}

From now on, the only supported method is to use the Authorization header with the bearer scheme (RFC 6750):
Authorization: Bearer {token}

Expected release

January 2025

Overview

A workflow action group lets you define a series of actions that can be stored on its own and referenced in other workflows. A workflow within a workflow, if you will.

However, now that manual workflows have parameters, they can provide this functionality in a better way. Therefore, for simplicity and consistency, we're removing workflow action groups and updating manual workflows so they can be referenced within other workflows.

Who will be affected?

Users who create and edit workflows via the Alloy API.

Details

You'll be able to reference a manual workflow in your workflow by creating an action whose design implements designInterfaces_workflowManualTrigger:

• The parametersDesignCode property must be set to the design code of the manual workflow.
• The new OutputActionId property must be set to the ID of the action that represents the final output of the referenced manual workflow. This output will be passed on to the next action in your workflow.

While it will be possible to chain multiple workflows (a workflow that references a manual workflow that references a manual workflow...), rest assured that Alloy will stop you from creating any circular references! 😮‍💨

Parameters

If the referenced manual workflow requires any parameters, you can supply them in the parameters array when adding/editing the relevant action in your workflow.

Depending on the type of WorkflowComputedItemAttributeWebModel used, you can supply values computed during your workflow, or pass on any parameter values that were supplied to your workflow when triggered.

Removed endpoints

All WorkflowActionGroup endpoints will be removed from the Alloy API.

Expected Release Date

26th October 2023 as part of the Alloy v2.52 release.

Overview

Alloy’s robust Permissions system gives you fine control over who has read/write access to most of the objects in your Alloy database (e.g. designs, layers, workflows).

To take this a step further, we introduced Access Policies. These are simple rules defined per design/interface, which ensure that users can only access items that can be traced back to them. For example, making job items only accessible to users who are members of the job’s allocated team.

While Access Policies work well in principle, the current implementation unfortunately comes with too much of a performance cost.

Therefore, Access Policies will be removed in the next Alloy release, to be replaced with a better implementation at a later date.

Who will be affected?

No active customers are currently using this feature, so we expect its removal to have zero impact.

Details

The /api/access-policy/ endpoints will be removed from the API. Any remaining access policies will be deleted.

Expected Release Date

23rd February 2023 as part of the Alloy v2.44 release.

Note

Due to a technical error, this post is being announced after the changes in Phase 1 were issued. 

Overview

When first designing Alloy, we anticipated the need for an item setting that would allow versioning. With this setting enabled, each change to the item would create a new version of the item with only the most recent item being visible in the application. While we still believe this function may hold value in the future, maintaining the feature in the application offers very little benefit over the item audit logs. Instead, the item versions consume storage space unnecessarily when enabled on designs. 

We have therefore taken the decision to remove item versioning for the time being. 

Who will this affect?

The change to remove item versioning will not impact the functionality within the system and is being made to improve performance for customers with large numbers of items. 

This work will mark the properties and endpoints marked as Obsolete to be removed at a later date. If this can cause a problem for API users, we urge you to take action during the time provided before removal as any integrations relying on obsolete properties may cease to function.  

Phase 1

Details

Both DesignWebModel and DesignInterfaceWebModel will not have the versioned property being returned anymore. It was already advertised as optional in the response and it is thus not meant to cause any problem.

The start and end properties ofItemWebModel and ReconstructedItemWebModel are now obsolete and will always return respectively 0000-01-01T00:00:00Z and 9999-12-31T12:59:59Z.

The DesignEditWebRequestModel and DesignCreateWebRequestModel will not accept the versioned property anymore. If the property is passed, it will be ignored.

The ReconstructedItemDeltaWebModel optional properties start and end will not be returned anymore.

The GET api/item-version/{itemId} and the GET api/item-version/item/{id} are now obsolete and will be removed as part of phase 2.

Phase 2

The start and end properties of ItemWebModeland ReconstructedItemWebModel  that were obsoleted during phase 1 will be removed.

The GET api/item-version/{itemId} and the GET api/item-version/item/{id} that were obsoleted during phase 1 will be removed.

Phase 1 Expected Release Date

3rd September 2021

Phase 2 Expected Release Date

March 2022

Overview

We are making changes to some of our endpoints in order to become fully OpenAPI 3.0 compliant. Additionally, we will be adding Redoc under the /docs path to provide an even easier way of navigating our API definition and explore models that use discriminators.

Who will this affect?

There are several changes to various endpoints as detailed below. None of these changes are expected to be a breaking change and the current method of calling these endpoints will remain compatible.

There will however be a Phase 2 of this work in which we will remove any obsolete endpoints and properties. API users should complete any transition to the new endpoints before the Phase 2 date to avoid issues.

Details

Delete Endpoints

The following endpoints will change to have a query parameter named signature to pass the signature. Passing the signature in the body will be obsoleted and removed in Phase 2:

DELETE api/access-policy/{code}/rule/{id}
DELETE api/custom-report/{customReportCode}/data-source/{code}
DELETE api/custom-report/{customReportCode}/document-definition/{id}
DELETE api/design/{code}/attribute/{attributeCode}
DELETE api/design/{code}/interface/{interfaceCode}
DELETE api/workflow-action-group/{code}/action/{id}
DELETE api/workflow/{code}/action/{id}

User Group Endpoints

There are 2 new user group endpoints to add and remove users from a user group:

POST api/user-group/user/add
POST api/user-group/user/remove

The following two (current) endpoints will be marked obsolete and removed in Phase 2; note, these will no longer be visible through the swagger documentation.

POST api/user-group/user
DELETE api/user-group/user

Role User Endpoints

There are 2 new role endpoints to add and remove users from a role:

POST api/role/user/add
POST api/role/user/remove

The following two (current) endpoints will be marked obsolete and removed in Phase 2; note, these will no longer be visible through the swagger documentation. 

POST api/role/user
DELETE api/role/user

Role Group Endpoints

There are 2 new role endpoints to add and remove groups from a role:

POST api/role/group/add
POST api/role/group/remove

The following two (current) endpoints will be marked obsolete and removed in Phase 2; note, these will no longer be visible through the swagger documentation. 

POST api/role/group
DELETE api/role/group

Expected Release Dates

Phase 1 : 29th September 2021

Phase 2 : 31st March 2022

Overview

In order to improve the accessibility of Alloy Meshes, we will be adding support for Open API JSON and endpoint documentation. Following a detailed review of the exposed endpoints and data models, we will also be acting to implement the following deprecations to provide better consistency between naming and conventions with the Alloy Core, Extended and Forge API's. Finally, we will be making changes to the way in which the security token is passed to the Meshes to improve security. 

Security token to be removed from query string

We will no longer be accepting the token parameter which represents an Alloy API token on the query string, this should be passed via the HTTP headers in all future requests using the same key of token.

Example CURL before:

curl -X 'POST' \
  'http://localhost:3000/aws-iot/update-device?itemId=abc?token=123' \
  -H 'accept: application/json' \

Example CURL after:

curl -X 'POST' \
  'http://localhost:3000/aws-iot/update-device?itemId=abc' \
  -H 'accept: application/json' \
  -H 'token: 123' \

MeshResponseWithItemWebModel renames property itemResponse to item

The following meshes are expected to return a response which includes an item payload under the property itemResponse.

• alloy-push-mayrise-notice-mesh
• json-push-alloy-mesh
• telensa-fault-push-alloy-mesh

This property is being renamed to item but we will continue to return itemResponse until the date specified below for Phase 2. 

Example response before:

{
  "itemResponse": {
    "itemId": "af32ef...",
    ...
  }
}

Example response after:

{
  "itemResponse": {
    "itemId": "af32ef...",
    ...
  },
  // we will duplicate the data in the recommended item property
  "item": {
    "itemId": "af32ef...",
    ...
  },
}

Risk calculation mesh to remove itemsResponse property

The risk calculation mesh alloy-push-risk-calculation-mesh is removing the itemsResponse property as it was not correctly indicating the success of the response model, it isn't required and will therefore be removed as part of Phase 1 changes. 

When do these changes take effect?

The above changes will be rolled out in June 2021, with deprecations finally removed in January 2022 with the following expected release dates: 

Expected Release Date

Phase 1: June 24th 2021

Phase 2: February 24th 2022

Overview

In an earlier announcement titled Removal of Item Title, Subtitle and Geometry properties (Phase 2), users were advised to update export AQS query to return the above attributes if they need them for their exported items. As part of these changes, we are making the ExportGeometry option obsolete as this can now be specified through the inclusion/omission of the geometry attribute in the query. 

Who will this affect?

Users querying the data with geometry via the API will be affected by the change.

Details

We are now making ExportGeometry optional and obsolete on the ExportWebRequestModel and it will be removed in due course in favour of requesting attributes_itemsGeometry as part of the export AQS attributes.

Expected Release Date

October 29th 2020