PMS & OTA Integration

What you asked for

Understand what is realistically possible with SMARTORDER, and whether it can integrate with everything else. SMARTORDER is low cost and not sacred — the team is free to change if something fits better. Eventually the ideal PMS connects as many international OTAs as reliably as possible: Airbnb, Booking.com, Agoda, Expedia. And explicitly: reliability matters more than automation here, because synchronisation problems and double bookings create far larger issues than any efficiency gain is worth.

That instinct is correct, and it is the one place in this handbook where the recommendation is to buy without hesitation.

SMARTORDER: what could be established

There is a real company: 株式会社スマートオーダー / SmartOrder Inc., Minato-ku, Tokyo, founded September 2022, capital ¥65M, whose stated primary business is inbound advertising services for the China market. It markets a cloud PMS for hotels, ryokan and minpaku covering reservations, front desk, room management, a site controller (channel manager), contactless payment and cleaning management.

What the public record actually supports, stated plainly:

• Two branded surfaces exist — a Japan site and a much larger generically-branded global site whose marketing copy claims "200,000+ properties worldwide." That claim reads as reused template or white-label copy rather than an audited figure.
• No public API, webhook or CSV-export documentation could be found. No developer portal on either domain.
• No third-party channel manager lists SMARTORDER as an integration. Not Beds24, not Hostex, and — significantly — not TL-Lincoln, Temairazu or ねっぱん, all of which publish named PMS-integration partner lists.
• No independent review coverage. No G2, no Capterra presence found.

Two honest conclusions follow.

First: treat it as an opaque system for integration purposes. Not "bad" — it may be perfectly serviceable as a booking engine at its price point. But you cannot build an operations layer on a system whose data access you cannot document.

Second: ask the vendor directly, in writing, before deciding anything. Smaller Japanese vendors frequently have private or partner APIs they do not publish, and will grant bespoke access to a larger account. You are becoming a larger account. The specific questions are at the end of this chapter. Until you have written answers, treat every claim about SMARTORDER's capabilities — including from your own team — as unverified.

If the answer is "no API," you have three options: manual/CSV bridges (viable at 15 units, unmanageable at 200), a scraping bridge against their web UI (fragile, and it will break at the worst possible moment), or migration. At your growth trajectory, migration.

The OTA access reality

This deserves stating bluntly because it eliminates a whole category of plans:

You will not get your own OTA API keys, and you should stop wanting them.

• Airbnb runs an invite-and-approval Partner API programme. Access goes to established PMS and channel-manager companies with scale, a security review and a signed partner agreement. Not to operators, at any unit count you are likely to reach.
• Booking.com has a formal Connectivity Partner Programme with genuinely good public documentation — and its connectivity portal currently states it is pausing integrations with new connectivity providers until further notice. Becoming a new certified Booking.com partner is not currently possible even for well-resourced applicants.
• Agoda publishes a YCS Channel Manager API, explicitly framed for "Channel Manager Partners," onboarded by email request. It is mid-rollout of mandatory OAuth 2.0 by 2026, tightening requirements further.
• Expedia is the most self-serve-friendly, with documented launch requirements and a mandatory site review before go-live — but property-management-side connectivity is a separate portal requiring you to adopt Availability & Rates, Reservation and Property Management APIs as a set.
• Trip.com has no open self-serve developer signup; onboarding runs through eBooking or a certified connectivity provider. It matters disproportionately for Japan and Bali given Chinese-market demand.

So: buy the certified connections. Build against one PMS/channel-manager API and let that layer carry the OTA relationships, the certifications, the security reviews and the breaking-change management. This is not a limitation of your ambition; it is the correct division of labour, and every AI and ops vendor in this market makes the same choice.

The Japanese domestic layer, which Western vendors do not reach

This is the wrinkle most international advice misses, and it will matter to you.

Japan's OTA market is not Airbnb and Booking.com. Jalan (Recruit) and Rakuten Travel are dominant domestic channels, particularly for hotel- and ryokan-licensed inventory, and effectively no Western channel manager reaches them natively. Access runs through Japan's domestic site controllers:

• 手間いらず (Temairazu) — Japan's most widely used channel manager/site controller, roughly the SiteMinder position. Integrates with many OTAs and PMSs via its own "TEMAIRAZU format," and keeps adding PMS partnerships. It is the connectivity layer many Japan-only PMS vendors — including AirHost — build on rather than connecting to OTAs directly. No public developer API found; integrations are bespoke negotiated feeds.
• TL-Lincoln (TLリンカーン) — the largest site controller for hotels and ryokan, backed by Recruit and JTB capital. It is a de facto industry-standard output format that many domestic PMSs ingest, rather than a modern REST API. Expect flat-file-era integration: strong for traditional distribution, weak as a foundation for custom automation.
• ねっぱん (NEPPAN, Clips Inc.) — claims number-one site-controller market share on Deloitte Tohmatsu/MIC research, actively announcing PMS integrations. Again a channel manager, again via named partnerships rather than a public API.

And the domestic minpaku PMS tools — AirHost, Beds by Livable, 管理くん, patto, HOTEL SMART, m2m Systems / 民泊クラウド — mostly plug into Temairazu or NEPPAN for OTA connectivity rather than connecting directly. Public API information for third parties is thin to nonexistent for most. Japanese comparison articles evaluate them on price, UI and support, essentially never on API depth — which is itself the signal. Assume no usable API unless a vendor confirms one in writing.

Practical consequence: if and when you need Jalan or Rakuten Travel — which you likely will as the portfolio moves toward hotel-licensed inventory in Japan — you will need a Temairazu or NEPPAN connection in addition to your international PMS, regardless of which PMS you choose. Scope that early rather than discovering it during a hotel acquisition.

Candidate PMS platforms

Evaluated on the criteria that actually matter for this plan: documented API, webhooks on reservation change, certified OTA coverage, multi-country and multi-currency support, and a messaging API.

Shortlist: Hostaway, Hostex, Guesty, with Beds24 as a deliberately cheap proving ground.

The considered recommendation: trial Hostex and Hostaway in parallel on a handful of real units, in both Japan and Bali. Hostex has the better Asia and Trip.com position plus a Japanese product; Hostaway has the more battle-tested API surface and the more honest documentation. Guesty enters the conversation properly at the company's ~1,000-unit scale, where its enterprise tooling and multi-entity handling earn their cost — and it is worth getting a quote now so the company plan is priced, even if your personal portfolio starts elsewhere.

A word on splitting. Running your ~200 personal units and the company's ~1,000 on different platforms is defensible — different entities, different economics — but it doubles your integration surface forever. If the operations layer is meant to serve both, weight platform choice toward the one that can carry both, and abstract the PMS behind an internal interface (below) so a future migration is a connector rewrite rather than a rebuild.

The integration architecture

The single most important engineering decision in the whole plan:

Never let the operations layer talk to a PMS directly. Put an interface in between.

   ┌──────────────────────────────────────────────────┐
   │           OPERATIONS LAYER (modules 1-6)         │
   │  speaks only in your own domain vocabulary:      │
   │  Property · Unit · Reservation · Guest ·         │
   │  Rate · Task · Item · Message                    │
   └───────────────────────┬──────────────────────────┘
                           │  internal interface
   ┌───────────────────────▼──────────────────────────┐
   │  connectors — one per source, swappable          │
   │  [Hostex] [Hostaway] [Temairazu] [CSV import]    │
   └───────────────────────┬──────────────────────────┘
                           │
   ┌───────────────────────▼──────────────────────────┐
   │  PMS / channel manager / site controller         │
   └──────────────────────────────────────────────────┘

This costs perhaps a week extra and it buys three things you will certainly need: the ability to change PMS without rewriting six modules; the ability to run two PMSs at once during a migration or across regions; and the ability to add a Temairazu connector for Japanese OTAs later without touching anything above the line.

Sync rules, in order of importance

1. The PMS owns the calendar. Full stop. Your layer reads reservations and never writes availability. Rate pushes are the only write, they are always human-approved, and they go through the PMS's documented endpoint. This single rule eliminates the double-booking risk you are rightly worried about.
2. Webhooks first, reconciliation always. Subscribe to reservation created/updated/cancelled and message-received events. Then run a nightly full reconciliation anyway, because webhooks get dropped, and a missed cancellation means a cleaner dispatched to an occupied unit. Log every discrepancy the reconciliation finds — that log is your integration health metric.
3. Idempotency everywhere. Every inbound event carries an external ID; process each exactly once. Duplicate webhook deliveries are normal, not exceptional.
4. Never destructive on ambiguity. If a reservation arrives that contradicts local state, flag it for a human. Do not auto-resolve, and do not cancel tasks on ambiguous input.
5. Store the raw payload. Every webhook body, unparsed, retained. When something goes wrong six weeks later — and it will — this is the difference between an hour's diagnosis and a shrug.

What the PMS must provide

Use this as the actual evaluation checklist. Anything marked required is genuinely disqualifying if absent.

Required

• Documented REST API with authenticated access for your own account
• Webhooks on reservation created / updated / cancelled
• Reservation read including guest name, dates, unit, channel, status, payout, guest count
• Certified Airbnb and Booking.com connections
• Multi-property, multi-currency, multi-timezone
• Rate and availability read; rate push endpoint
• Guest messaging read and send for at least Airbnb and Booking.com

Strongly wanted

• Message-received webhook (polling works but adds latency, and latency is ranked)
• Agoda, Expedia and Trip.com connections
• Sandbox or test environment
• Documented rate limits, and a changelog

Ask about explicitly

• Data export on exit — can you leave with your reservation history?
• Behaviour on connection loss: does it queue, drop, or double-book?
• Whether connecting a channel makes the PMS the master calendar (Hostaway documents that it does; assume others behave similarly and confirm)
• Japanese-language support for staff, and Japanese/Indonesian invoicing

Compliance, which is a PMS-adjacent problem

Neither Japan's nor Indonesia's regulatory requirements are things a Western PMS will handle for you. Chapter 7 covers the data model; the PMS-relevant parts:

Japan. Under 住宅宿泊事業法, minpaku listings operate under a 180-day-per-year cap per listing (further restricted by municipal ordinances — parts of Tokyo effectively bar weekday operation), must maintain a 宿泊者名簿 guest register per stay including name, address, occupation and nationality with passport/ID verification for foreign guests lacking a Japanese address, and must file bi-monthly reports to the 民泊制度運営システム, a login-gated government web portal with no evident public submission API. Assume manual or semi-automated filing. Hotel- and ryokan-licensed properties fall under 旅館業法 instead: no 180-day cap, stricter facility and fire-safety licensing, same register obligation.

Your system therefore needs, as hard features rather than nice-to-haves: a per-property legal regime flag, a 180-day usage counter with projection ("this unit will hit the cap on 14 November at current booking pace" is a genuinely valuable alert your PMS will not give you), and an exportable structured guest register.

Bali. Enforcement tightened sharply with Permenpar No. 6/2025, effective 31 March 2026: villas listed on Airbnb, Booking.com and Expedia must have a verified NIB business registration number or risk delisting. Pondok Wisata (KBLI 55130) is restricted to Indonesian citizens and capped at roughly five rooms; foreign-owned operations need a PT PMA with a villa licence (KBLI 55193), plus zoning, PBG/SLF building certificates, and regional hotel/restaurant tax (PHR) registration. Critically, Bali enforcement lands at the OTA listing level — platforms are being made to verify NIB before listings stay live — which is structurally different from Japan's government-portal model. Track licensing documents per Bali property with expiry dates, and expect OTA-side verification requests.

Effort and risk

Effort: the migration itself is the work, and it is mostly not engineering — it is re-listing, re-mapping rates and restrictions per channel, and a careful cutover window per property. Budget a pilot of three to five units for a full month before moving anything else. The connector layer is a week.

Risk: this is the highest-consequence and lowest-uncertainty item in the handbook. Migration risk is real and well-understood: double bookings during cutover, lost restrictions, broken rate plans. It is managed with a small pilot, a channel-by-channel checklist, and a freeze on rate changes during cutover — not with cleverness. Once through, this is the most stable component you own, because you will own very little of it.

Decisions for you

1. Send SMARTORDER the questions this week. In writing: Is there a REST API, and can you see the documentation? Are there webhooks on reservation changes? Can you export full reservation history as CSV? Which OTAs are direct connections versus via a site controller? Can guest messages be read and sent programmatically? Their answers make this decision for you.
2. Trial Hostex and Hostaway on three to five real units each, split across Japan and Bali. Test the thing that actually matters: create a booking on each channel and watch what the webhook delivers and how fast.
3. Get a Guesty quote now for the ~1,000-unit company scenario, even if you start elsewhere. It prices the ceiling.
4. Decide: one platform for personal and company, or two? Recommendation: one, with the connector abstraction as insurance.
5. Scope Jalan and Rakuten Travel. Do you want Japanese domestic OTA distribution in the next 12 months? If yes, Temairazu or NEPPAN enters the plan now rather than later.
6. Confirm the legal regime of every current and planned Japanese property — minpaku registration or 旅館業法 licence — because the 180-day counter and the reporting cadence depend on it, and it cannot be inferred from the PMS.