De Workflow API (voorheen bekend als TASK API) is een REST API die de OpenAPI specificaties volgt. De API kan worden gebruikt voor taken binnen zowel de module Order fulfilment als de module Service & incidenten, maar maakt onderscheid tussen inTask en outTask (links die verwijzen naar de Swagger UI).
De API maakt gebruik van het Equitri protocol om alle systemen synchroon te houden. Dit betekent dat er voor elke update een Indicatie is, gevolgd door een Fetch en afgesloten met een Sync. Dit betreft zowel updates die de organisatie aanbiedt aan Gridsz als updates die Gridsz aanbiedt aan de organisatie.
Hieronder vind je meer details en een visuele uitleg:
Om deze API te kunnen gebruiken, moet de organisatie een geconfigureerd Systeem en token hebben. Geef hiervoor de volgende gegevens op in een support - of configureer dit zelf in het beheerportaal als je sitebeheerder bent:
- Cluster - geeft aan voor welke clusters (netwerken) dit systeem kan worden gebruikt
- SystemID - de unieke ID per organisatie om het systeem te herkennen
- Eindpunt - het eindpunt waar alle API-aanroepen naartoe moeten gaan
- Token - het token dat door de organisatie is verstrekt (dit wordt door Gridsz gebruikt wanneer het systeemeindpunt wordt aangeroepen)
- Standaard eindpunt
Houd er bovendien rekening mee dat de API achter IP-whitelisting zit. Neem contact op met Gridsz support om IP-adressen te laten whitelisten, per omgeving.
inTask API
De InTask API is bedoeld voor organisaties die taken willen aanmaken. Dit kunnen Active Operators zijn die installatieorders aanmaken, Network Owners die POP-Incidenten aanmaken, enzovoort.
Release-opmerkingen
| Versie | Verschijningsdatum | Opmerkingen |
|---|---|---|
| 1.32.0 | 13 maart 2026 | Wijzig de productie-URL in api.task.gridsz.com |
| 1.30.0 | 22-01-2026 | Contactgegevens toevoegen aan het hoofdobject |
| 1.29.0 | 22-01-2026 | Het veld assignedSolutionParty is toegevoegd aan het hoofdniveau op de taskFetch (GET)- . Dit veld geeft aan welke partij de taak (set) toegewezen heeft gekregen die voor deze order/dit ticket moet worden voltooid. – Dit veld wordt uitsluitend ingevuld doorGridsz – De waarde kan worden bijgewerkt doorGridsz, in het geval dat de order/het ticket opnieuw wordt toegewezen Voor ActiveEquipmentEndpoint en ActiveEquipmentEndpointMulti is het rijveld niet langer vereist – Aangezien de rij vaak niet nodig is om het werk uit te voeren, is de validatie versoepeld – Bovendien is het veld nu ingesteld op nullable |
| 1.28.1 | 08-01-2026 | Voor het schema Contactpersoon zijn de velden lastName en phoneNumber niet langer vereist – Dit ondersteunt een breder scala aan contactscenario's waarin volledige persoonlijke gegevens niet beschikbaar of niet nodig zijn – Er is nu geen verplicht veld meer voor de contactpersoon – elk veld kan worden ingevuld en bijgewerkt wanneer dit relevant en beschikbaar is Het objectnetworkDiscrepancyInfo istoegevoegd aan taskInfo – Hierdoor kan het nieuwe tasktype NETWORK_DISCREPANCY worden aangemaakt – waarmee een (mogelijk) verschil tussen de administratie en de fysieke realiteit wordt geschetst. Voeg een nieuw eindpunt toe met de tagtaskSearch – Dit eindpunt kan worden gebruikt om taken op een specifiek adres of een specifieke verbinding te vinden Andere kleine wijzigingen die al live zijn: Voeg een nieuw eindpunt toe voorOAuth2 onderde tagauthorization – Gridsz OAuth2 geleidelijk Gridsz voor alleGridsz – dit zal later op grote schaal worden gecommuniceerd – Belangrijk: bestaande Bearer-tokens blijven geldig tot ze verlopenzijn Het $-teken wordt nu geaccepteerd voor de AddressCode Bugfix:Gridsz nu correct de reasons[] -gegevensGridsz bij de status PROVIDED |
| 1.27.4 | 13-11-2025 | Het veld sendImpactNotification wordt toegevoegd onder incidentInfo. - Dit optionele booleaanse veld geeft aan of IMPACT_NOTIFICATION tasktypes mogen worden aangemaakt door Gridsz. - Standaard, als serviceAffecting = false dan is sendImpactNotification = false, en vice versa voor true. |
| 1.27.3 | 02-10-2025 | Het object linkedTasks heeft nu drie extra velden: subStatus, addressCode, reasons [array]. - Deze extra gegevens zijn bedoeld om extra inzicht te geven in de status van gerelateerde taken. |
| 1.27.2 | 02-10-2025 | Het veld networkType heeft nu een standaardwaarde van "FIBER". - Dit is alleen van toepassing op nieuwe taken die worden aangemaakt, waarbij de waarde aanvankelijk wordt ingesteld bij het aanmaken - Bestaande taken worden hierdoor niet beïnvloed en behouden hun huidige networkType (zelfs als het null is). |
| 1.27.1 | 03-04-2025 | Wijzigingen aangebracht in de linkedTasks op root-niveau. - Het taskType-veld wordt nu gevalideerd volgens Enum-waarden - De volgende velden toegevoegd: mainStatus, gepland, orgId De linkedTasks worden nu ook proactief gebruikt door Gridsz, door automatisch taken te koppelen die aan elkaar gerelateerd zijn, maar niet afkomstig zijn van dezelfde order/ticket Bijvoorbeeld: in het geval dat een INSTALL wordt aangemaakt op een adres dat al een open FTU_CHANGE-taak heeft. Door deze taken te koppelen en een aantal belangrijke gegevens te tonen, zoals de status, kunnen betrokken partijen een goed overzicht krijgen. |
| 1.27.0 | 20-03-2025 | Gridsz kan nu Multi Fiber orders support . - Dit betekent dat het mogelijk is om meerdere vezels behorende bij één verbinding in één order te leveren Bijvoorbeeld door een INSTALL order aan te maken en zowel Fiber 1 als Fiber 2 aan te vragen - Om dit support hebben we de volgende nieuwe objecten aan de API toegevoegd: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo Deze velden worden alleen gevuld als de Neteigenaar of Actieve Operators een multi-vezelverbinding op hun order aanvragen, door meerdere vezels aan te leveren Dit betekent dat voor een grote meerderheid van Gridsz en -systemen deze velden nooit gevuld zullen worden! |
| 1.26.9 | 06-03-2025 | Het veld externalCorrelationId is toegevoegd aan het hoofdniveau. - Dit veld kan worden ingevuld bij het maken van een nieuwe bestelling - Het veld kan niet worden bijgewerkt - Het is een optioneel veld om op te geven - Het veld kan worden ingevuld door de aanvrager om een taak uit hun interne systeem te correleren aan de Gridsz . |
outTask API
De OutTask API is bedoeld voor organisaties die taken ontvangen die ze moeten uitvoeren. Dit kan gaan om Aannemers die patchverzoeken ontvangen, NOC's die netwerkincidenten verder onderzoeken, enzovoort.
Release-opmerkingen
| Versie | Verschijningsdatum | Opmerkingen |
|---|---|---|
| 1.33.0 | 2 april 2026 | Voeg het veld outTaskCount toe aan de takenlijst |
| 1.31.0 | 5 maart 2026 | – Voeg POP-gegevens toe aan de taakinfo – Wijzig de productie-URL in api.task.gridsz.com |
| 1.29.0 | 5 februari 2026 | – Voeg contactgegevens toe aan het hoofdobject – Voeg coördinaten toe aan afterConnect |
| 1.28.0 | 22-01-2026 | Voor ActiveEquipmentEndpoint en ActiveEquipmentEndpointMulti is het rijveld niet langer vereist – Aangezien de rij vaak niet nodig is om het werk uit te voeren, is de validatie versoepeld – Bovendien is het veld nu ingesteld op nullable. |
| 1.27.0 | 08-01-2025 | Voor het schema Contactpersoon zijn de velden lastName en phoneNumber niet langer vereist – Dit ondersteunt een breder scala aan contactscenario's waarin volledige persoonlijke gegevens niet beschikbaar of niet nodig zijn – Er is nu geen verplicht veld meer voor de contactpersoon – elk veld kan worden ingevuld en bijgewerkt wanneer dit relevant en beschikbaar is Het objectnetworkDiscrepancyInfo istoegevoegd aan taskInfo – Hierdoor kan het nieuwe tasktype NETWORK_INCONSISTENCY worden ontvangen – waarmee een (mogelijk) verschil tussen de administratie en de fysieke realiteit wordt geschetst. Het veldcoaxPathDescription istoegevoegd aan TechnicalPath – Dit veld wordt door Gridsz ingevuld Gridsz COAX-taken, op basis van beschikbare gegevens in Availability Andere kleine wijzigingen die al live zijn: Voeg een nieuw eindpunt voorOAuth2toeonderde tagauthorization – Gridsz OAuth2 geleidelijk uit voor alle Gridsz – dit zal later op grote schaal worden gecommuniceerd – Belangrijk: bestaande Bearer-tokens blijven geldig tot ze verlopen Het $-teken wordt nu geaccepteerd voor de AddressCode |
| 1.25.3 | 02-10-2025 | Het object linkedTasks heeft nu drie extra velden: subStatus, addressCode, reasons [array]. - Deze extra gegevens zijn bedoeld om extra inzicht te geven in de status van gerelateerde taken. |
| 1.25.2 | 26-06-2025 | Het veld externalCorrelationId is toegevoegd aan het hoofdniveau - Dit veld kan alleen worden ingevuld door de partij die de bestelling aanmaakt (InTask) - Het veld kan niet worden bijgewerkt - Het is een optioneel veld om op te geven - Het veld kan worden ingevuld door de aanvrager om een taak uit hun interne systeem te correleren aan de Gridsz . |
| 1.25.1 | 03-04-2025 | Wijzigingen aangebracht in de linkedTasks op root-niveau. - Het taskType-veld wordt nu gevalideerd volgens Enum-waarden - De volgende velden toegevoegd: mainStatus, gepland, orgId De linkedTasks worden nu ook proactief gebruikt door Gridsz, door automatisch taken te koppelen die aan elkaar gerelateerd zijn, maar niet afkomstig zijn van dezelfde order/ticket Bijvoorbeeld: in het geval dat een INSTALL wordt aangemaakt op een adres dat al een open FTU_CHANGE-taak heeft. Door deze taken te koppelen en een aantal belangrijke gegevens te tonen, zoals de status, kunnen betrokken partijen een goed overzicht krijgen. |
| 1.25.0 | 20-03-2025 | Een isPrivate Boolean toegevoegd aan Labels - Standaard is een label niet privé. |
| 1.24.0 | 06-03-2025 | Gridsz kan nu Multi Fiber orders support . - Dit betekent dat het mogelijk is om meerdere vezels te ontvangen die behoren tot één verbinding in één taak Bijvoorbeeld, het ontvangen van zowel vezel 1 als vezel 2 voor een FTU_CONSTRUCT Opmerking: de PATCH gebaseerde taken zullen altijd betrekking hebben op 1 vezel per keer, wat betekent dat het mogelijk is om twee PATCH_INSTALL's in één taakset te hebben - Om dit support , hebben we de volgende nieuwe objecten toegevoegd aan de API: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo Deze velden worden alleen gevuld als de Netwerkeigenaar of Actieve Operators een multi-vezelverbinding op hun order aanvragen, door meerdere vezels te leveren Dit betekent dat voor een grote meerderheid van Gridsz en systemen deze velden nooit gevuld zullen worden! |