Is there any way through GraphQL Api to update/add a parameter to objects

i want to update/add parameters like area/height using javascript, so is it possible to do so by GraphQl api

Hey @Webiers ,

This is not possible via GraphQL, what you can do instead is create a new Commit (or Version in the new UI) that has the updated metadata.

Please keep in mind that an object’s hash (its id) will need to be recomputed if any of its properties are modified.

I want to do something how excel plugin works using javascript
can you please share any example/guide to create new commit using api’s and update metadata

We could do better at tutorials from JS but fortunately in the meantime all our code is opensource including the excel connector

When you hit a roadblock we’ll try I help again.

1 Like

Technically wouldn’t it be possible to just POST /objects/[streamId] with the object keeping the same id and it would edit the values in place?

I’m not sure if that’s allowed, @gjedlicska should be able to confirm.
Nevertheless, that would not be the “right” way to do it, in Speckle you should rather create a new version (aka commit) of your model (aka branch) instead, that way you’ll preserve the model history etc.

Similar convo here: Modifying Parameters outside host applications with Speckle - #14 by bfortunato


Hey @Webiers and @sanchez

We don’t support changing object properties in our graphlq api. Objects are a part of our Core data model, which has its own set of concepts. You can read more about it in our dev guides here The Base Object | Speckle Docs.

In the same vein, while technically it should be possible to overwrite an object with a specific id after changing its properties, it renders almost all of the benefits of our object model and the decomposition API.

It can even backfire in weird ways IE. on receive our SDKs do a diff receive.
What that means is, on receive, clients tell the server which objects they have in their local cache, so that the server only sends the bare minimum data. We use the objectId (which is a result of a hash function of the objects properties) to do the receive diffing.
If client has the object locally with the unchanged value, but someone else changed the property of the object overwriting the existing record with the same id, the client will not receive the changes.

For these reasons, its highly recommended to not mess with the objects without our SDKs.

If you could describe your usecase @Webiers I could try to help you coming up with a direction that is solving your needs.

1 Like

@jonathon Is the excel connector’s BaseObjectSerializer able to serialize any Speckle object?

For example, if I wanted to create a Collection or a Rhino Block Definition/Instance, would I be able to serialize those?

Happy to start a new post with what I’m trying to accomplish, but that’s basically what I’m trying to do: create Collections, Rhino Block Definitions and Instances from Mesh/Breps objects already in a given stream.

Understood, I don’t think there’s a need for a separate post. Unfortunately this is not something I would try to do with the excel connector - it’s not meant for this workflow.

That aside, we’d still be interested to hear the why behind your request!

We’re working on a service that ingests STEP files from Catia and commits them to a model on our Speckle server. The service is running in Node and written in Typescript, so I was hoping to write the commit workflow in the same service.

Each of the STEP files is a Part, which is placed into an Assembly by instantiating the Brep from the STEP file wherever the Part is used and applying the transform to it. I’ve been able to manipulate the transform on a Rhino Block Instance, so it seemed like the path of least resistance to just create a Rhino Block Definition which references the Part’s Brep and then create individual Block Instances with the appropriate transform for each instance in an Assembly, put it all in a Collection and commit.


So, the real question is how complete the feature is in Excel’s BaseObjectSerializer relative to the other SDKs that will handle all defined objects.

Nominally, if the objects you are defining meet the contract defined in C# Objects Kit, then to my knowledge, nothing peculiar about them is different from object to object. I haven’t checked support for detachment and chunking in the proto-SDK wrapped in Excel. I’ll check with @connor to see if he can bring that to light.

I copy-pasta’d the BaseObjectSerializer and ServerTransport from the Excel connector and they work beautifully for most of what I’ve tried. However, when I tried creating a Collection (and BlockInstance/BlockDefinition) it didn’t generate the __closure. Hopefully that’s just because of how I’m trying to compose the collection (sample below), but I am sympathetic to the general point that Collections, BlockInstances and BlockDefinitions are not things the Excel connector generates so its serializer isn’t meant to handle them.

const message = 'Created a collection';

  const collection = {
    name: 'My Ideal Collection',
    elements: [
        referencedId: '<ID_OF_EXISTING_BLOCK_INSTANCE>',
        speckle_type: 'reference',
        speckle_type: 'reference',
    speckle_type: 'Speckle.Core.Models.Collection',
    collectionType: 'optimistic collection',

  const serverTransport = new ServerTransport(serverUrl, token, streamId);
  const serializer = new BaseObjectSerializer([serverTransport]);
  const serializedCollection = await serializer.SerializeBase(collection);

  await serverTransport.CreateCommit("My AOSM Branch",, message);

This may be feature incomplete then. We have looked recently to enhance what we have with JS to enable more Automate workflows, intending to begin with data reads, perhaps then we should be more expansive for Serializer + Deserializer

1 Like