Create Subsidiary — Proposed Guide

Planned API — Reference Only

Create Subsidiary: Creating a subsidiary would define an entity available for later attribution. It should not open bank accounts, configure payroll or…

Overview

Creating a subsidiary would define an entity available for later attribution. It should not open bank accounts, configure payroll or provision an accounting connector.

Key concepts

Validate the parent organization, entity name and reporting currency. Store a source-system external id separately from the Remizen id.

Implementation considerations

Creation does not establish legal registration or regulatory status. Those facts require independently verified business records.

Proposed API behavior

POST /v1/subsidiaries 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.

Illustrative request fields
Name	Type	Description
organization_id	string	Stable fictional organization reference; not a secret and not evidence that a resource exists.
name	string	Human-readable example label; stable relationships should use identifiers instead.
country	string	Illustrative country code; it does not establish regional product availability.
currency	string	Uppercase ISO 4217 currency code. Determine its minor-unit exponent before monetary conversion.
external_id	string	Fictional source/provider correlation value, not a credential or proof of synchronization.

Static example requests

Proposed, non-executing request examples

# Proposed request text only; this reserved host is not a live API.
curl -X POST 'https://api.remizen.example/v1/subsidiaries' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
  "organization_id": "org_example_123",
  "name": "Example business unit",
  "country": "US",
  "currency": "USD",
  "external_id": "external_example_123"
}'

Fictional response example

201 (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": {
    "organization_id": "org_example_123",
    "name": "Example business unit",
    "country": "US",
    "currency": "USD",
    "external_id": "external_example_123",
    "id": "subsidiaries_example_123"
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: Creation does not establish legal registration or regulatory status. Those facts require independently verified business records.

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 create subsidiary operation requires review of its input or authorization.",
    "request_id": "req_example_123"
  }
}

Proposed data types

Illustrative field dictionary
Name	Type	Description
organization_id	string	Stable fictional organization reference; not a secret and not evidence that a resource exists.
name	string	Human-readable example label; stable relationships should use identifiers instead.
country	string	Illustrative country code; it does not establish regional product availability.
currency	string	Uppercase ISO 4217 currency code. Determine its minor-unit exponent before monetary conversion.
external_id	string	Fictional source/provider correlation value, not a credential or proof of synchronization.

Subsidiaries

Users & Organizations

Update Subsidiary