Editing API

Create and update features, equipment and connections with a batch edit request.

Last updated: 10 November 2026

On this page

Request format Operation and entity types Updating and deleting Connection endpoints Placement and route relationships Applying the response

Request format

POST /api/p/{pid}/edit accepts JSON:

{
  "request_id": "ornek-duzenleme-001",
  "note": "Planlanan saha kaydı",
  "ops": [
    {
      "op": "create",
      "entity": "feature",
      "id": "gecici-dolap",
      "type": "cabinet",
      "geometry": {"type": "Point", "coordinates": [32.0, 39.0]},
      "props": {"name": "Dağıtım noktası", "status": "planned"}
    },
    {
      "op": "create",
      "entity": "equipment",
      "id": "gecici-odf",
      "type": "odf",
      "node_id": "gecici-dolap",
      "props": {"ports": 24, "label": "Panel A"}
    }
  ]
}

This example creates a field cabinet followed by an ODF attached to that cabinet in the same request. Coordinates are examples. The id fields are client temporary references; the server creates permanent identifiers. Operations run in order, so a reference may point to a record created earlier in the request.

Top-level ops accepts 1–2,000 items and note up to 500 characters. See Concurrency for request_id rules.

Operation and entity types

op is create, update or delete. If entity is omitted, it defaults to feature.

`entity`	Purpose	Main fields when creating
`feature`	Map feature	`type`, appropriate `geometry`; `ref_layer_id` for `ref`
`equipment`	Fiber equipment	Equipment `type`, `node_id` or appropriate `parent_id`, and type-specific `props`
`connection`	Fiber/port connection	`node_id`, `a`, `b`
`relation`	Placement, entrance or route	`type`, `child`, `parent`; optional `seq`, `via`, `via_no` for routes
`talep_item`	Address and building planning records	Subtype and relevant building/unit fields
`fiber_item`	Fiber and allocation records	Subtype-specific fields; rules may require the dedicated allocation workflow
`circuit`	Technical circuit	Anchors `a`, `b`, and `props`; optional `endpoint_id`
`optik_item`	Optical profile, selection and measurement	Subtype-specific `props`; calculations are created through a dedicated endpoint

Not all types in this table support unrestricted CRUD operations. For example, a source-unit row cannot be created directly and an optical calculation cannot be updated. Writing optical profiles and selections requires administrator permission. Electric entities are Coming soon and are excluded from this integration scope.

Updating and deleting

Replace the identifier and version in this body with the values you last read:

{
  "request_id": "ornek-duzenleme-002",
  "ops": [
    {
      "op": "update",
      "entity": "feature",
      "id": "DOL-123",
      "version": 1,
      "props": {"status": "existing", "note": null}
    }
  ]
}

Omitted attributes are retained; an explicit null in props removes that attribute. Send geometry to change the geometry. Location quality is edited through method, verified and accuracy_m in the quality object; obtain permitted choices from the catalogue.

Deletion example:

{
  "request_id": "ornek-duzenleme-003",
  "ops": [
    {"op": "delete", "entity": "feature", "id": "DOL-123", "version": 2}
  ]
}

Deletion can also affect dependent records. Read a feature's details and relationships before sending the operation. Use the set of changed records returned in the successful response.

Connection endpoints

A fiber end and a port on the rear face of an ODF have the following form. The referenced cable and equipment must belong to the same project; the cable must terminate at the connection's node.

{
  "op": "create",
  "entity": "connection",
  "node_id": "DOL-123",
  "a": {"t": "fiber", "cable": "KB-456", "n": 1},
  "b": {"t": "port", "eq": "ODF-789", "side": "in", "n": 1},
  "props": {"kind": "splice"}
}

Place this object in the ops array. Port faces are in and out; numbering starts at 1. If a fiber or port is already connected at that node, a new connection is rejected with 409. Connection endpoints cannot be changed by a general update; delete the existing connection and create a new one. Use location_id and slot for splice-tray placement.

Placement and route relationships

This example places an existing splice closure inside an existing manhole. Replace identifiers with actual records from the same project:

{
  "request_id": "ornek-duzenleme-004",
  "ops": [
    {
      "op": "create",
      "entity": "relation",
      "type": "icinde",
      "child": "EK-123",
      "parent": "MH-456"
    }
  ]
}

The child must be a point record and the parent a suitable shared site structure. If the child already has a placement parent, remove the existing relationship first. Placement cycles are not allowed. Creating a relationship does not move the feature geometrically.

For type: "guzergah", child identifies the cable or duct and parent the trench/aerial-route segment. A duct can only pass through a trench. If seq is omitted, the relationship is appended to the route. Use via to route a cable through a duct and via_no to identify the subduct; the duct must have a recorded route in the same segment. type: "giris" is a separate relationship linking an address entry to a building.

Applying the response

A successful response contains ok, batch, ids, tmp and features. Depending on the operation, it may also include equipment, connections, fiber_items, circuits, optik_items and uyarilar. ids lists operation results; tmp maps temporary identifiers. A warning in a successful response does not mean the record was rejected.

Do not guess versions changed as a side effect; use response data or a fresh read. See Feature types for general feature and equipment rules.