- URL:
- https://<root>/services/<serviceName>.<serviceType>/webhooks/<webhookID>/edit
- Methods:
POST- Version Introduced:
- 11.1
Access requirements
Required privileges
The Sever Administrator API requires privilege-based access. An administrator must be assigned a specific user privilege, or role, to access any given endpoint. Listed below are the user privileges or roles an administrator can be assigned that provides access to this endpoint. If multiple privileges are listed, only one needs to be assigned to gain access.
Note that administrators assigned a custom role must also have the administrative View all content privilege assigned to them to access the API directory as an administrator. Additonally, any custom roles that include a webhook-related privilege must also include the general Publish server-based layers content privilege.
Tokens
This API requires token-based authentication. A token is automatically generated for administrators who sign in to the Server Administrator API directory's HTML interface. Tokens generated in this way are stored for the entirety of the session.
Those accessing the API directory outside of the HTML interface will need to acquire a session token from the generate operation in the Portal Directory API. For security reasons, all POST requests made to the Server Administrator API must include a token in the request body.
Description
The edit operation allows administrators to update a previously configured geoprocessing or feature service webhook. Once updated, the changes will be applied immediately. If the payload URL for a webhook has changed or if the event trigger for a feature service webhook has been updated, the new trigger or payload URL will be used when the webhook is next invoked.
Webhook security
Starting at ArcGIS Enterprise 11.2, service webhooks use signature verification to ensure the integrity and security of webhook payloads sent from ArcGIS Enterprise to a webhook receiver. The input for the signature parameter acts as a shared secret key between both ArcGIS Enterprise and the webhook receiver, which is known, and stored independently by, both ArcGIS Enterprise and the webhook receiver and used to determined if the payload is trusted. When a webhooks event is triggered, the secret key and the payload are hashed using a HMAC-SHA256 algorithm, creating the signature. The signature is then passed in the webhook request as the x-esri header value. When the webhook payload is delivered to the receiver, the receiver uses the secret key and payload to create a signature of its own using the same HMAC-SHA256 algorithm that ArcGIS Enterprise used. If the signature included in the request header matches the recalculated value created by the webhook receiver, the webhook payload can be trusted by the receiver. Otherwise, the receiver may choose to reject the incoming webhook payload.
Request parameters
| Parameter | Details |
|---|---|
(Required) | The webhook name. Example Example |
(Required for feature service webhooks) | Specifies the event triggers that will invoke the webhook. For more information about the supported event triggers listed below, see the Feature service event triggers section. The values for this parameter can be submitted as a string or as an array. Values: Example |
(Optional) | A user-defined alphanumerical string. Starting at ArcGIS Enterprise 11.2, the value provided for Example Example |
(Required) | The payload URL where the payload will be delivered once the webhook is invoked. Example |
(Optional) | Specifies the media type of the resource. The media type is a string sent with the file indicating the file's format. Values: |
(Optional) | Specifies the response payload format. The default value is Values: |
(Optional) | Specifies whether callbacks will be enabled ( Values: |
(Optional for feature service webhooks) | The window for cataloging event triggers for a feature service. The modifiable values for this parameter are the Example |
| The response format. The default format is Values: |
Feature service event triggers
The table below lists the supported event triggers for feature services:
| Event | Details |
|---|---|
| Any event is triggered. |
| A feature is created. |
| A feature is updated. |
| A feature is deleted. |
| A feature is edited (e.g., insert, update, or delete). |
| A new attachment is added to a feature. |
| A feature attachment is updated. |
| A feature attachment is deleted. |
| A feature layer's schema is changed. |
| A feature layer's definition is changed. |
| A feature service's definition is changed. |
| Introduced at 11.3. The post operation is performed on the service. |
Example usages
The following is a sample POST request for the edit operation, editing a geoprocessing service webhook to use a new payload URL:
POST /<context>/admin/services/myService.GPServer/webhooks/create HTTPS/1.1
Host: organization.example.com
Content-type: application/x-www-form-urlencoded
Content-Length: []
name=Microsoft Flow&signatureKey=123456789ABCDE&hookUrl=https://app.logic.azure.com:443/workflows/80fd5c68fcd84b3491b25330680ef1&payloadFormat=pjson&active=true&f=pjsonJSON Response syntax
{
"id": "<webhook ID>",
"folderName": "<the service's root folder name>",
"serviceName": "<the service name>",
"serviceType": "<the service type>",
"name": "<webhook name>",
"changeTypes": ["event triggers"],
"signatureKey": "<signature key>",
"hookUrl": "<payload URL>",
"active": <true | false>,
"contentType": "<application/json | application/x-www-form-urlencoded",
"scheduleInfo": { //The following object is only returned when modifying a feature service webhook, as scheduling info is not applicable to geoprocessing webhooks
"name": "<user provided schedule name>",
"state": "enabled",
"startAt": <time in Epoch>,
"recurrenceInfo": {
"interval": <integer value>,
"frequency": "second"
}
},
"payloadFormat": "<json | pjson>",
"created": <time in Epoch when the webhook was created>,
"modified": <time in Epoch when the webhook was last modified.>,
"ownerId": "<user-name of the webhook's owner>",
"modifiedId": "<username of the user to last modify the webhook.>",
"status": "<success message>"
}JSON Response examples
The following is a sample JSON Response for an updated geoprocessing service webhook:
{
"id": "91ece443-746b-43eb-9ba4-d4055b771017",
"folderName": "System",
"serviceName": "CachingTools",
"serviceType": "GPServer",
"name": "UpdatedWebhook",
"changeTypes": ["*"],
"signatureKey": "12345ABCDEF",
"hookUrl": "https://app.logic.azure.com:443/workflows/...",
"active": true,
"contentType": "application/json",
"scheduleInfo": {},
"payloadFormat": "json",
"created": 1670878247288,
"modified": 1670878267973,
"ownerId": "webhookAdmin",
"modifiedId": "webhookAdmin",
"status": "success"
}