Customer-specific twin processors

Most integrations react to a twin after it has been built. A twin processor goes one step further: it runs inside the twin processing pipeline, so your own logic becomes part of how a twin is produced. This page is a brief overview — the capability exists and is delivered as a managed service, rather than something you wire up yourself from public packages.

The main advantage: a processor's output becomes part of the twin, so it is served to every consumer through the standard Twinfinity API and viewer — your apps, third-party integrations, and Twinfinity's own tools all see it automatically, with no per-consumer wiring. Compare that with an external function, where the data it derives is stranded in your own system and reachable only by whatever you connect to it.

What it is

A twin processor is a small, customer-specific module that Twinfinity runs automatically whenever a twin's content is (re)built. It receives the twin's processed model as input, runs your logic, and writes back additional data that is attached to that twin version. From that point on the data is just part of the twin — retrieved through the same API, and rendered in the same viewer, as everything else.

Typical uses:

Derive new data from the model — for example aggregating areas per space type, deriving counts, or computing custom metrics.
Map the model into a domain-specific schema your downstream systems expect.
Enrich products with computed properties that then show up alongside the model's own property sets.

How it works

A twin version is built ──► your processor runs ──► extra content is attached to that twin version
        (input: the twin's processed model + geometry)        (output: computed data / properties)
                                                                        │
                                                                        ▼
                                              served to ALL consumers via the standard Twinfinity API + viewer

Available to every consumer. Output is stored on the twin version and exposed through the twin's content API, so any client — your apps, other integrations, the Twinfinity viewer — reads it exactly like the model itself. Produce it once; everyone gets it.
Triggered by the pipeline. Each time a twin's content is produced, any processors registered for your tenant run against it — no manual step.
Sandboxed and bounded. Processors run in an isolated sandbox with strict time and resource limits, so custom logic can never affect the stability of the platform or other tenants.
Per twin version. A processor's output is tied to the exact twin version it ran on, so results stay consistent with the model they were derived from. Several processors can contribute to the same twin version independently.

How it compares to event-based integration

If you only need to react to changes and push data into one external system, event-based forwarding is the right tool and you can build it yourself. Reach for a twin processor when the derived data should live on the twin and be available to everyone through the standard API, rather than sitting in a single external system that each consumer would otherwise have to integrate with separately.

This is a managed, advanced capability. Twin processors are authored against an internal SDK and deployed per tenant by Twinfinity — they are not currently a self-service, publicly packaged feature. If you have a processing need that belongs inside the twin pipeline, talk to your Twinfinity contact about building and deploying a processor for your tenant.