The Workflow API (previously known as TASK API) is a REST API that follows the OpenAPI specifications. The API can be used for tasks within both the Order fulfilment and Service & incidents module but distinguishes between inTask and outTask (links pointing to the Swagger UI).
The API makes use of the Equitri protocol in order to keep all systems in sync. This means that for every update there is an Indication, followed by a Fetch and finished with a Sync. This concerns both updates that the organization offers to Gridsz and updates that Gridsz offers to the organization.
Please find further details and a visual explanation below:
In order to use this API, the organization must have a configured System and token. In order to do this, please provide the following details in a support ticket – or alternatively, configure this yourself in the Admin Portal if you are a Site Admin:
- Cluster – indicates for which clusters (networks) this system can be used
- SystemID – the unique ID per organization to recognize the system
- Endpoint – the endpoint to which all API calls must go
- Token – the token provided by organization (this will be used by Gridsz when calling the system endpoint)
- Default endpoint
Additionally, please be aware that the API is behind IP whitelisting. Contact Gridsz support to have IP addresses whitelisted, per environment.
inTask API
The InTask API is meant for organizations that would like to create tasks. This can concerns Active Operators creating installation orders, Network Owners creating POP Incidents, et cetera.
Release Notes
| Version | Release Date | Notes |
|---|---|---|
| 1.27.4 | 13-11-2025 | The field sendImpactNotification is added under incidentInfo. – This optional boolean field indicates whether IMPACT_NOTIFICATION tasktypes may be created by Gridsz. – By default, if serviceAffecting = false then sendImpactNotification = false, and vice versa for true. |
| 1.27.3 | 02-10-2025 | The object linkedTasks now has three additional fields: subStatus, addressCode, reasons [array]. – This additional data is meant to provide extra insights on the status of related tasks |
| 1.27.2 | 02-10-2025 | The field networkType now has a default value of “FIBER“. – This only applies to new tasks being created, where the value will be set initially upon creation – Existing tasks will not be affected by this, and will retain their current networkType (even if it’s null) |
| 1.27.1 | 03-04-2025 | Made changes to the linkedTasks on root level. – The taskType field now gets validated according to Enum values – Added the following fields: mainStatus, planned, orgId The linkedTasks will now also be pro-actively be utilized by Gridsz, by automatically linking tasks which are related to each other, but do not originate from the same order / ticket For example: in the case an INSTALL is created on an address which already has an open FTU_CHANGE task. By linking these tasks and showing some important data, such as the status, involved parties can have a good overview |
| 1.27.0 | 20-03-2025 | Gridsz can now support Multi Fiber orders. – Meaning it is possible to provide multiple fibers belonging to a single connection in one order For example, creating an INSTALL order and requesting both Fiber 1 and Fiber 2 – In order to support this, we have added the following new objects to the API: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo These fields will only be filled if the Network Owner or Active Operators requests a multi-fiber connection on their order, by providing multiple fibers This means that for a large majority of Gridsz users and systems, these fields will never be filled! |
| 1.26.9 | 06-03-2025 | Added the field externalCorrelationId to the root level. – This field can be provided when creating a new order – The field cannot be updated – It is an optional field to provide – The field can be filled by the requestor to correlate a task from their internal system to the Gridsz task |
outTask API
The OutTask API is meant for organizations that will receive tasks that they need to execute. This can concerns Contractors receiving patch requests, NOC’s further investigating Network Incidents, et cetera
Release Notes
| Version | Release Date | Notes |
|---|---|---|
| 1.25.3 | 02-10-2025 | The object linkedTasks now has three additional fields: subStatus, addressCode, reasons [array]. – This additional data is meant to provide extra insights on the status of related tasks |
| 1.25.2 | 26-06-2025 | Added the field externalCorrelationId to the root level – This field can only be provided by the party creating the order (InTask) – The field cannot be updated – It is an optional field to provide – The field can be filled by the requestor to correlate a task from their internal system to the Gridsz task |
| 1.25.1 | 03-04-2025 | Made changes to the linkedTasks on root level. – The taskType field now gets validated according to Enum values – Added the following fields: mainStatus, planned, orgId The linkedTasks will now also be pro-actively be utilized by Gridsz, by automatically linking tasks which are related to each other, but do not originate from the same order / ticket For example: in the case an INSTALL is created on an address which already has an open FTU_CHANGE task. By linking these tasks and showing some important data, such as the status, involved parties can have a good overview |
| 1.25.0 | 20-03-2025 | Added an isPrivate Boolean to Labels – By default, a label is not private |
| 1.24.0 | 06-03-2025 | Gridsz can now support Multi Fiber orders. – Meaning it is possible to receive multiple fibers belonging to a single connection in one task For example, receiving both Fiber 1 and Fiber 2 for an FTU_CONSTRUCT Note: the PATCH based tasks will always concern 1 Fiber at a time, meaning it is possible to have two PATCH_INSTALL’s in one taskset – In order to support this, we have added the following new objects to the API: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo These fields will only be filled if the Network Owner or Active Operators requests a multi-fiber connection on their order, by providing multiple fibers This means that for a large majority of Gridsz users and systems, these fields will never be filled! |