Deal data lives in your CRM. Lease structure lives in LeasePilot. Status updates need to land in your asset-management system, your deal pipeline, sometimes a custom internal tool your firm has built around how it operates. Most platforms solve the cross-system syncing problem by reaching — shared service accounts, polling APIs, picking through each other's data.
LeasePilot doesn't reach. Both directions of the connection are push-based, configured during onboarding, and triggered by the system that already has the data.
01Inbound: your system pushes deal data into LeasePilot
When deal data already exists in your property-management or CRM (tenant names, building IDs, square footage, dates, deal stages, whatever your stack tracks), your system sends a payload to LeasePilot at a moment you choose: on deal close, on every save, nightly, on demand. LeasePilot maps the values onto the structured fields in your deal-terms panel, and the matching deal is available to draft against, populated.
The same pattern works whether the source is Yardi, MRI, Salesforce, Dynamics 365, an internal tool, or a custom system your team has built.
02Outbound: LeasePilot pushes lease data back out on status change
In the other direction, LeasePilot watches the status of every document. When a document moves into a status you've configured as a trigger (typical examples: Out for signature, Executed, Conformed, Approved by counsel — the statuses themselves are yours to define), LeasePilot abstracts the document into structured data and ships that payload to an endpoint your team controls.
The result: when a lease is executed, the abstract lands in your asset-management system. When a draft hits Approved, the deal pipeline updates. When a renewal is conformed, the data of record matches the signed copy automatically. No re-keying, no manual export-then-import, no overnight reconciliation job.
03Why push, not pull
Same reasoning in both directions:
- No credentials shared with us. A pull-based integration means handing over a service account and trusting another platform not to overstep. A push doesn't require that. Each system you operate emits what you've already chosen to emit.
- You decide what gets sent. Sensitive fields stay where they are. Each push ships only the data the receiving side actually needs.
- You decide when it gets sent. Inbound on your schedule, outbound on statuses you've defined. LeasePilot doesn't poll.
- Failures stay debuggable in the system you operate. If a payload doesn't land where it should, the question what happened on the way out lives in your logs, on a system your team understands.
04Setup
Both directions are configured once, during onboarding, by your team and ours working together. Inbound and outbound are set up separately: which fields flow in, which statuses trigger an outbound push, which endpoint receives the abstract, what shape the payload takes. The implementation team fits each side to whatever interface (webhook, file drop, scheduled job, API call) your stack already speaks.
NoteBoth directions are explicit by design. Inbound pushes only fire when your system sends them. Outbound pushes only fire on statuses you've defined as triggers. LeasePilot doesn't poll, doesn't reach, and doesn't push anything you haven't configured.
For pulling deal terms out of an LOI or term sheet (a one-off, document-based path that doesn't need a connected system), see import deal terms. For the deal-terms panel that the inbound flow ultimately populates, see deal terms. For the API token used by custom integrations, see API token.