Integration data access
Installing an extension does not grant its provider general access to merchant business objects. When an extension node needs an Ormuz object, access must come from explicit process context or an already-established mapping to a precise target. Both paths remain bounded by merchant, extension configuration, and the node contract using them.
Two paths, and nothing else
An integration can read or modify one of your business objects only in two situations:
Within a process, on an object you passed to it by wiring the process, or on an object type for which you explicitly authorized access.
Through an established mapping, to reread the exact Ormuz object associated with one of its own objects — for example the Ormuz order behind a Mondu order.
Inside a process, the object comes from explicit wiring or `platform_access` permission. Outside a process, a mapping lets the integration reread only its exact target.
An extension therefore never receives generic search capability across the business model. Execution context, permissions, and mappings each delimit a concrete, verifiable access.
Path 1 — inside a process
When you connect one node's output to an integration-node input, that wiring itself is your authorization: it is visible in the graph, you designed it, and the object is simply handed to the node. No additional permission is requested, and this is the case for most nodes.
Some nodes, however, need to read or modify an object without without that access appearing in their inputs and outputs — for example a node granting credit checks and updates company exposure in its own behavior. This access is opaque to you: it requires an explicit permission declared by the node in its platform_access contract and granted by you.
See Node permissions for the consent mechanism, scope, and revocation.
Path 2 — an established mapping
An integration works with its own provider-side objects. To durably link these objects to yours, Ormuz records object mappings : “this Mondu order corresponds to this Ormuz order.”
A mapping can then reread exactly the targeted Ormuz object — nothing else. This is what lets an inbound provider event directly expose your business object without the integration needing to search your data.
The essential point: a mapping never creates new access. It can be established only toward an object the integration already legitimately held through one of the two paths. It freezes an existing access; it does not open one.
Explicit object links
Object Links are not a third implicit access path. They are relationships created explicitly by a process between objects already available in its context. A relationship can connect two platform objects, a platform object and an extension object, or two extension objects.
Once the link exists, Core nodes can resolve the linked platform endpoint or, when the target extension object is declared retrievable by its extension, explicitly request that it be reloaded from the provider. This operation remains visible in the graph and never turns a simple identifier into a general access right.
Do not confuse this mechanism with an object mapping : a mapping expresses identity between a provider object and its Ormuz representative; a link expresses a functional relationship between two objects that remain distinct.
What is never possible
Regardless of granted permissions and recorded mappings, an integration cannot:
browse or search your data — there is no way for an integration to list your companies, invoices, or orders;
read an object from an external reference — receiving or guessing one of your object identifiers grants no right to read it;
walk from one object to related objects — access to a contact does not open access to its company, nor vice versa; each object requires its own authorization;
modify an object merely because it is associated — a mapping grants only reread access to its exact target; writing requires a write permission granted inside a process;
cross a merchant boundary — an object outside the configuration scope is treated as nonexistent, with no observable difference between “exists elsewhere” and “does not exist.”
Integrations receiving provider events — inbound webhooks or scheduled synchronization — are even more restricted: they execute outside any process, therefore have no process permission, cannot create mappings, and cannot modify business objects. They can only reread an already-established mapping and propose data to a process, which decides.
When authorization is checked
Authorization is not checked once at design time: it is revalidated up to the moment access actually occurs.
When saving the process — you cannot save a process using a node whose access has not been authorized.
Before every node execution — consent state is reevaluated on each pass.
At the moment of access — the platform rechecks that the node requesting the object is the one in the current process, that it declared this access, that permission is still granted, and that the object belongs to the correct scope.
Practical consequence: revoking a permission takes effect immediately, including for an already-running process. The next relevant access fails permanently and without automatic retry.
What you can control and observe
Public surfaces let you review permissions currently in force for a process (see Node permissions) and mappings recorded for an extension configuration (see Object mappings).
). If a node attempts access that is no longer authorized, the step fails and the error is visible on the instance. Revoking a permission therefore affects future access without erasing effects already produced or mappings legitimately created earlier.