Update Subsidiary — Proposed Guide

Planned API — Reference Only

Update Subsidiary: A subsidiary update would change permitted descriptive attributes without reassigning historical transactions. Currency changes require…

Overview

A subsidiary update would change permitted descriptive attributes without reassigning historical transactions. Currency changes require more scrutiny than a display-name edit.

Key concepts

Use version checks and keep an effective-dated record of material entity changes. Validate parent references.

Implementation considerations

Do not reinterpret older monetary amounts under a new currency. Future contracts should restrict changes that would corrupt accounting meaning.

Proposed API behavior

PATCH /v1/subsidiaries/{subsidiary_id} is an illustrative design for this topic. Path and field names may change before implementation. Access would require an authorized organization context and operation-specific permission; no public API or authorization grant is available here.

Proposed path parameters
Name	Type	Description
subsidiary_idrequired	string	Stable fictional subsidiary reference; not a secret and not evidence that a resource exists.

Illustrative request fields
Name	Type	Description
name	string	Human-readable example label; stable relationships should use identifiers instead.
parent_id	string	Stable fictional parent reference; not a secret and not evidence that a resource exists.
status	string	Proposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success.
version	integer	Illustrative resource revision for detecting stale updates; no live concurrency contract is published.

Static example requests

Proposed, non-executing request examples

# Proposed request text only; this reserved host is not a live API.
curl -X PATCH 'https://api.remizen.example/v1/subsidiaries/sub_example_123' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
  "name": "Example business unit",
  "parent_id": "parent_example_123",
  "status": "draft",
  "version": 1
}'

Fictional response example

200 (proposed example)Static response fixture

Fictional documentation data only. No request was sent, record created, review performed, payment initiated or provider connection activated.

JSON

{
  "data": {
    "name": "Example business unit",
    "parent_id": "parent_example_123",
    "version": 1,
    "id": "subsidiaries_example_123",
    "organization_id": "org_example_123"
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: Do not reinterpret older monetary amounts under a new currency. Future contracts should restrict changes that would corrupt accounting meaning.

422 (illustrative; final error contracts are undecided)Proposed error fixture

Synthetic diagnostic example. Human-readable messages must not be used as stable programmatic contracts.

JSON

{
  "error": {
    "code": "validation_error",
    "message": "The proposed update subsidiary operation requires review of its input or authorization.",
    "request_id": "req_example_123"
  }
}

Proposed data types

Illustrative field dictionary
Name	Type	Description
subsidiary_id	string	Stable fictional subsidiary reference; not a secret and not evidence that a resource exists.
name	string	Human-readable example label; stable relationships should use identifiers instead.
parent_id	string	Stable fictional parent reference; not a secret and not evidence that a resource exists.
status	string	Proposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success.
version	integer	Illustrative resource revision for detecting stale updates; no live concurrency contract is published.

Create Subsidiary

Users & Organizations

Teams