# Delivery services

Select a payment system or a delivery service. Create your own records using a registered REST handler. Scope: `delivery`.

Built-in services are readable. Bitrix24 permits updates and deletion only for REST-handler records; OAuth applications are also checked against handler ownership. The sale scope alone is insufficient.

## Operations

- [List](./delivery-services/list.md) — `GET /v1/delivery-services`
- [Get](./delivery-services/get.md) — `GET /v1/delivery-services/:id`
- [Create](./delivery-services/create.md) — `POST /v1/delivery-services`
- [Update](./delivery-services/update.md) — `PATCH /v1/delivery-services/:id`
- [Delete](./delivery-services/delete.md) — `DELETE /v1/delivery-services/:id`
- [Handlers](./delivery-services/handlers.md) — `GET /v1/delivery-services/handlers`

## Key fields

Pass id as the shipment deliveryId. parentId links a profile to its parent service. logotype is a file ID, not a URL.

[All fields](./delivery-services/fields.md).

## Before you start

Handlers are registered separately: these routes only read their definitions. active uses Y/N strings, not booleans.

Without active delivery is active (Y); sort defaults to 100. Creation returns parent and profiles; a profile can also be used in a shipment.

## Typical workflow

Read handlers, select a code, create an inactive VIBE-PROBE record, read it, update name, then delete only your own record. Readback can fail after a successful write: do not blindly retry creation.

## Limits

Lists are complete, without limit/offset; meta.total equals data length. No search, aggregate or generic batch. Logo: logo [filename, base64], up to 2 MiB decoded, JSON body up to 3 MiB. SETTINGS/CONFIG are accepted only on creation.

## Write restrictions

| Record | GET | PATCH / DELETE |
|---|---|---|
| Built-in | Yes | 403 |
| REST | Yes | Subject to Bitrix24 rights and OAuth ownership |

## Related entities

- [Shipments](/docs/entities/shipments)
- [CRM deliveries](/docs/entities/crm-deliveries)