At the moment, we do not yet offer the functionality to export collections but this is something we are planning to implement with a future iteration of the feature.
Not sure if I’m understanding correctly which collection Ids you want to retrieve, but if you export a Report or Dashboard definition, the collectionId that these entities are in is stored in the collectionId field of the definitions. There’s currently no public API to retrieve all existing collectionIDs.
The second import will add a second report with the same configuration as currently Optimize has no way of identifying duplicate entities during separate import attempts, this is also an area we are considering improving with future feature iterations.
However, at the moment Optimize can identify duplicates within the same import batch, so if possible in this scenario I would recommend merging both exported entity lists so you can import just one batch of entities which will avoid duplicates.
Hope that answers your questions! Let me know if anything isn’t clear.
From the REST API documentation, the collectionId is a required field to get the dashboard/report IDs. Is there a way to retrieve all the dashboard/report IDs without using the collection IDs (since currently there isn’t a way to retrieve the collection IDs)? and what about the reports/dashboards not belonging to a collection? I tried “null, ‘%00’, an empty value” but the API always returns an empty list.
Lastly, Is there any time estimate for the collections API or is it not planned in a specific release yet?
Currently there’s no way to retrieve Dashboard or Report IDs without collectionId, the use case this was modelled for is that users have a specific collection they keep Dashboards/Reports in which are to be moved to a different Optimize instance, so it is assumed that you already know your collectionId and that private entities (those without collectionId) are not subject to this kind of bulk export/import use case.
I don’t think we have any plans to make the collectionId optional for the get ID APIs (to retrieve all dashboard/report Ids regardless of where they are stored), but you raise a good point and I can see how that could be useful - if you have a license, I would recommend you create a feature request for this. On first view it looks like this would be faster to implement than the collection export/import feature itself, so there would be potential that we could implement this change sooner rather than later.
As a workaround for now, you could consider retrieving all report/dashboard Ids from Elasticsearch directly instead by querying the report and dashboard indices.
I dont have an estimate for this, but you can check on the ticket progress here. Its currently marked as “potential for 3.8”, but I personally think it’s quite unlikely to be included in 3.8 given how many other features we are still working on first (I could be wrong, this is just my personal estimate).