Skip to main content
This is a planning example, not a runnable property-management API integration. The current API accepts only credit_union.v1 and requires credit-union loan fields. There is no property-management profile, property/unit resource or invoice resource in this contract. Do not represent service charges or rent as loans to make a request pass validation.

​
Example: service-charge arrears

An owners’ management company authorizes collection of EUR 1,250 in service-charge arrears from a liable owner. The managing agent supplies records from its property-management system. EUR 250 is subsequently received in that source system, leaving EUR 1,000 authorized for collection. These are proposed domain mappings to agree during integration design, not additional request fields: Keep creditor identity, liability, contact details and collection authority separate. A property address does not by itself establish a liable Customer or permission to contact someone.

​
Before runnable examples

Agree the property-management profile and implement its validation, grants, runtime handling and OpenAPI together. Decisions include:
  • Supported debt types: service charges, rent or other charges, and required source facts for each.
  • Stable opaque IDs for parties and placements, plus property/unit and invoice references and their privacy treatment.
  • Charge aggregation, due dates, credits, adjustments and payment allocation; the existing API supports only full refunds and reversals of a Payment observation.
  • The information partners need back: current collection progress, communications or reporting would need capabilities beyond the existing source-representation reads.
Once those decisions are implemented, publish runnable examples that validate against that profile. The credit-union walkthrough shows today’s implemented flow and its reconciliation rules.