Hi! We’d like to share what we ended up with and ask about a couple of things 
.
The goal was simple: we wanted to be confident that if anything ever happens with Fibery, our data stays with us. (Corporate requirements 
) We couldn’t find a built-in way to export a whole workspace, so we wrote our own nightly dump via the API.
The good part
We pull the schema, entity data, automation rules and users. Rough numbers: around eighty plus databases, fifty-seven thousand entities, a hundred megabytes per run. Plus a reconciliation step — expected count against written count — because without it an incomplete copy looks exactly like a complete one. And we’re growing fast 
.
A big thank for the /api/automations/auto-rules/for-type/{id} tip from Chris — without it the automations wouldn’t have made it into the dump. That said, it would feel safer if that endpoint were official 
.
A few things short of ideal
Three things we couldn’t get:
- whiteboards — they read beautifully through MCP, but there’s no way to reach them with a regular token
- Custom App sources — the dev token is only issued through MCP and lives about an hour
- validation rules — not exposed through the API or MCP
If there’s a way to get at these and we simply missed it, please tell us — we’d be glad to be wrong.
Honestly, everything we did was an attempt to get a workspace export that doesn’t exist but maybe it will be helpful if you develop one button or one API call out of the box: schema, data, automations, whiteboards, apps?
We suspect we’re not the first to go down this road. And it wouldn’t only help with backups — workspace migrations, audits and external analytics all run into exactly the same wall.
We tested the reverse direction too, and this is where it gets interesting: you can’t set your own fibery/id when creating an entity.
That makes any restore a two-pass process. First you create every entity and record which old id became which new one, then you go back over everything and wire up the relations.
If fibery/id could be specified on creation — even only in some import mode, even only into an empty workspace — restoring would become straightforward: load it as-is and the relations line up by themselves.
Same story with users: they can only be created by inviting them through the UI, which means every relation pointing at a person has to be rebuilt by hand, matching on email. We understand why it works that way, but it hurts for restores .
If any of this is already on the roadmap, we’d love to hear about it 
!
Thank you very much for Fibery! 