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.32.0 | 13-03-2026 | Update production url to api.task.gridsz.com |
| 1.30.0 | 22-01-2026 | Add contact details to root object |
| 1.29.0 | 22-01-2026 | The field assignedSolutionParty has been added to the root level on the taskFetch (GET) – This field outlines which party is assigned the task(set) to be completed for this order/ticket – This field is exclusively filled by Gridsz – The value can be updated by Gridsz, in case the order/ticket is re-assigne For the ActiveEquipmentEndpoint and ActiveEquipmentEndpointMulti, the row field is no longer required – As the row is often not required to execute the work, the validation is relaxed – Additionally, the field is now set to nullable |
| 1.28.1 | 08-01-2026 | For the Contact person schema, the fields lastName and phoneNumber are no longer required – This supports a broader range of contact scenarios where full personal details are not available or necessary – Now, there is no required field for the Contact Person – any field can be provided and updated when relevant and available The object networkDiscrepancyInfo is added to taskInfo – Through this, the new tasktype NETWORK_DISCREPANCY can be created – outlining a (potential) difference between the administration and physical reality. Add a new endpoint with tag taskSearch – This endpoint can be used to find tasks on a specific address or connection Other minor changes which are already live: Add a new endpoint for OAuth2 under the tag authorization – Gridsz is gradually rolling out OAuth2 for all Gridsz API’s – this will be communicated in large scale later – Important: existing Bearer tokens will remain valid until expired The $ character is now accepted for the AddressCode Bug Fix: Gridsz will now correctly fill the reasons[] data on status PROVIDED |
| 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.33.0 | 02-04-2026 | Add the field outTaskCount to the taskset |
| 1.31.0 | 05-03-2026 | – Add POP info to task Info – Update production url to api.task.gridsz.com |
| 1.29.0 | 05-02-2026 | – Add contact details to root object – Add coordinates to afterConnect |
| 1.28.0 | 22-01-2026 | For the ActiveEquipmentEndpoint and ActiveEquipmentEndpointMulti, the row field is no longer required – As the row is often not required to execute the work, the validation is relaxed – Additionally, the field is now set to nullable |
| 1.27.0 | 08-01-2025 | For the Contact person schema, the fields lastName and phoneNumber are no longer required – This supports a broader range of contact scenarios where full personal details are not available or necessary – Now, there is no required field for the Contact Person – any field can be provided and updated when relevant and available The object networkDiscrepancyInfo is added to taskInfo – Through this, the new tasktype NETWORK_INCONSISTENCY can be received – outlining a (potential) difference between the administration and physical reality. The field coaxPathDescription is added to the TechnicalPath – This field will be filled by Gridsz for COAX tasks , based on available data in Availability Other minor changes which are already live: Add a new endpoint for OAuth2 under the tag authorization – Gridsz is gradually rolling out OAuth2 for all Gridsz API’s – this will be communicated in large scale later – Important: existing Bearer tokens will remain valid until expired The $ character is now accepted for the AddressCode |
| 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! |