The unit has to wait for the buyer
If another customer buys it during the conversation, the beautiful interface has failed. The hold must exist in the developer's system.
REAL.BZ is now assembling developer, bank and registry interfaces into one transaction route.
We are building the new-build deal you can finish in one evening.
Not a chatbot with apartment cards. Live inventory, a real hold, checks, documents, escrow and electronic registration — without dropping the buyer between services.
The buyer chooses the unit and signs the agreement. The system prepares the rest, exposes the state of every step and stops wherever a person must make the decision.
- Live unitprice and status from source1
- Choice3–5 options with reasons2
- Holdterms and expiry returned3
- Checksbank, identity, eligibility4
- Agreementdata entered once5
- Signaturethe buyer acts6
- Registrationelectronic submission7
A video takes a minute.
It cannot carry the transaction.
The easy version of this agent recommends an apartment, shows the floor plan and generates a film. The buyer says “I’ll take it.” That is where the actual system starts.
The price has to be today's price
Developers use different formats, promotions and update schedules. Inventory without a last-sync time becomes an error source quickly.
Legal documents cannot be generated by tone of voice
An agent may collect data and prepare the agreement. The buyer still makes the legally significant decision and signs it.
That is why video is phase two. First comes the transaction spine: data, hold, checks, agreement, signature and registration.
How one purchase moves
The route does not start with a floor filter. It starts with the person's job and ends only when every party knows the next transaction state.
- 01
Understand the job
Budget, household, timing, city, mortgage, investment or living goal, and the constraints the buyer will not trade away.
A structured request
- 02
Reduce the choice
Not a hundred cards: 3–5 live options. Each explains why it fits, what it gives up and what the actual window direction can show.
A reasoned shortlist
- 03
Lock the unit
The developer API returns price, hold expiry, payment amount and refund terms. A source may return 24, 48 or 72 hours; the MVP tests a 48-hour window and the project remains the source of truth.
A timed hold with terms
- 04
Confirm ability to buy
Mortgage pre-approval, identity and compliance checks, subsidies, trade-in and other eligibility rules run before the agreement is prepared.
No surprise after the hold
- 05
Prepare the documents
Buyer data populates the project agreement, is checked by the parties and moves into the agreed developer and bank workflow.
A signature-ready package
- 06
Sign
The system presents the final terms and hands the document to the approved electronic-signature service. The buyer signs it.
One explicit human action
- 07
Submit and expose status
After signature, the package advances and returns a real state: accepted, awaiting data, suspended or registered.
The deal never vanishes into chat
A thousand developments do not produce a thousand identical APIs.
Every developer names fields, states, promotions and update schedules differently. REAL.BZ maps them into one schema while preserving the source and time of every change.
Freshness is part of the product
Every source has an acceptable delay. An expired unit is not presented as current: the system rechecks it or removes it from the shortlist until the source responds.
One unit record must carry
- 01development, building and unit ID
- 02plan, area and floor
- 03window direction and a verified view
- 04price, promotion and payment terms
- 05state: available, held, booked or sold
- 06hold expiry and payment refund terms
- 07last-sync time and source
Normalisation does not rewrite the developer's truth. It makes that truth comparable and shows how much it can be trusted right now.
What has to happen before the hold
A useful recommendation answers more than “do you like this apartment?” It checks whether the buyer can complete it and whether a better alternative exists.
01
Money and purchase method
Mortgage pre-approval, deposit, eligible subsidies and trade-in are checked before anyone promises a timeline.
02
Identity and compliance
KYC and bank compliance become visible states, not a surprise rejection on the last screen.
03
The view that will actually exist
A panorama is tied to the building, floor and window direction. If verified data does not exist, the system says so instead of inventing an ocean.
04
Project and price in context
The buyer sees available legal project information and a comparison with alternatives, not only the claims of whoever pays the commission.
05
A visible fee
Who pays REAL.BZ and how must be clear before the choice: developer commission, a fixed buyer fee or another agreed model.
The agent prepares the transaction.
The person signs it.
That boundary is not decorative. The agent does not impersonate the buyer's intent and does not press a legally significant button for them.
The rails already exist
- escrow structures for new-build purchases
- remote electronic signing of documents
- electronic submission to property registries
- bank checks and mortgage workflows
REAL.BZ is assembling above them
- one data package without repeated entry
- agreement preparation from the project's approved template
- handoff to signature with final human confirmation
- a state, error and retry ledger
The target is two deliberate buyer actions: choose and sign. “One evening” describes the route to a ready, signed package, not a promise that an external registry will finish that evening. If the bank, developer or jurisdiction requires another action, the route exposes it instead of hiding it behind the word “automatic.”
A bad connection must not repeat a payment
In a transaction, failure is not a red toast. It is a stranded hold, a duplicate charge or documents in conflicting states. Reliability is designed with the interface.
Idempotency
A hold or payment has an operation key. Repeating the request returns the existing result instead of creating a second hold or charge.
Queues and safe retries
When an external service is unavailable, the operation is not lost. The system knows what finished, what is waiting and what can be retried.
Compensating action
If the chain stops, the reversal is known: release the hold, refund under project rules or stop the document package.
Responsibility boundary
Before payment, the buyer sees who owns the unit, money, documents and registration, plus refund rules and any applicable insurance.
A working transaction first.
The film comes later.
We are already assembling the interfaces and data. The first version is built around a short choice, a real hold and one legible path to signature.
Phase two
Video for the selected plan, finish options and verified window view. It helps the decision; it does not replace live inventory or the hold.
The first version
- 01one unit schema and connectors to developer feeds
- 02a 3–5 option shortlist by budget, household and goal
- 03API booking with price, expiry and hold terms
- 04data collection and preparation of the document package
- 05signature, submission and status orchestration without duplicate operations
We do not count conversations
- shortlists that become holds
- holds that become completed deals
- time from first request to signature
- expired holds and the reason for each
Have a live feed or booking API?
Connect the project to the build.
Send the documentation, a sample export or your technical contact. We will map unit states, hold rules, payment, documents and responsibility boundaries.
Write in Telegram. A project link and a sample feed are enough to start.
- 01We do not promise an integration before inspecting the source
- 02We do not replace the buyer's signature with an agent action
- 03We do not present expired inventory as current