Integrating Hundreds of Different Systems: How hello again GmbH Scales Loyalty Integrations with Small, Reusable Building Blocks

Session context: “Integrating hundreds of different systems” by Markus Gasplmayr (hello again GmbH)

In “Integrating hundreds of different systems,” Markus Gasplmayr, a backend developer at hello again GmbH, walks through how the team connects their loyalty platform to hundreds of heterogeneous third-party systems—cash registers, booking tools, online shops, CRMs, and more. The mission is straightforward but demanding: maximize value for each client’s end customers without drowning in bespoke, hard-to-maintain integrations.

hello again doesn’t ship a single, central app. Instead, they deliver a customized loyalty solution per client across industries—retail, e-commerce, service providers like hairdressers, and even cities or economic regions. Client size ranges from a few thousand to several million end users. The product suite spans the user-facing app and web app plus a client dashboard: user management, loyalty mechanics (earning points, redeeming rewards), feedback tools, sharing features, messaging, analytics—and crucially, third-party integrations.

This idea drives every technical decision Marcus outlines: standardize, reuse, orchestrate—and keep client-specific code as small and isolated as possible.

The problem space: Many systems, varied constraints—a scalable integration approach

Markus frames three recurring customer types:

1. Type 1: Unrestricted possibilities—APIs available, custom code permitted, full openness.
2. Type 2: Limited possibilities—no client-side custom code, but services are available for consumption.
3. Type 3: No possibilities—no custom code, no services.

Beyond these constraints, reality adds further complexity:

• Hundreds of different systems, including in-house solutions.
• Varied combinations and usage patterns of subsystems.
• Occasional lack of technical know-how on the stakeholder side.

The overarching target is clear: avoid a maintenance nightmare of bespoke integrations and instead build “really simple and generic integrations and processes” for fast onboarding and easy upkeep.

Architecture overview: Core platform with well-defined integration points

At the core, hello again runs multiple backend instances behind their server, backed by a database and communication gateways for push notifications, emails, and SMS. Their apps, web app, and dashboard communicate directly with this server. The key question is how to attach third-party systems to this setup.

For Type 1 customers (with open capabilities), there are multiple routes:

• External APIs for most features—user data, receipt uploads, reward creation, and more.
• Plugins for selected online shops (built with partners) that are easy to install and cover the common needs: user synchronization and purchase/receipt uploads to hello again.
• Configurable backend services—webhooks and coupon backends—to address external systems via configuration, such as forwarding user data to a CRM after signup or validating scanned codes against a third-party system.

For Type 2 customers (limited possibilities, but services available), hello again will handle the integration, with three explicit design goals: keep custom code separate from the backend; make implementation, setup, and maintenance easy; and maximize reusability.

For Type 3 customers (no options), the team looks for minimal yet meaningful workarounds—simple data exports, for instance—or deploys their POS solution that works without touching the POS software.

The integration toolkit

Markus outlines several building blocks that cover the breadth of integration scenarios:

• External APIs: The standard interface for exchanging user data, uploading receipts, creating rewards, and more.
• Shop plugins (with partners): Simple to install and encapsulate common chores like sync and uploads.
• Google Cloud products: Cloud Functions, Cloud Run, and Cloud Workflows—used to implement modular, reusable integration components.
• Open Integration Hub: An open-source integration platform used earlier; Markus notes they ran into stability and failure issues, which motivated a shift to Google Cloud services for later integrations.
• Configurable backend services: Webhooks and custom coupon backends to trigger external actions or validate codes without changing the core backend.
• POS solution: A piece of software installed directly on the POS system’s operating system (not within the POS software). It intercepts the print process at checkout, prompts for customer data (e.g., customer number or a scan from the app), uploads the to-be-printed receipt along with that data, and lets the server process it via OCR to award points.

Design principle: Small, focused, configurable

That principle defines the Google Cloud approach:

• A Cloud Function dedicated solely to uploading receipts, configured per integration.
• Another Cloud Function that does only one thing: download a file (e.g., from an FTP server).
• Client-specific transformation functions to convert third-party formats to the internal schema.
• Workflows and schedulers to chain these steps into reliable end-to-end processes.

With these building blocks, hello again can assemble integrations quickly while keeping custom code small and contained.

Integration paths by customer type

Type 1: Open client systems—APIs, plugins, configuration

When the client offers APIs and allows customizations, hello again’s workload is minimal. Typical moves:

• Use webhooks to connect events (like signup) to external systems (e.g., forward user data to a CRM).
• Leverage the external API for core actions: sync users, upload purchases/receipts, create rewards.
• Install shop plugins to handle sync and upload flows “out of the box.”

Most of the work is guidance and support; the integration primitives are already in place.

Type 2: Services available, no custom code—hello again builds and operates

The team aims for three outcomes:

1. Keep custom code outside the core backend.
2. Make the setup and ongoing maintenance easy.
3. Maximize reusability across integrations.

Common tasks include:

• Data transformation: converting incoming data to the platform’s internal format.
• Pulling files from external systems and pushing content to the platform.
• Uploading receipts to hello again’s external API.

Earlier, some of this ran on Open Integration Hub. However, stability and failures prompted a shift toward Google Cloud Functions/Run/Workflows. The underlying idea remained the same: small, configurable modules doing one thing well, plus workflow orchestration to connect them.

In practice, the core components are:

• “Upload Receipt”: A generic Cloud Function that posts formatted receipts to the API.
• “Download File”: A generic Cloud Function that retrieves files (e.g., via FTP).
• “Transform Data”: A client-specific Cloud Function to reshape data into the internal format.

A scheduler triggers a Cloud Workflow to orchestrate the pipeline on a defined cadence. The core backend remains untouched, and most integration logic stays modular and easy to maintain.

Type 3: No options—minimal exports and the POS solution

When no integrations are possible on the client side, hello again still tries to craft reasonable solutions. Even a simple export can be enough to implement “export → transform → upload” workflows.

The standout here is the POS solution: installed at the OS level, not within the POS software. It detects when a purchase completes and a receipt is about to be printed, intercepts that print job, asks for the customer identifier (typed or scanned via the app), and uploads the receipt and user data to the server. The server uses OCR to process the receipt and award points—achieving POS integration “without touching the POS software.”

Two concrete examples from the talk

1) Cash register integration (Type 1)

The basic flow, as Markus describes it:

1. The user shows the app at checkout; the ID is scanned.
2. The purchase proceeds normally.
3. When the transaction completes, the POS sends the receipt to hello again’s server.
4. The server processes the receipt and awards points.

Of course, a complete POS integration must also handle returns and rewards—but the core is straightforward. By exposing the external API, hello again’s effort is limited to supporting the client implementation.

2) Importing booking data (Type 2/3)

Assume the booking data is available on an FTP server. A workflow can be built with three steps:

• Step 1: Fetch the data—a simple, reusable Cloud Function downloads the file from FTP.
• Step 2: Transform the data—a client-specific Cloud Function converts the file into the internal format.
• Step 3: Upload the receipts—a reusable Cloud Function posts them to the server.
• Scheduling: A scheduler triggers the workflow on a schedule.

Once the reusable components exist, new integrations come together quickly; the only bespoke work is data transformation for the client’s format.

Why small components deliver big integration wins

The consistent theme is decomposition into tiny, reusable parts—a pattern that shines in heterogeneous integration landscapes:

• Lower blast radius: If a component fails, it doesn’t pull down the core backend.
• Maintainability: Fixes are rolled out where they belong—no need to change or redeploy the platform backend.
• Speed: Building blocks like “download file” and “upload receipt” are implemented once and reused across clients via configuration.
• Clear boundaries: Client-specific logic (transformations) is isolated; generic functions remain product-wide assets.

These align with Markus’s goals: separation from the backend, simplicity in setup and maintenance, and high reusability.

What makes the POS solution notable

POS software is notoriously hard to extend. hello again’s approach sidesteps modification entirely:

• Install software at the OS level, not within the POS application.
• Intercept printing when the purchase completes.
• Prompt for the customer ID (typed or scanned via the app).
• Send the would-be printed receipt to the server; process it with OCR; award points.

This “bypass” model unlocks loyalty mechanics even in highly constrained environments. For end users, the experience remains straightforward: present the app, get scanned, earn points.

Evolving the toolset: From Open Integration Hub to Google Cloud

Markus is candid that finding the right tools took time and iteration. Using Open Integration Hub exposed stability issues and failures. As requirements evolved, they switched later integrations to Google Cloud Functions/Run/Workflows.

The payoffs from the current setup are tangible: faster, more reusable integrations with simpler maintenance.

Outcomes and metrics cited in the talk

Markus highlights three outcomes:

• Speed: “We could actually cut the time effort in half for the integrations.”
• Reuse: “We can actually reuse up to two-thirds of our functionality.”
• Maintainability: Separating the server from minimal custom code makes fixes and updates quick—no waiting, no heavyweight deployments.

Together, these underscore that a strategy of small building blocks, clean orchestration, and minimal client-specific code scales in practice.

Engineering takeaways to apply

• Build generic integration components that do exactly one thing (e.g., “download file,” “upload receipts”), and make them configurable.
• Isolate client-specific transformations in dedicated functions; keep everything else generic.
• Orchestrate with workflows and schedule execution—without touching the core backend.
• Offer external APIs and shop plugins so clients with open systems can implement with minimal friction.
• Use configurable backend services (webhooks, coupon backends) to trigger external systems without core changes.
• For POS environments, think at the OS layer when the application layer is off-limits—the print interception point is effective.
• Expect iteration in tooling: requirements change; stability matters; replacing a platform can be the right call.
• Measure success by speed, reuse, and maintainability—not by the number of bespoke features.

Conclusion: Integration as a product discipline, not a one-off project

“Integrating hundreds of different systems,” presented by Markus Gasplmayr (hello again GmbH), demonstrates that scaling integrations isn’t about one monolithic super-integration. It’s about many small, composable components and a strict separation between generic capabilities and client-specific data transformation.

The combination of external APIs, shop plugins, configurable backend services, Google Cloud building blocks, and the OS-level POS solution forms a toolbox that adapts to even the most constrained environments. The approach accelerates integration timelines, reduces maintenance overhead, and boosts the practical value of the loyalty platform—regardless of whether a client is fully open, partially open, or seemingly closed.

For engineering teams facing similar challenges, the core playbook is pragmatic and proven: break integrations into the smallest reusable steps, limit bespoke code to the transformation layer, and orchestrate everything cleanly. The outcomes Markus cites—halved integration effort, two-thirds reuse, and straightforward maintenance—show that this strategy holds up under real-world heterogeneity.

• 

  

  How to build and maintain 1.000 Apps

  Michael Schöndorfer von hello again spricht in seinem devjobs.at TechTalk über die Challenge, eine große – und stetig wachsende – Anzahl an Apps zu entwickeln und zu verwalten.

  Watch now

• 

  

  Sebastian Auberger, CIO bei hello again

  Der CIO bei hello again Sebastian Auberger redet im Interview darüber, was neue Devs erwartet – aus technologischer und aus persönlicher Perspektive – und welche Möglichkeiten zur Weiterentwicklung es gibt.

  Watch now

• 

  

  Malith Thilakarathne, Mobile Developer bei hello again

  Mobile Developer bei hello again Malith Thilakarathne erzählt im Interview über seinen Einstieg in das Entwickeln von Mobile Apps, was seine aktuelle Arbeit besonders macht und gibt Tipps für Neueinsteiger.

  Watch now