[{"data":1,"prerenderedAt":312},["ShallowReactive",2],{"arch-integrations":3,"arch-integrations-details":60},{"id":4,"title":5,"body":6,"category":49,"deepPage":50,"description":51,"extension":52,"layer":53,"meta":54,"navigation":55,"path":50,"relatedFlows":56,"replaces":56,"seo":57,"stem":58,"__hash__":59},"architecture/architecture/integrations.md","Integrations",{"type":7,"value":8,"toc":44},"minimark",[9,13,33,38,41],[10,11,12],"p",{},"The operating layer does not replace every system in the building. It wraps the systems the building already runs — access hardware, property management, payments, accounting — and orchestrates them through a single behavioral specification. Each integration absorbs the vendor's data model into the operating layer, normalizes it against the standard, and surfaces a consistent experience to residents and staff.",[10,14,15,16,20,21,24,25,28,29,32],{},"Integrations are categorized by the role they play in the building. ",[17,18,19],"strong",{},"Access control"," connects to the orchestration engine and inherits the permissions model. ",[17,22,23],{},"Property management"," wraps lease, ledger, and unit-state data. ",[17,26,27],{},"Payments"," routes resident charges through the payment wrapper. ",[17,30,31],{},"Accounting"," synchronizes financial events into the building's books. The behavioral specification is the same regardless of which vendor sits behind it; the integration is the seam that makes vendor swaps possible without renegotiating the standard.",[34,35,37],"h2",{"id":36},"integration-approach","Integration approach",[10,39,40],{},"Each integration declares its capabilities, its data model, and its failure modes against the operating layer's contract. Where a vendor exposes a stable API, the operating layer consumes it directly. Where the vendor exposes only a portal, the integration is built against the documented data export and a scoped service account. Critical paths — access decisions, payment authorization — execute through the edge gateway when connectivity to the vendor cloud is intermittent.",[10,42,43],{},"No integration is exclusive. The orchestration engine is designed so the building can swap one access vendor for another, or one PMS for another, without rewriting the behavioral specification or breaking the resident experience. The vendor directory below lists the integrations currently shipped or available on request.",{"title":45,"searchDepth":46,"depth":46,"links":47},"",2,[48],{"id":36,"depth":46,"text":37},"integration","/architecture/integrations","How external systems connect to the operating layer — the vendor directory and the integration approach.","md","4",{},true,null,{"title":5,"description":51},"architecture/integrations","lDsPbdf0wjKA7T4DK8iCyTlmkgarD-gQWTc2dgsoqHk",[61,87,109,157,179,201,246,268,290],{"id":4,"title":5,"body":62,"category":49,"deepPage":50,"description":51,"extension":52,"layer":53,"meta":85,"navigation":55,"path":50,"relatedFlows":56,"replaces":56,"seo":86,"stem":58,"__hash__":59},{"type":7,"value":63,"toc":82},[64,66,76,78,80],[10,65,12],{},[10,67,15,68,20,70,24,72,28,74,32],{},[17,69,19],{},[17,71,23],{},[17,73,27],{},[17,75,31],{},[34,77,37],{"id":36},[10,79,40],{},[10,81,43],{},{"title":45,"searchDepth":46,"depth":46,"links":83},[84],{"id":36,"depth":46,"text":37},{},{"title":5,"description":51},{"id":88,"title":89,"body":90,"category":49,"deepPage":103,"description":104,"extension":52,"layer":53,"meta":105,"navigation":55,"path":103,"relatedFlows":56,"replaces":56,"seo":106,"stem":107,"__hash__":108},"architecture/architecture/integrations/adyen.md","Adyen integration",{"type":7,"value":91,"toc":101},[92,95,98],[10,93,94],{},"Adyen is the primary payment processor used by Apareé clients in EMEA and APAC, and a common choice for operators running cross-border portfolios. The integration sits behind the payment wrapper, exposing the same operations Stripe exposes, with Adyen's settlement, local payment methods, and regulatory posture underneath.",[10,96,97],{},"The integration consumes Adyen's unified commerce model so the same operating-layer behavior — charging an amenity fee, holding a deposit, issuing a refund — works across every market the building operates in. Local payment methods (SEPA, iDEAL, Bancontact, regional card schemes) are supported without per-method consumer code; the wrapper normalizes them into the same charge / hold / release / refund / reconcile contract.",[10,99,100],{},"The integration also handles the regulatory side. SCA challenges, 3DS flows, and country-specific reporting are managed at the wrapper, not exposed to the consumers. The behavioral standard scores the financial side of the resident experience — refunds within the window, holds released on schedule, statements arriving when they should — and the integration is what makes those guarantees enforceable across processors.",{"title":45,"searchDepth":46,"depth":46,"links":102},[],"/architecture/integrations/adyen","Adyen unified payments wrapped through the payment & invoice wrapper.",{},{"title":89,"description":104},"architecture/integrations/adyen","GbQS9CWTkIL-MuR3HNlTrmWFRS0II-QD-gEP_fKTZK4",{"id":110,"title":111,"body":112,"category":49,"deepPage":149,"description":150,"extension":52,"layer":53,"meta":151,"navigation":55,"path":149,"relatedFlows":152,"replaces":56,"seo":154,"stem":155,"__hash__":156},"architecture/architecture/integrations/dormakaba.md","Dormakaba integration",{"type":7,"value":113,"toc":147},[114,117,123,129,135,141],[10,115,116],{},"Dormakaba is the second primary access-control family wrapped by the operating layer. The integration covers three Dormakaba product lines, suited to different building scales and operational models.",[10,118,119,122],{},[17,120,121],{},"Dormakaba Lyazon."," A cloud-based access management platform aimed at commercial and mixed-use buildings. The integration uses the Lyazon cloud API for credential management, door control, and event ingestion. Lyazon is well-suited to buildings with more complex zone hierarchies and shift-based staff access patterns.",[10,124,125,128],{},[17,126,127],{},"Dormakaba exivo."," A cloud-managed access control system for small-to-mid buildings. The integration uses the exivo REST API. exivo is the default choice when a building's access needs are straightforward and the management overhead of a more configurable platform is not warranted.",[10,130,131,134],{},[17,132,133],{},"Dormakaba Ambiance."," A platform aimed at residential and hospitality contexts with a focus on mobile credentials and guest workflows. The integration uses the Ambiance API for credential issuance and door commands, with event subscription for real-time orchestration.",[10,136,137,140],{},[17,138,139],{},"What gets wrapped."," Door commands, credential lifecycle, event subscription, and device health. Per the same pattern as the SALTO integration, configuration of physical zones, door groups, and schedules stays in the Dormakaba console where vendor support and audit trail live; the operating layer reads from there.",[10,142,143,146],{},[17,144,145],{},"What is unified."," Same contract as every other integration. The resident does not see Dormakaba. Staff do not need to learn the Dormakaba console for routine operations. The orchestration engine presents a single decision interface, and Dormakaba is one of the hardware families that fulfils it.",{"title":45,"searchDepth":46,"depth":46,"links":148},[],"/architecture/integrations/dormakaba","Dormakaba Lyazon, exivo, and Ambiance wrapped through the access orchestration engine.",{},[153],"access",{"title":111,"description":150},"architecture/integrations/dormakaba","mek8V076p-D0FJCuESBk0GNYgnEFqbJaO9XYIer3KQ8",{"id":158,"title":159,"body":160,"category":49,"deepPage":173,"description":174,"extension":52,"layer":53,"meta":175,"navigation":55,"path":173,"relatedFlows":56,"replaces":56,"seo":176,"stem":177,"__hash__":178},"architecture/architecture/integrations/quickbooks.md","QuickBooks integration",{"type":7,"value":161,"toc":171},[162,165,168],[10,163,164],{},"QuickBooks Online is the accounting system most commonly used by smaller and mid-tier residential operators in North America. The integration consumes the financial events emitted by the payment wrapper and lands them in QuickBooks with the metadata the building's accountant needs to reconcile without rework — building, unit, resident, category, period, behavioral context.",[10,166,167],{},"The integration is one-directional from the operating layer into QuickBooks. Charges, refunds, deposits, and adjustments flow in as journal entries against the right accounts on the right cadence. Where QuickBooks exposes class and location dimensions, the integration uses them so portfolio-level reporting works without manual tagging. Where the building's chart of accounts is non-standard, the integration is configured at deployment to map operating-layer categories onto the right account codes.",[10,169,170],{},"The point of the integration is not to replace the building's accountant. It is to remove the manual reconciliation step that traditionally bridges operations and accounting — so the books reflect the operational reality the standard scored, with no discretionary mapping in between.",{"title":45,"searchDepth":46,"depth":46,"links":172},[],"/architecture/integrations/quickbooks","QuickBooks Online wrapped through the accounting integration so financial events from the operating layer land in the building's books.",{},{"title":159,"description":174},"architecture/integrations/quickbooks","MlVSZ1THx3mjZ5upDkOOSe8W9kqYAHmeRqU2yrQaK-w",{"id":180,"title":181,"body":182,"category":49,"deepPage":195,"description":196,"extension":52,"layer":53,"meta":197,"navigation":55,"path":195,"relatedFlows":56,"replaces":56,"seo":198,"stem":199,"__hash__":200},"architecture/architecture/integrations/realpage.md","RealPage integration",{"type":7,"value":183,"toc":193},[184,187,190],[10,185,186],{},"RealPage is the second of the two dominant property management systems in the residential operator market. The integration covers the OneSite product line for traditional multifamily and the Investment Management Services platform for institutional asset operators, behind the same operating-layer contract used for Yardi.",[10,188,189],{},"The integration consumes RealPage as the system of record for lease, ledger, and unit-state data. The orchestration is one-directional from RealPage on lease and tenancy facts, and bi-directional on operational events that need to land in RealPage's ledger — amenity charges, late fees, deposit holds, refunds. The wrapper normalizes the shape of these events so the building's books reflect the resident's actual experience, not a vendor-specific schema.",[10,191,192],{},"Failure modes are explicit. If RealPage is unreachable, the operating layer continues to serve resident workflows from cache and queues outbound events for reconciliation when the link returns. The behavioral standard scores the resident-facing experience, not the integration's uptime — a Yardi-backed building and a RealPage-backed building produce the same resident behavior or they do not meet the standard.",{"title":45,"searchDepth":46,"depth":46,"links":194},[],"/architecture/integrations/realpage","RealPage OneSite and IMS wrapped through the property management integration layer.",{},{"title":181,"description":196},"architecture/integrations/realpage","BKGAjC_ZoRD0sfElKMBhbGBux8cr4UbJo9g3r6crPJk",{"id":202,"title":203,"body":204,"category":49,"deepPage":239,"description":240,"extension":52,"layer":53,"meta":241,"navigation":55,"path":239,"relatedFlows":242,"replaces":56,"seo":243,"stem":244,"__hash__":245},"architecture/architecture/integrations/salto.md","SALTO integration",{"type":7,"value":205,"toc":237},[206,209,215,221,227,232],[10,207,208],{},"SALTO is one of two primary access-control families wrapped by the operating layer. The integration covers three SALTO product lines, each suited to a different building profile.",[10,210,211,214],{},[17,212,213],{},"SALTO KS."," Cloud-based access control for buildings that need centralised credential management and remote operation. The integration uses the KS REST API for credential issuance and revocation, real-time door commands, and event subscription. KS is the default choice for portfolio operators who want a single management surface across multiple buildings.",[10,216,217,220],{},[17,218,219],{},"SALTO Nebula."," A unified cloud platform for SALTO's broader hardware range. The integration uses the Nebula REST API and event stream. Nebula carries the more recent SALTO product roadmap and is the recommended path for new commissioning unless an existing building is already on KS.",[10,222,223,226],{},[17,224,225],{},"SALTO Homelok."," Designed for residential applications with a stronger resident-facing posture — mobile credentials, guest passes, delivery codes. Where Homelok is deployed, the operating layer wraps it the same way: residents see the Apareé surface, Homelok handles the door.",[10,228,229,231],{},[17,230,139],{}," Door control commands, credential lifecycle (issue, modify, revoke, replace), real-time event ingestion (access granted, denied, door held, forced), and device health telemetry. Configuration of doors, schedules, and access groups remains in the SALTO console where SALTO owns the truth — the operating layer reads from those configurations rather than mirroring them.",[10,233,234,236],{},[17,235,145],{}," From the resident's perspective, there is no SALTO. There is the building. The same is true for staff using the operations console and for the workflows that issue access decisions. SALTO is an implementation detail, swappable without disturbing the experience.",{"title":45,"searchDepth":46,"depth":46,"links":238},[],"/architecture/integrations/salto","SALTO KS, Nebula, and Homelok wrapped through the access orchestration engine.",{},[153],{"title":203,"description":240},"architecture/integrations/salto","JUKvkeN8Xuw8TCuXb65L7f9whymhck7-iMJlzyb2ZHY",{"id":247,"title":248,"body":249,"category":49,"deepPage":262,"description":263,"extension":52,"layer":53,"meta":264,"navigation":55,"path":262,"relatedFlows":56,"replaces":56,"seo":265,"stem":266,"__hash__":267},"architecture/architecture/integrations/stripe.md","Stripe integration",{"type":7,"value":250,"toc":260},[251,254,257],[10,252,253],{},"Stripe is the primary payment processor used by Apareé clients in North America and several non-EEA markets. The integration sits behind the payment wrapper, exposing the same charge / hold / release / refund / reconcile contract that the booking engine, the issue engine, and the move-in / move-out flow consume.",[10,255,256],{},"The integration uses Stripe's idempotency primitives and webhook delivery model to guarantee that financial events land exactly once in the building's ledger, even under retries and processor outages. Holds for amenity deposits and security deposits are issued through Stripe's authorization model and released on the schedule defined by the behavioral standard. Refunds are a first-class workflow, not a manual back-office task — the standard requires refunds to happen within a defined window, and the wrapper enforces that contract regardless of which processor sits behind it.",[10,258,259],{},"When a building swaps Stripe for Adyen, or vice versa, the consumers — booking engine, issue engine, onboarding — are unaffected. The wrapper is the only thing that changes.",{"title":45,"searchDepth":46,"depth":46,"links":261},[],"/architecture/integrations/stripe","Stripe Payments and Connect wrapped through the payment & invoice wrapper.",{},{"title":248,"description":263},"architecture/integrations/stripe","nuD8OE0yN0H2R2XZ9aWlZu4zjYw7mdfruP7l6LKjxDE",{"id":269,"title":270,"body":271,"category":49,"deepPage":284,"description":285,"extension":52,"layer":53,"meta":286,"navigation":55,"path":284,"relatedFlows":56,"replaces":56,"seo":287,"stem":288,"__hash__":289},"architecture/architecture/integrations/xero.md","Xero integration",{"type":7,"value":272,"toc":282},[273,276,279],[10,274,275],{},"Xero is the accounting system most commonly used by Apareé clients in EMEA, APAC, and emerging markets. The integration is the EMEA-and-APAC counterpart to QuickBooks: it consumes the financial events emitted by the payment wrapper and lands them in Xero with consistent metadata for unit, resident, category, period, and behavioral context.",[10,277,278],{},"The integration is one-directional from the operating layer into Xero. Charges, refunds, deposits, and adjustments flow in as bills, invoices, and journal entries against the right accounts on the right cadence. Tracking categories are used for portfolio-level reporting where the operator runs multiple buildings on the same Xero tenant. Multi-currency handling follows Xero's settlement model so cross-border operators can report in a single base currency without manual conversion.",[10,280,281],{},"The integration's role is the same as QuickBooks's role: remove the manual reconciliation step between operations and accounting, so the books reflect the resident experience the standard scored without discretionary mapping in between.",{"title":45,"searchDepth":46,"depth":46,"links":283},[],"/architecture/integrations/xero","Xero wrapped through the accounting integration so financial events from the operating layer land in the building's books.",{},{"title":270,"description":285},"architecture/integrations/xero","oWlbO7mS6lM6dJtqqlgQeAZRtSjoq4XUOjgdUsR6IAc",{"id":291,"title":292,"body":293,"category":49,"deepPage":306,"description":307,"extension":52,"layer":53,"meta":308,"navigation":55,"path":306,"relatedFlows":56,"replaces":56,"seo":309,"stem":310,"__hash__":311},"architecture/architecture/integrations/yardi.md","Yardi integration",{"type":7,"value":294,"toc":304},[295,298,301],[10,296,297],{},"Yardi is one of the two dominant property management systems in the residential operator market. The integration covers the two product lines most commonly deployed by Apareé clients — Voyager for institutional and mid-tier portfolios, and Breeze for smaller operators — and absorbs both behind the same operating-layer contract.",[10,299,300],{},"The integration consumes Yardi as the system of record for lease, ledger, and unit-state data. Lease activations and terminations flow into the onboarding and move-out engines on a defined cadence. Charges originating in the operating layer flow back into Yardi's ledger through the accounting integration with consistent metadata. The resident-facing experience does not depend on Yardi being reachable in real time; the operating layer caches the data the resident-facing flows need and reconciles asynchronously.",[10,302,303],{},"Where Yardi exposes a stable API, the integration consumes it directly. Where Yardi exposes only a portal, the integration is built against documented exports and a scoped service account. Either way, the building's resident experience is governed by the behavioral specification, not by the seam between the operating layer and the PMS.",{"title":45,"searchDepth":46,"depth":46,"links":305},[],"/architecture/integrations/yardi","Yardi Voyager and Breeze wrapped through the property management integration layer.",{},{"title":292,"description":307},"architecture/integrations/yardi","fh5oUiIo8aETSy_wNjQUwTcInnHGwmzYPPoFw9ULIvk",1779718756836]