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 on the Equitri protocol page.
In order to use this API, the organization must have at least a SystemID and Endpoint. 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.41.0 | 17-09-2026 | Added File is archived to the unavailableReason enum, reported per attachment on both taskFetch and taskAttachment when the stored file has been removed (this can happen once a task has been closed or delivered for 2+ years). Downloading such an attachment now returns a 410 Gone response with the message File is archived (the existing 410 for a virus-scan-failed file is now documented as well). |
| 1.40.0 | 03-09-2026 | Added a location field to the calculateRoutingRules request. |
| 1.39.0 | 20-08-2026 | Documented attachment limits on the upload endpoints: 5 MB per file, 50 MB total per task, 20 attachments per task, and the allowed file types. The 50 MB and 20-file limits apply per task across all calls, not per request — an inTask and its outTask share one total. Uploading past 20 files is now rejected with 400 (TASK.MAX_AMOUNT_FILE_UPLOADED_IS_EXCEEDED), and uploading past the 50 MB total is also rejected with 400. |
| 1.38.0 | 20-08-2026 | Updated the description of taskInfo.HASInfo.SolutionParty. |
| 1.37.0 | 05-08-2026 | Added an optional networkType filter (FIBER or COAX) to POST /SP/{orgId}/tasks/search (Task Search), and added a networkType field to each task result. The filter is optional and case-sensitive; an unrecognized value returns a 4xx response. The response’s networkType is always present and always either FIBER or COAX — a task with no stored value is reported as FIBER. |
| 1.36.0 | 23-07-2026 | calculateRoutingRules is added as a new API endpoint is added. Gridsz will return the party that the tasks will be routed to based on provided input (This does not create any order; it is merely to proactively determine the routing-outcome before any order is created). The isPrivate field is removed from labels. This is only an update on the documentation as the field was never implemented on the InTask API for labels. The field remains available to be used on the OutTask API (unchanged). |
| 1.35.0 | 05-06-2026 | Change Mose.Shared.Models.ActiveOperatorTask.deadlines.name field max length from 3-99 to 3-50 and remove required attribute from ActiveOperatorTaskSync.MainStatus to match current behavior |
| 1.34.0 | 06-05-2026 | Added new field SolutionParty for FTU_CHANGE and DAMAGE_REPORT (already available on INCIDENT, QUOTE and NETWORK_DISCREPANCY) |
| 1.33.0 | 30-04-2026 | Added new field requestorIsExecutor – used when the requesting party (AO) needs to route the task to themselves |
| 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) |
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.39.0 | 01-10-2026 | Added a description for email validation. |
| 1.38.0 | 11-09-2026 | Increased the attachment upload limit from 20 to 75. |
| 1.37.0 | 17-09-2026 | Added File is archived to the unavailableReason enum, reported per attachment on both taskFetch and taskAttachment when the stored file has been removed (this can happen once a task has been closed or delivered for 2+ years). Downloading such an attachment now returns a 410 Gone response with the message File is archived (the existing 410 for a virus-scan-failed file is now documented as well). |
| 1.36.0 | 20-08-2026 | Documented attachment limits on the upload endpoints: 5 MB per file, 50 MB total per task, 20 attachments per task, and the allowed file types. The 50 MB and 20-file limits apply per task across all calls, not per request — an outTask and its inTask share one total. Uploading past 20 files is now rejected with 400 (TASK.MAX_AMOUNT_FILE_UPLOADED_IS_EXCEEDED), and uploading past the 50 MB total is also rejected with 400. |
| 1.35.0 | 05-06-2026 | Change Mose.Shared.Models.ActiveOperatorTask.deadlines.name field max length from 3-99 to 3-50 and remove required attribute from ActiveOperatorTaskSync.MainStatus to match current behavior |
| 1.34.0 | 05-05-2026 | Change taskInfo → hasInfo → afterConnect → (deliveredFTUType and deliveredConnectionStatus) from Required to Optional |
| 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! |