Building Integrations with Archilogic

In Closing the Feedback Loop we discussed how important integrations are to get buildings to reach their maximum potential. In the following paragraphs we will be sharing paths to build these integrations as well as go-to-market implications for integrators and Archilogic.

Recap - Why Integrations?

Integrations ensure two things:

1. Floor plans live in one place - the System of Record. Changes and edits are propagated automatically to every connected system.
2. Surface third-party data in context. Relevant information appears directly in Archilogic, so the person (or AI agent) editing a plan has everything needed to improve the layout.

The first point is usually an important visual requirement that needs to be in sync with the integrator’s product architecture. The second point is about sending data (usually as custom attributes) to Archilogic, where it can be shown in the context of floor plans in order to make informed edits.

What we are, and what we’re not

Archilogic is a System of Record for Floor Plans and Spatial Building Data. We do not offer room booking, occupancy analysis, digital signage, IWMS, and the like. Many excellent products already address those needs. By focusing on the SoR, we keep our product strategy clear and challenging enough, without competing with our partners.

What’s an Integration?

For Archilogic, an integration is a live, one- or two-way link between our System of Record and a partner application. It lets the partner embed an interactive floor-plan view that always mirrors the latest geometry or leverage Archilogic's Spatial Building Data model. Third-party data - sensor readings, bookings, asset tags - flows back to Archilogic and appears as contextual overlays. As we noted in our BIM vs. Archilogic piece, this “dynamic handshake” wipes out manual uploads, version clashes, and the back-and-forth of static files. It’s instant, accurate, and keeps every user working from the same source of truth. So, what’s the best way to build that link?

Integrating with Floor Plans

This section will focus on the integration with floor plans as it is the bigger challenge (pulling data from Archilogic into a 3rd party app has much fewer UI hurdles).

There are two main ways of getting integrations up and running:

1. Archilogic’s floor plan SDK
2. A standard format export (available via API)

Without going into technical detail, we’ll outline the pros and cons of both approaches below.

Archilogic’s Floor Plan SDK

Our Floor Plan SDK sits in the same end-to-end stack we use to build Archilogic’s own products. Years of development and learning have shaped SpaceGraph, Editor, and our developer tools into a cohesive system. Because we depend on the SDK every day, it benefits from constant real-world testing and iterative improvement.

Why use it?

• Launch rich floor-plan UX in days instead of months
• Plans refresh automatically whenever the source changes—no file juggling
• Build on the same battle-tested and performant engine our own apps rely on every day

‍

Trade-offs

• The SDK replaces your current floor-plan canvas, so some UI refactoring is inevitable
• Source plans must live on Archilogic—either in your tenant or in your customers’ accounts. This means that all of your customers’ floor plans need to run on Archilogic and no longer on 3rd party systems. This has commercial implications - more on this in the GTM section below.

If those constraints fit your architecture, the payoff is a native-feeling plan experience delivered with a handful of lines of code.

(Almost) Standard Formats

Plenty of platforms already display floor plans in common formats such as GeoJSON, SVG, IMDF, or their own twist on those standards. Archilogic can export to virtually all of them - manually or through the API. Because our data is fully standardized, we can generate a custom export that drops straight into an integrator’s existing workflow.

Advantages

• Little to no new product work.
• Vendor independence: if some customers prefer a different floor-plan solution, just publish the spec and let each vendor conform to it.
• Future-proof: should your preferred format change later, Archilogic can regenerate exports automatically - no redraw or re-upload of plans required.

‍

Drawback

• Out-of-the-box standards often need extra tailoring on the integrator’s side to achieve the desired UX - work that sits outside Archilogic.

Go-to-Market

Archilogic’s pricing philosophy is to charge where we create value, and that’s typically with the users of commercial space. We charge for digital square footage / meterage as that happens to be the metric that’s most closely aligned with value creation. In effect, the license follows data residency: whoever owns the floor plans also holds the license.

In this model, integrations can take several different commercial paths, depending on who controls the plans and who initiates the connection.

The End-User of Space wants an Integration

This is the plain vanilla scenario. The user of space is using Archilogic as the system of record for floor plans and spatial building data. Integrations either exist already (for example ServiceNow or Microsoft Places), or the customer is using other systems they’d like to connect to. In that case, we talk to those companies and start working on the relevant plugins/exporters. The integrator isn’t charged for anything by anyone, and our customer has an independent commercial relationship with the integrator. And, as mentioned above, we ensure that Archilogic customizes its output to fit seamlessly into the integrator’s existing data pipeline.

The Integrator is looking for a new way to deal with Floor Plans

In this scenario, we’re not contacted by the user of space, but by the integrator. They typically require a combination of three things:

• a way to make it easier to onboard floor plans into their application
• a way to upgrade product UX as it relates to floor plans
• access to spatial building data to build new features

Archilogic can help with all of them. However, we strongly believe that eventually the user of space is the right persona to be managing their own floor plans. So how do we square the circle?

In this scenario, it tends to be difficult to layer an entire SaaS subscription that’s driven by square footage on top of the vendor’s existing cost structure. As such, our approach is to sell the integrator a license that lets them solve their minimum requirements at a cost that’s ideally fixed, or at minimum directly tied to incremental revenue that can be generated using Archilogic. The exact structure of a license is custom for each relationship, and we are flexible. This is not because we feel charitable, but because we’d like to ensure that the integrator is incentivised to eventually take us to their clients and say “you might want to check out Archilogic, it works seamlessly with our solution and is a great system of record for floor plans.” If and when that happens 1) the commercial relationship for square footage is now between the user of space and Archilogic, 2) the management of floor plans moves away from the integrator as the data is transferred to the user of space, 3) the integration just continues working, and 4) the integrator gets paid a referral fee. As an added bonus, any other Archilogic customer is now an opportunity for the integrator because the systems already work together.

Summary

Managing floor plans and spatial building data in a true System of Record changes the game for commercial users of space. It opens up seamless integrations with 3rd party systems and brings buildings as an asset class into the enterprise data stack (ready for AI too).

Integrators benefit because a slew of manual processes disappear while the product experience improves. Please don’t hesitate to contact us if you’d like to discuss setting up an integration - we’d welcome to hear your thoughts and feedback.

‍