Hello Psuresh, I am reviewing your question now and will have a response soon.
Unfortunately, I can’t find a deterministic way to connect them either. Our Data APis are considered “legacy” products that are not being actively updated as changes are made. The “id” they take is actually an auto-incrementing ID which effectively just points at the actual id of the collection. The content endpoint provides that actual value.
Remaking the Data endpoints to fit our modern APIs is a feature that has been requested before, and I put in a new request to consider it for prioritization. However, it is not currently on our roadmap.
Unfortunately, I can’t find a deterministic way to connect them either. Our Data APis are considered “legacy” products that are not being actively updated as changes are made. The “id” they take is actually an auto-incrementing ID which effectively just points at the actual id of the collection. The content endpoint provides that actual value.
Remaking the Data endpoints to fit our modern APIs is a feature that has been requested before, and I put in a new request to consider it for prioritization. However, it is not currently on our roadmap.
Hi Michael, thanks for your response… it would have been great if we can get a work around/ patch release from product team to solve this mapping between Lucid Chart API and Data API.
I looked to see if there was a reasonably small path to add both IDs to the `/content` endpoint, but unfortunately there is not. There are good reasons we moved away from the ID field, which doesn’t scale to the complexity of data that we have today. With a relatively simple example, it is 1:1 but more complex documents can’t deterministically make that connection.