System Obsługi Najmu
ERPConnect AI agents to System Obslugi Najmu, a Polish rental property management platform. Agents create reservations, mark them paid as an irreversible income operation, and look up a tenant's bank account details.
What This Integration Enables
System Obsługi Najmu, usually shortened to SON, is a Polish rental property management platform, and this connector is three actions wide on purpose. It does not try to be the letting agent's whole system. It handles the one sequence that is genuinely painful to do by hand across a portfolio: register a tenancy, get the tenant a way to pay for it, and record the money when it arrives. Create Reservation, Get Bank Account and Mark Reservation Paid, and each of the three exists because of the one after it.
The design choice worth understanding is the dedicated bank account. Create Reservation registers a reservation for a tenant, requiring first name, last name, email, amount, check in and check out dates, and optionally accepting the estate or room, a deposit, a currency, an address, a paid flag, a reservation code and a discount coupon. What it returns is the bank account number generated specifically for that reservation's payment. That is what makes reconciliation tractable. In a portfolio of tenancies the hardest part of collecting rent is not asking for it, it is working out which of forty transfers on a Monday belongs to which tenancy when the payment comes from a parent, a company or a name that appears nowhere in the tenancy agreement. A dedicated account number per reservation replaces name matching with identity. Get Bank Account then returns the account details, the user ID, the IBAN, the account number and the currency, assigned to a tenant or reservation for payment, looked up by tenant user ID. Mark Reservation Paid closes the loop by marking a reservation as paid and creating a matching income financial operation for the tenant, identified by estate ID and the reservation code used at creation, optionally recording a card payment and an amount.
Two behaviours belong on the page rather than in a support ticket. The reservation code is optional on Create Reservation and mandatory on Mark Reservation Paid, which means a reservation created without one cannot be marked paid through this connector at all. A flow generates and stores it at creation time, always, not when it is first needed. And Mark Reservation Paid responds with OK or ERROR and nothing else. There is no detail in a failure and no echo of what was written on a success, so a flow verifies rather than assumes, and treats an ERROR as a stop that a person sees rather than something to retry into.
Be precise about the shape of this surface, because a three action connector invites assumptions in both directions. There is no read of reservations here: Get Bank Account looks up payment details by tenant user ID and is the only read in the connector. There is no update or cancel of an existing reservation, and no way to reverse a payment once Mark Reservation Paid has created the income operation. And there are no triggers. SON exposes no webhook subscription through this connector, so nothing here creates a FlowRunner trigger, and the flow is started by something else: a tenancy agreed in the agent's own system, a schedule, or a bank statement arriving. That is not a limitation to work around so much as a description of where this connector sits, at the two ends of a payment rather than in the middle of a property management system.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A tenancy that arrives with its own account number
A letting is agreed in the agency's own intake system or a signed agreement comes back through DocuSign. The agent generates and stores the reservation code first, because Mark Reservation Paid will need it and there is no later opportunity to add it. It calls Create Reservation with the tenant's name and email, the amount, the check in and check out dates, the estate or room, the deposit and the currency, and takes back the dedicated bank account number generated for that reservation. That number, the amount and the dates go to the tenant through Gmail in the same run, and the reservation code and account number are written to the agency's own record in Google Sheets so the reconciliation later has something to match on.
Reconciliation that matches on the account, not the name
Bank statement lines arrive daily. The agent reads them, and for each credit it matches on the dedicated account number the reservation was issued with rather than on the payer's name, which is why a transfer from a parent, an employer or a shared household account resolves correctly instead of plausibly. Get Bank Account confirms the account details assigned to the tenant before anything is proposed, so a match is verified against SON rather than against a spreadsheet that may have drifted. Clean matches on the exact amount are put forward as a batch. Partial payments, overpayments and credits against an account number that does not resolve are separated and named, because those are precisely the ones that go wrong quietly.
A collections view built without touching the ledger
Not every run should write anything. On a schedule the agent reads the agency's own reservation register, calls Get Bank Account for each active tenancy, and joins the bank feed against the dedicated account numbers to produce a view of who has paid, who has paid part, and who has not paid at all, with the check in date next to each. The summary goes to the property manager in Slack and the arrears list feeds a reminder sequence. This run creates no income operations and marks nothing paid, which is exactly what makes it safe to run every morning: the money side of the platform is only ever written after a person has looked at a specific match.
Human-in-Loop Highlight
Mark Reservation Paid is the gate, and it is the gate for a reason that is easy to underestimate on a three action connector. The description is exact: it marks a reservation as paid and creates a matching income financial operation for the tenant. That is not a status flag. It is an entry in the tenant's financial record that says money arrived, and the platform responds with OK or ERROR and nothing else, so there is no confirmation of what was written and no detail when it fails. This connector exposes no way to reverse it. Everything upstream is recoverable and cheap. Create Reservation can be repeated, Get Bank Account writes nothing. The moment the income operation exists, a tenant who did not pay is recorded as having paid, or a payment from one tenancy is credited to another, and the person who finds out is a tenant reading a statement they know is wrong or an owner receiving a distribution that does not reconcile. The matching itself is where the ambiguity lives: the dedicated account number makes most transfers unambiguous, and the ones that are not, a partial payment, a round sum covering two months, a transfer to an account number that resolves to a tenancy that ended, are exactly the ones an agent should not settle on its own. So the agent reconciles and stops. It posts to the property manager: "34 credits on Monday's statement. 29 match a dedicated reservation account on the exact amount and I have listed them with the tenant, the estate and the reservation code. 5 do not. Two are partial: 1,200 zloty received against 2,400 due for reservation R-4471, Kamila Rutkowska, and 800 against 1,500 for R-4506. One is 4,800 zloty to the account for R-4390 where the amount due is 2,400, so it looks like two months paid at once. One resolves to a reservation whose check out was in March. And one has no reservation code recorded at creation, so I cannot mark it paid at all and it needs fixing in SON. Marking a reservation paid creates the income operation against the tenant and I have no way to undo it from here. Confirm the 29, and tell me how to treat the five?" The manager answers once, and the agent runs Mark Reservation Paid only on what was confirmed. This is the human-in-the-loop moment on a connector small enough to read in a minute, and it sits exactly where it should: on the single action that writes money into somebody's record.
Agent Capabilities
3 actionsReservations
2- Create Reservation Creates a reservation for a tenant and returns the dedicated bank account number generated for that reservation's payment. Requires first name, last name, email, amount, check in and check out dates. Optionally accepts the estate or room, a deposit, a currency, an address, a paid flag, a reservation code and a discount coupon. The reservation code is optional here and required by Mark Reservation Paid, so a flow generates and records one every time rather than only when it expects to need it.
- Mark Reservation Paid Marks a reservation as paid and creates a matching income financial operation for the tenant, identified by estate ID and the reservation code used at creation, optionally recording a card payment and an amount. It responds with `OK` or `ERROR` and nothing more, so a flow verifies rather than assumes and treats a failure as a stop rather than a retry. This connector exposes no way to reverse the income operation, which is why it runs behind a person.
Banking
1- Get Bank Account Returns the bank account details assigned to a tenant or reservation for payment, including the user ID, the IBAN, the account number and the currency, looked up by tenant user ID. This is the only read in the connector, and it is what lets a reconciliation match a bank credit to a tenancy on the account number rather than on the payer's name.
Frequently Asked Questions
What can FlowRunner do with System Obsługi Najmu?
FlowRunner agents can run Create Reservation, Get Bank Account, and Mark Reservation Paid in System Obsługi Najmu.
Does connecting System Obsługi Najmu to FlowRunner require OAuth?
System Obsługi Najmu uses a custom authentication method to connect to FlowRunner.
Can System Obsługi Najmu trigger a FlowRunner workflow automatically?
System Obsługi Najmu doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with System Obsługi Najmu
$100 in credits. No card required. Connect in minutes.