> ## Documentation Index
> Fetch the complete documentation index at: https://docs.speckle.systems/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> These docs contain multiple Speckle product experiences. For Speckle 2026.9, prefer /next/ pages for the topics and changes they cover. The navigation label Current does not override this version-specific precedence.
> Coverage under /next/ is incremental. Use Current documentation for unchanged topics and when a /next/ page says coverage is unavailable or explicitly refers you to Current. Do not infer a feature was removed from a missing page.
> Read the page-specific documentation status, applicability, affected guidance and replacement links in agent-only content. Impacted, changed and superseded apply only to the stated scope; they do not mean the entire feature is deprecated. Historical connector guides apply only to the legacy connector described.
> Match guidance to the customer's deployment version, model data format and connector. Respect plan, permission and compatibility restrictions. If an unknown version or data format changes the answer, ask a focused clarification; do not infer deployment version from the date alone.
# Building applications on 2026.9
> Where to start if you build an app that reads Speckle data rather than a connector — viewer apps, data-only apps, and why there is no drop-in replacement for the object-graph loaders.
Documentation set: Speckle 2026.9. Status: current. Authority: canonical for this version and the coverage on this page.
Applies to version 2026.9, from 2026-09; this is not a rollout date for every deployment.
Authoritative Speckle 2026.9 documentation for the topic covered here. For Speckle 2026.9, prefer this page over conflicting earlier guidance. Follow the linked pages in the other documentation version for unchanged topics and where this page says coverage is not yet available. Respect data-format, deployment, plan, permission, and compatibility limitations stated in the page.
This is 2026.9 documentation. Coverage here is incremental: a page exists only where 2026.9
differs or is newly documented. For any other topic, switch to **Current** (2026.8 and earlier) in
the version selector.
This page is for people building an **application on top of Speckle data** — a dashboard, an
internal tool, a web app, a service that reacts to versions. Not a connector: you are not
publishing from a host application, you are reading what others published.
In 2026.9 a version's data is a [bundle](/next/developers/building-integrations) of parquet
files rather than an object graph, and that changes how your app gets at it. Which door you
take depends on whether you render.
You import `@speckle/viewer`. Bridge the bundle to the object shape the viewer converts, with
sample code you copy into your app.
You read properties, quantities or geometry without the viewer. Read the bundle directly — the
load mechanics are the same ones every non-SDK consumer uses.
Writing scripts with a Speckle SDK instead? The SDK applies every bundle rule for you. Start from
the [.NET](/next/developers/sdks/dotnet/breaking-changes) or
[Python](/next/developers/sdks/python/breaking-changes) 2026.9 pages.
## My app writes data
Publishing is the harder half. A 2026.9 version is a bundle built and uploaded through an
ingestion, and there is no published JavaScript bundle builder — `@speckle/objectsender`
writes object graphs, and .NET and Python are the only SDKs that build bundles today.
That leaves three honest options, in the order most teams should consider them:
| Option | When it fits |
| -------------------------------------- | -------------------------------------------------------------------------------- |
| Publish from .NET or Python instead | The writing half can move process or language |
| Implement the bundle contract yourself | You must stay in JavaScript, and can carry a parquet writer and the SGEO encoder |
| Ask for compatibility mode | You need time, and your consumers still read object graphs |
The wire sequence, the correctness rules and a build order are in [Publish a bundle from your
own code](/next/developers/building-integrations/publish). Read it before choosing the second
option: it is a real piece of work, and unlike the read path there is no worked sample.
## Why there is no drop-in object-graph loader
If your app is built on `@speckle/objectloader` or `@speckle/objectloader2`, the natural ask
is a version of those packages that reads bundles and hands you the same object graph —
`getRootObject()`, `__closure`, `getObjectIterator()`, unchanged. That is not coming, on
purpose.
Emulating that surface would mean rebuilding the object graph that 2026.9 retires: a third
implementation of the receive fidelity contract, kept in step with the .NET and Python SDKs
forever, reconstructing hashes and closures that no longer exist in the data. It would also
teach new apps a shape the platform is moving away from.
What to do instead depends on what you were using the graph for.
| What you used the object graph for | In 2026.9 |
| ---------------------------------- | ------------------------------------------------------------------------------------------- |
| Reading properties across objects | Read the eav tables. Objects are keyed by `applicationId`, properties by dotted path |
| Walking hierarchy | Read typed relations. Grouping is `IN_COLLECTION` and the scene view, not nested `elements` |
| Getting geometry to draw | Decode SGEO from the geometry shards, or bridge to the viewer |
| Object identity across versions | `applicationId`, not a content hash |
The mechanics for all four are in [Load a bundle in your own
code](/next/developers/building-integrations/load). That page is written for any non-SDK
consumer, which includes you — it is not connector-specific.
A loader that fetches `referencedObject` from the objects endpoints gets a 404 on every 2026.9
version. Dispatch on `Version.schemaVersion` before you fetch, and keep your existing reader for
the older shape.
## What stays the same
Your Speckle token, the GraphQL API for projects, models and versions, webhooks, permissions
and sharing are unchanged. So is the shape of the problem: list a version, fetch its data,
key your app's state to something stable. Only the fetch and the identity changed.