---
title: "Create or update webhooks in a batch"
method: POST
path: "/entities/Webhooks/batch-modify"
tags: ["Webhook"]
---

# Create or update webhooks in a batch

`POST /entities/Webhooks/batch-modify`

## Request

- Base URL: `https://us-east.api.coevera.com/api/v100/rest/spaces/your_space_id`
- URL: `https://us-east.api.coevera.com/api/v100/rest/spaces/your_space_id/entities/Webhooks/batch-modify`
- Auth: HTTP basic
- TypeScript: <https://skmtc.dev/coevera/apis/coevera-crm-api/docs/entities/Webhooks/batch-modify/post.ts> (a function with typed inputs; its response is checked against the schema)

An item with an `id` updates that webhook; an item without one creates a webhook.

## Query parameters

- `validation-level` integer
- `rollback-method` 0 | 1

## Request body

- BatchWebhookInput[]
  - `insecure_ssl` boolean: If True, remote side ssl certificate will not be validated when delivering notifications.
  - `options` object: Params in REST API format (snake case), to modify the content of the WebHook. You can set "entity" options of the main entity on which the event occurs. E.g. Account for events like Account.Create, Account.Update, Account.Delete. For events with a secondary related entity you can also options under key "related_entity". E.g. for Account.LinkedDocument event, the "expand" option of CloudObject(Document) can be set under "related_entity" key. Filter follows REST API conventions: https://developers.coevera.com/reference/rest/ In addition, to REST params, you can conditionally trigger webhook only when specified fields will change. You can use "on-field-change" param and provide a list of api names on which this change will listen. The "on-field-change" option is available for Account, Appointment, Task, Contact, Opportunity, Lead, Product Line Item, Project, Quote and Custom Entity. Suppressing Webhooks You can specify list of strings under "skip_keys" key in options. Whenever you make an API request with header "Webhook-Skip-Key" equal to any of the specified skip keys, the Webhook will not be triggered. This can prevent a Webhook loop. Example: { "entity": { "Contact": { "expand": [ "primary_account", "primary_contact", "task_relations.task" ], "load-only": [ "id", "primary_account", "primary_contact.first_name", "task_relations.task" ], "filter": { "email1": ["test@example.com", "test@example.net"], "email2": "test@example.com" }, "filter-op": {"email1": "eq"}, # optional, default operator is eq "on-field-change": ["email1"] }, "Account": { "filter": { "owner_id": ["9900cce6-bcd6-412a-bcd1-1904556c949a"] } } }, "related_entity": {"expand": ["contact"], "load-only": ["id", "contact"]}, "skip_keys": ["gmail_sync", "custom_integration"], "chunk_size": 100, // defines the size of the chunk, default is 100, max is 100. "chunk_delay": 300, // each chunk will be delayed by N * chunk_delay seconds, where N is index of chunk, default is 0. "custom_entity_api_name": ["CE_Name1", "CE_Name2"] // in case of triggered custom entity, this will execute webhooks only for specified ones within the list. Default are all custom entity types. }
  - `signature` string, uuid: Signature to verify webhook (has to be UUID). When signature is set, then all webhook requests will be signed using HMAC-SHA256. This signature will be used as key and request body as message. Signature will be located in "WebHook-Signature" header.
  - `url` string: Target URL that webhook event payloads are POSTed to.
  - `events` string[]: Event types this webhook subscribes to (e.g. Account.Create, Lead.Update). At least one event is required; the webhook fires whenever any subscribed event occurs in the team space.
  - `id` string, uuid: ID of object to update.

## Response `200`

Result per item, in request order: the id of the created or updated record, or the error.

- object
  - `success` boolean: True when the request succeeded; false on error.
  - `data` union[]
    - union
      - string, uuid: Id of the created or updated record.
      - Error: The body of every REST error. `code` and `name` are stable identifiers; `message` is for people. The full list of codes is at https://developers.coevera.com/reference/errors/.
        - `http_status` integer, required: HTTP status code.
        - `code` integer: Numeric code of the API error.
        - `name` string: Name of the API error.
        - `message` string: Message describing the error.
        - `success` boolean, required: Always false on error.

## Other responses

- `400`: Bad request: a bad or unknown parameter (codes 117, 118), a missing permission (code 50), conflicting data (code 2002) or any other API error. The REST API answers 400 where others answer 403 or 409; check `code`.
- `401`: Not authenticated: missing or wrong credentials, a credential of another space, or an expired token (code 401, ERROR_UNAUTHORIZED).
- `422`: Validation failed (code 40000, with the failing fields) or a required parameter is missing (code 119). By default one failed item fails a whole batch and nothing is written.
- `429`: Too many requests (code 182). Wait for the seconds in Retry-After, then retry.
- `500`: Unexpected server error (code 1000, ERROR_UNKNOWN).

---

[API](https://skmtc.dev/coevera/apis/coevera-crm-api.md) - [All operations](https://skmtc.dev/coevera/apis/coevera-crm-api/llms.txt) - [OpenAPI document](https://skmtc.dev/coevera/apis/coevera-crm-api/revisions/40ebbc83f179?raw)