This event is triggered when a Pull encounters an error while running.

Read the type value from the webhook request body.

If PROVIDER_ERROR: An error occurred on the carrier's end which prevents the pull from completing. The pull will likely not be completed and the consumer should wait and try to resubmit later.
If INTERNAL_ERROR: An error occurred on our our end which prevents the pull from completing. We have been notified of the issue and the pull MAY receive future webhooks (including COMPLETED when we resolve the issue.)

Webhook Request Format

The webhook is a POST request with a JSON body that will look like the following:

{
  "widget_id": "<WIDGET_ID>",
  "team_id": "<TEAM_ID>",
  "pull_id": "<PULL_ID>",
  "status": "PROVIDER_ERROR",
  "meta_data": {... developer-supplied JSON-serializable metadata ...},
  "event_type": "ERROR",
  "account_identifier": "<ACCOUNT_IDENTIFIER>",
  "is_monitored": true,
  "monitoring": { // Only exists if is_monitored=true
    "initial_pull_id": "<PULL_ID>", // The ID of the original Pull being monitored
    "monitoring_id": "<MONITORING_ID>" // The ID of the Monitoring
  },
  "data": { 
    "type": "PROVIDER_ERROR",
  }
}

Data key	Data description
type	The type of error the Pull encountered. Possible values: `PROVIDER_ERROR`, `INTERNAL_ERROR`, and for servicing requests also `VALIDATION_ERROR`.
servicing_action_ids	Servicing requests only. IDs of the `ServicingActions` that did not reach the carrier.

ERROR webhook for Servicing pulls

For a servicing request, ERROR is sent once per request, when at least one ServicingAction did not reach the carrier. Its pull_type is SERVICING and its pull_id is the servicing Pull. data.type is usually VALIDATION_ERROR, and data.servicing_action_ids lists the actions that did not reach the carrier; use GET /servicings/:servicingActionId or the latest SERVICING_STATUS_UPDATED webhook for each one to see why.