#Integrations: living with the hardware and software restaurants already have

TL;DR

• We do not build live connectors into incumbent POS systems. We build one-shot migration importers. An importer costs ~40% of a live connector, needs no partner approval where an export path exists, has ~0.1 eng-months/year of maintenance instead of 0.35–0.6, and cannot be revoked mid-contract. It also kills the hardest objection in POS sales ("I'll lose three years of history") in a 30-minute onboarding step.
• The five that ship first, in order: Google Business Profile → Dotypos migration importer → generic CSV/Excel menu importer → Storyous migration importer (v1 Full) → HubRise-resold delivery module (v3). Total canonical budget for the domain is 4.0 eng-months in the S1-cut v1 sellable, 8.5 in Full, +5.5 in v2 core and +5.0 in v3 (canon §5.1, domain I books +9.0 for all post-v1 integration work; the +1.5 difference is the HubRise module moving out of Full — §2.2). None of the first three needs a partner's permission; GBP needs an allowlist and HubRise needs a reseller agreement.
• CRM-on-someone-else's-POS is not a cheaper version of this business, it is a different and worse one. Not because of the identity gap alone (24% of Checks against 30–38% at v1 with A4 true — 22–28% if false — and **52% (v2 core)** once QR PWA ordering and Wallet passes ship, canon §1 and 05 — The CRM Product and Scope Tiers §3.2) but because an overlay has zero switching cost, churns at 40–60%/yr [known] against a POS's 22–25%, and clears 3–37% gross margin once middleware COGS lands [known, r07 §4.1]. The engineering is the easy part; the business is unfixable.
• Middleware is a purchase, never an architecture. HubRise is the only vendor with acceptable economics (EUR 35/site/mo standard, EUR 30 at 6–30 sites, EUR 27 at 31+, no setup fee for standard locations, self-funded and independent as of today [verified, hubrise.com/pricing, 2026-08-18]) and the only one with a first-class customer + loyalty model. Deliverect, Otter, Chowly and Omnivore are permanently out of scope (canon §4).
• Aggregators give you an operational win and zero CRM value, and the "win your customers back from Glovo" QR is a connector-revocation risk, not a feature. Canon puts it out of scope unless we decide in writing never to build aggregator connectors. Since canon still plans a delivery module (v3 under the v2-core/v3 tier split), treat the in-parcel QR as dead and remove it from every sales asset now.
• Maintenance drag is the number that decides the portfolio size: 5 connectors = 1.8–3.0 eng-months/yr (4–7% of S1's 42 eng-months/yr); 15 = 5.3–9.0 (13–21%); 40 = 17.5–30 eng-months/yr plus a non-engineering partner-relations owner — arithmetically impossible for S1 and a dedicated pod for S2. The portfolio ceiling for S1 is ~8 live surfaces, forever.

Sibling docs: strategy and go/no-go in 01 — Feasibility verdict · adapter/port mechanics and the event log in 02 — System architecture · printers, terminals and device fleet in 03 — Hardware, peripherals and the device fleet · PSP, fiscal-provider and accounting-export obligations in 04 — Payments, fiscalisation, privacy and security · identity, consent and messaging channels in 05 — The CRM Product and Scope Tiers · sequencing and budget in 07 — Roadmap, Team and Budget · risk register in 08 — Pros, cons, difficulties and risks.

Scope boundary for this document. Messaging channels (SMS aggregators, WhatsApp, Viber, Telegram) are not integrations in the canon's accounting — they sit in domain G (CRM) and are specified in 05 — The CRM Product and Scope Tiers. Fiscal providers (fiskaly, Checkbox/Vchasno, GUM kasa-online printer partners) sit in domain F and are specified in 04 — Payments, fiscalisation, privacy and security. Payment terminals sit in domain E. This document owns exactly one thing: third-party systems whose availability we do not control and whose breaking changes we must survive.

Unit convention throughout: 1 eng-month ≈ 4.3 eng-weeks, senior engineer with the canon §5.1 AI-assist multipliers already applied.

#1. The strategic verdict, and what it costs you in data

#1.1 Three paths, priced

Canon §1 already decides this: own the POS, sell it CRM-first. This section exists to state why the other two lose, in numbers a due-diligence reader can check.

The argument that actually carries the decision is not the identity gap. c03 C11 is right that identified Guests are not a random sample — loyalty members visit 1.5–2.5× more often and spend 10–25% more per Check [known], so 24% of Checks is worth more than 24% of revenue and the true value gap is 1.7–2.0×, not 3×. The decisive facts are the two rows in bold: an overlay has no switching cost and no payment rail. Cancelling a loyalty tool costs the restaurant nothing; cancelling a POS closes the restaurant. That is canon §1's "installed base × switching cost × payment contract", and no amount of connector engineering changes it.

#1.2 The capability ladder — grade every vendor on this, not on "we have an API"

Two structural consequences:

1. T3 is embedded software, per vendor, per runtime. iiko/Syrve = a .NET Front plugin; Oracle Simphony = an Extension Application on the workstation; Aloha = a DLL on the BOH file server; Clover = an Android app on the device [known]. A cloud team cannot ship T3 without becoming four embedded teams. At S1's 3.5 effective eng-FTE (canon §5.2) that is not a trade-off, it is a category error.
2. T2 for in-store card is the one thing every incumbent reserves for its own loyalty product, because it requires being the processor. Toast, Square, Clover, Lightspeed and PAR all sell their own CRM/loyalty; PAR owns Punchh; Olo owns Wisely and Omnivore; iiko ships iikoCard; r_keeper ships Farcards [known]. We would be building the single highest-margin attach product each platform most wants to keep.

#1.3 What you can and cannot learn about a Guest, per data source

Coverage is share of a Site's Checks attributable to a known, contactable, deduplicated Guest.

The importer trap, stated as a rule. An imported customer table gives you identifiers but not the Art. 7(1) evidence that the Guest consented — no policy-text hash, no timestamp, no ui_surface, no channel scope. Canon invariant 11 is therefore not a nicety: the migration importer sets marketing suppression by provenance and the segment builder cannot clear it. The concrete failure it prevents (c02 M7): a Customer migrates from Dotypos, we import 18 months of Glovo-sourced Orders, the segment builder includes them, the first win-back SMS goes to people who only ever ordered through an aggregator, and it is an unlawful-processing complaint with the Customer's name on it and our infrastructure underneath. Imported Identities land suppressed; they become marketing-eligible only by re-consenting on a surface we own.

#1.4 The seven questions the Customer actually asks

This is the demo. Map it against what each path can answer. The JTBD is canon-adjacent: "I own four cafés, I cannot tell you which of my regulars stopped coming, and I cannot tell you which of my four managers is discounting."

Four of seven are unanswerable on any overlay, and they are the four that close deals. That is the product argument for canon §1, independent of the coverage arithmetic.

#2. Incumbent POS integration table

RT = real-time push of Check events. ID = usable Guest identifier for in-store card. WB = write a loyalty Discount to an open Check pre-Tender (T3). Eng-weeks = our cost for a live production connector including mapping UI, backfill, retries, reconciliation and a support runbook — a hypothetical for every row whose verdict is "Never".

#2.1 Two facts from this table that change the plan

Teya gates both beachhead importers. Canon A3 says Teya owns Storyous and holds a majority of Dotykačka, which makes Teya structurally unavailable as a CZ payments partner. The consequence nobody wrote down: Teya also controls the credentials our Dotypos importer needs. Dotykačka's API requires a partner licence key issued on request and is only available to Customers on FULL/UNLIMITED licences [known, search-corroborated 2026-08-18]. A single policy decision at Teya turns off our best migration path in our only market.

The mitigation is a design decision, not a negotiation. The Dotypos importer must accept two input paths of equal standing: (a) the API, when a partner key exists; (b) the CSV/XLSX export the Customer generates themselves from the Dotykačka back office, which requires nothing from Teya. This promotes the generic CSV/Excel importer from a fallback to a load-bearing v1 component — which is exactly where canon §4 already puts it, and now for a stated reason. Every importer we write targets the file path first and the API path second.

#2.2 What we build, and what it costs (canon §5.1 domain I, reconciled)

Two arithmetic notes on this table, because both totals moved.

• Why the Full column still lands on canon's 8.50. Under the canon tier split the HubRise-resold delivery module is v3, not v1 Full, so its 1.50 leaves this column: 4.00 (S1 cut) + 1.00 (Storyous) + 1.00 (mapping UI) + 1.00 (observability) = 7.00 against canon §5.1's 8.50. The 1.50 of headroom goes to the two lines that were plainly under-costed as bare 1.00 placeholders — the mapping-UI framework and the observability / drift-detector / contract-test harness, each to 1.75 — because each now has to carry three v2-core importers instead of one. New subtotal: 4.00 + 1.00 + 1.75 + 1.75 = 8.50, matching canon.
• The post-v1 total no longer matches canon and is not fudged to. v2 core (5.50) + v3 (5.00) = 10.50 against canon §5.1's +9.0 for domain I. The 1.50 difference is exactly the HubRise module moved out of Full. Either canon §5.1 domain I is restated as 8.5 Full / +10.5 post-v1, or the module is re-costed; do not close the gap by shaving an importer.

The Full-tier lines P3 must repay. The S1 cut skips the Storyous importer (named in canon §4's "Full only" list), plus the mapping-UI framework and the connector observability harness (Full-tier in this table's split of canon §5.1 domain I; canon §4 does not itemise them). The last two are prerequisites for the v2-core UA importers — Poster, r_keeper and iiko/Syrve are three mapping-heavy builds landing in one phase — so 1.75 + 1.75 = 3.50 eng-months of Full-tier deferral has to be repaid inside P3, before or alongside the 5.50 of v2-core work. The Storyous importer does not have to be, unless the §10 trigger fires.

Not in this budget, by canon: messaging channels (domain G), accounting export (domain B), fiscal providers (domain F), payment terminals (domain E).

#3. Middleware: make-vs-buy

#3.1 The margin stack, recomputed at canon ARPU

r07 computed this at a EUR 59 CRM-only price. Canon §5.4 sets CZ subscription ARPU (POS+CRM+KDS) at EUR 110–130/site/mo, so the arithmetic changes and only one column survives. The delivery module is an add-on priced on top of that subscription, and it is now a v3 line, not v1 Full (canon tier split).

Decision recorded, and it is a reprice: the delivery module lists at EUR 59, not EUR 39–49. At the old EUR 39–49 the module was break-even to ~35% and canon A16's ">50% gross margin at EUR 27–35/site" gate was arithmetically unreachable. At EUR 59 the gate becomes reachable, but only at the bottom of the COGS band: 54% at the EUR 27 tier (31+ sites), 49% at EUR 30 (6–30 sites), 41% at EUR 35 standard, all before the support allocation. Clearing >50% across the whole EUR 27–35 band would need a EUR 70–75 list price, which is not sellable as an add-on against a EUR 110–130 subscription. So the gate is restated as ">50% GM at the EUR 27 COGS tier against a EUR 59 module price, with a 40% hard floor at EUR 35" — below that floor the module is dropped or Glovo is built natively, it is not discounted further (§11, A16).

It is explicitly not a 0%-margin closing concession. A concession would look free and is not: HubRise bills per Site per month, so the cost scales with exactly the thing we are trying to grow, and a zero-margin line item on every delivery-taking Site is an unbounded liability rather than a one-off discount. HubRise resale is still not a profit line — it is a feature we buy to stop losing deals — but at EUR 59 it at least pays for its own support.

What HubRise genuinely buys, and it is not margin:

• One integration instead of four, saving ~11–13 eng-months against building Glovo + Bolt Food + Wolt + Uber Eats natively [known, r07].
• The sentence "we already connect to 100+ systems" in a chain RFP, on day one, truthfully.
• A customer + loyalty data model, so a Guest identified through the delivery channel can at least be analysed — never marketed to (§4.3).

What it does not buy: control. If HubRise is acquired by a POS or an aggregator, this flips from wedge to trap overnight — that is the Omnivore precedent exactly. Canon A16 owns that assumption; the mitigation is that the HubRise adapter sits behind our own OrderIngress port (§7) so a native Glovo connector is an adapter swap, not a rewrite.

#4. Delivery aggregators

#4.1 Capability and onboarding

Canon position: none of these is built natively in v1, v2 core or v3 unless HubRise's coverage costs us a named deal (canon A16). Wolt's SSIO is the one that would be cheapest to add later if that trigger fires in CZ, because the merchant-linking step — which is 10% of the build and 90% of the operational pain — is done by Wolt's own UI rather than by our ops team.

#4.2 Where the eng-months actually go (if we ever build one)

#4.3 The CRM truth, and the feature we must not ship

Every aggregator withholds Guest identity, in every market, deliberately. First name, last initial, a relayed phone that expires, a sometimes-truncated address. No email, no stable customer ID across Orders, and terms that prohibit onward marketing. A Customer doing 35% of revenue through Glovo has 35% of its business permanently outside its own Guest database, and we cannot fix that.

Three consequences to put in writing:

1. Aggregator Orders create a separate, marketing-suppressed Identity, linked into the Cluster for analytics only (spend, frequency, item mix), never as a marketing target — unless the Guest independently joins on a surface we own with the same phone. Canon invariant 11; enforced in the schema, not in a policy note.
2. Sell aggregator data as analytics, not CRM. Delivery-zone heatmaps, channel mix, item cannibalisation, per-channel margin after commission. That is genuinely useful and entirely lawful.
3. The in-parcel "win your customers back from Glovo" QR is out of scope (canon §4). Aggregator partner agreements standardly prohibit using the integration to solicit the platform's customers or divert Orders off-platform [known, c02 C8b — must be re-verified against the actual Glovo/Wolt/Bolt agreements if ever reconsidered]. The penalty is not a warning letter, it is connector revocation across every one of our Sites simultaneously, in the exact channel that is 15–40% of the Customer's revenue. Canon's trigger is that we may only build it if we decide in writing never to build aggregator connectors. Since canon still plans the delivery module (v3 under the tier split), that trigger will not fire. Delete the claim from every deck and demo script now, before a salesperson promises it.

#5. Google and Apple surfaces

Canon A14 update. A14 assumes the GBP allowlist is granted, owner = Product, apply in M1, due M6. The 7–10 business-day Basic Access SLA [known, search-corroborated] is materially better than r07's "days–weeks, opaque" framing, but the quota is the real constraint, not the approval: per-project quotas are tight and review-reply automation across dozens of Sites is a documented pain point in Google's own developer forums [known, search-corroborated 2026-08-18]. Design consequence: review sync is a scheduled, quota-budgeted pull with per-Org fairness, never a per-page-load fetch, and the quota-increase request goes in at the same time as the access request, not after the first customer complains.

#6. Accounting, payroll, inventory

The rule that saves 6–8 eng-months: in CEE, a correctly-formatted export file beats an API integration. Accountants want a file they can import into the package they already run. They do not want OAuth, they do not want a portal, and they will not maintain a token. A template-driven export engine — configurable CSV/XML per country per package — is a single build that covers ~80% of demand across the whole beachhead.

This work sits in domain B (canon §5.1: "accounting export"), not domain I. Canon scope: one CZ format in the S1-cut v1; more formats are Full-only. Listed here for completeness because it is the connector question Customers actually ask.

The one non-obvious build here is free. Canon requires an EU Data Act export/switching capability in v1 sellable (Regulation (EU) 2023/2854, applicable since 12 Sep 2025, switching charges withdrawn by 12 Jan 2027 [known]). That is the migration importer run in reverse. Same canonical bundle format, same Item/Option/tax/Guest/Check schema, same validation. Build the bundle format once and you have satisfied a dated regulatory obligation, a procurement checkbox and a sales objection with one artefact. Do not let these be two projects.

#7. Connector-platform design

#7.1 The shape

Two rules make this survivable and both are non-negotiable:

• normalise() is a pure function from a recorded envelope to canonical facts. No network, no clock, no database. That is what makes contract tests run on every PR, offline, in milliseconds, with no sandbox — which matters enormously given Dotykačka has no public sandbox [known, search-corroborated] and Oracle's is billed per API call [known].
• The raw envelope is stored before it is parsed. Every support ticket in this category is "what did they actually send us". Without the log you are guessing; with it you are answering. Cost ~0.25 eng-months, saves that in the first quarter.

#7.2 The four ports

// :integrations-api — vendor types never cross this boundary.
// Money is integer minor units everywhere (canon §3.1 invariant 1).

data class ConnectorKey(val vendor: String, val apiMajor: Int)   // ("dotypos", 2)

/** One-shot read. The v1 workhorse. Never live, never write-back. */
interface Importer<C : ConnectorConfig> {
    val key: ConnectorKey
    suspend fun probe(cfg: C): ProbeResult                  // creds, scope, clock skew, entity counts
    suspend fun pull(cfg: C, cursor: Cursor): Page<RawEnvelope>
    fun normalise(raw: RawEnvelope): List<StagedFact>       // PURE. Contract-tested on fixtures.
    fun provenance(): Provenance                            // drives marketing suppression, canon inv. 11
}

/** External Order -> Check. HubRise in v3; a native aggregator only if canon A16 fires. */
interface OrderIngress<C : ConnectorConfig> {
    val key: ConnectorKey
    fun normalise(raw: RawEnvelope): InboundOrder           // PURE
    suspend fun ack(cfg: C, orderRef: ExternalRef, decision: AcceptOrReject): AckResult
    suspend fun statusUpdate(cfg: C, orderRef: ExternalRef, s: OrderStatus): AckResult
}

/** We push outward: Menu Snapshot, availability, Site status. */
interface CatalogPublisher<C : ConnectorConfig> {
    val key: ConnectorKey
    fun render(snapshot: MenuSnapshot, channel: ChannelId): VendorPayload   // PURE
    suspend fun publish(cfg: C, payload: VendorPayload): PublishResult
    suspend fun setAvailability(cfg: C, deltas: List<AvailabilityDelta>): PublishResult
}

/** Non-transactional presence surfaces: GBP, Apple Business Connect. */
interface ProfileSurface<C : ConnectorConfig> {
    val key: ConnectorKey
    suspend fun pushProfile(cfg: C, p: SiteProfile): PublishResult
    suspend fun pullReviews(cfg: C, since: Instant): Page<Review>
    suspend fun replyToReview(cfg: C, id: ReviewId, body: String): PublishResult
}

Importer is deliberately the richest port and the only one in the S1 cut. OrderIngress and CatalogPublisher exist from day one as empty seams so the HubRise adapter in v3 is an addition, not a refactor.

#7.3 Sandbox, replay and contract tests

#7.4 Versioning and surviving a breaking change

ConnectorKey carries apiMajor. Two majors may be live simultaneously; each tenant's connector binding pins one; migration between them is a data migration on the binding row plus a staged rollout through the canon §3.1 cohort ladder (lab → 3 friendly Sites → 10% → 40% → 100%).

The playbook, in order, when a partner breaks something:

The contractual half of this matters more than the engineering half, and it is not in any appendix. From the first invoice, the MSA must state that third-party connector availability is expressly not warranted, is excluded from the SLA, and is never a condition of the subscription; if a platform revokes access we owe migration assistance, not refunds (c02 C8b). ~EUR 3–5k of drafting. Absent that clause, one platform revocation converts into refund liability and SLA credits across the whole affected base simultaneously. Canon §4 already lists "contracts (MSA/DPA/SLA) that expressly do not warrant third-party connector availability" in v1 sellable — this is the reason.

#8. Maintenance drag

Per live connector per year, steady state:

Scaled, with the coordination overhead that appears above ~15:

Importers do not appear in this table, and that is the whole point. A one-shot importer's maintenance is deferred until the next time we run it; if the vendor breaks their API between migrations we discover it during a migration we are being paid for, and the fix is scoped to one Customer. Realistic drag: ~0.1 eng-months/yr per importer [estimate], and it is demand-driven rather than calendar-driven.

Canon-scope check. The S1-cut v1 has exactly two live surfaces (Google Business Profile, and the connector runtime itself) plus two importers. Steady-state drag ≈ 0.5–0.9 eng-months/yr — 1–2% of S1 capacity. Full v1 adds only the Storyous importer: ≈ 0.6–1.0 eng-mo/yr. v2 core adds Apple Business Connect plus three UA importers: ≈ 1.2–1.9 eng-mo/yr. v3 — where the HubRise module and any native Glovo connector now sit — adds two more live surfaces: ≈ 1.9–3.1 eng-mo/yr. That is the portfolio a 3.5-FTE team can carry. Anything approaching 15 live connectors is a different company.

#9. Platform risk, with the receipts and the mitigations

The structural conclusion, unchanged from r07 §8: a CRM whose data supply is an incumbent POS API has a supplier with 100% concentration risk, who is also a competitor, who sets the price, and who has a documented record of raising it. No engineering fixes that. Canon §1 is the only sane response.

#10. Priority: the five that ship first

Sixth, seventh and eighth, in order, and not before v2 core: Apple Business Connect (0.50) · Poster importer (1.25, on UA entry) · r_keeper importer (1.50, on UA entry). The HubRise-resold delivery module (1.50) and a native Glovo connector (3.50) are both v3; Glovo only when canon A16's trigger fires with a named lost deal attached.

Never, per canon §4: Toast, Aloha, Brink, Revel, TouchBistro, SpotOn, Olo, Micros 3700, Omnivore, Deliverect. Also never: Reserve with Google, payroll connectors, live inventory connectors, and any marketplace listing where the Customer's contract is with the platform rather than with us.

#11. Assumptions this document owns

#12. What would change this answer

1. A CEE POS or PSP exposing a stable, third-party-readable card token or PAR. If one does, overlay identity coverage roughly doubles and path A becomes arguable for a lower-capital plan. Confirms it: Adyen/Nexi/Worldline tokenization terms for ISV access, plus the canon A6 sandbox test.
2. HubRise's ISV-side terms. Customer pricing is verified; partner terms are not. If HubRise offers a genuine reseller margin rather than a pass-through, the §3.1 arithmetic improves, the EUR 59 reprice can be revisited and the module can move back out of v3.
3. A CZ incumbent that publishes an unrestricted bulk export. That would make its importer a ~0.4 eng-month job and could add two more markets' importers for the price of one.
4. A named chain deal that requires T3 write-back on iiko/Syrve. It is the only incumbent where full write-back is architecturally clean. Canon permits it only against a signed deal; the price is ~4.0 eng-months and becoming a .NET embedded-software shop for one Customer.
5. Wolt SSIO in Czechia specifically. If self-service venue activation works in CZ without a BD gate, a native Wolt connector becomes the cheapest aggregator to own and could displace HubRise for a delivery-light beachhead. Confirms it: one application through the public developer portal.