Workspace backup via the API

Ideas & Features
1

Hi! We’d like to share what we ended up with and ask about a couple of things :grinning_face: .

The goal was simple: we wanted to be confident that if anything ever happens with Fibery, our data stays with us. (Corporate requirements :upside_down_face: ) 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 :shaking_face: .

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 :+1: .

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 :upside_down_face: 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 :grinning_face: .

If any of this is already on the roadmap, we’d love to hear about it :star_struck: !

Thank you very much for Fibery! :heart_eyes:

2

Hello,

Have you tried the Export your data? Did you run into any issues with it?

you can’t set your own fibery/id when creating an entity

You can, actually, could you please share the error you received?

3

Thanks for the pointer — we checked, and you’re right, fibery/id can be set on creation. :heart_eyes: That lets us do the restore in a single pass: the references between entities stay valid straight from the dump, so there’s nothing to re-map afterwards.

Built-in export — we knew about it and looked at it, but it didn’t fit us.:upside_down_face: It has to be started by a person, and we want a snapshot almost every day with nobody involved. And the format is meant to be read by a human, not loaded back in. Going through the API gives us both at once.

What we ended up building.

A nightly export that runs on a schedule. It pulls the schema and all entities through the API, splits them into files, and drops them into Google Drive — one folder per date. A run report is written alongside: for every database, how many entities were expected and how many actually made it, so an incomplete snapshot is visible right away.

Then we checked the part that actually matters — whether any of this can be restored. We took a clean workspace and rebuilt a slice of it there: spaces, databases, all fields, single-selects with their values, relations, formulas. Then we loaded entities into it with their original ids.

Everything we tested came back: ids, creation dates, references between entities, statuses, multi-selects, and rich text.

What won’t come back, as expected: files (the dump only holds links and checksums), whiteboards, views and reports, permissions, and change history. Public ids start over too, so external links to entities stop working after a restore. Users have to be invited again.

The main outcome for us is that the backup is no longer just sitting there — it’s been tested for reversibility. We know what comes out of it and what we’d have to rebuild by hand :melting_face: .

4

And separately — what the ideal solution would look like from where we sit :shaking_face: .

There are two things missing today.

First, scheduled exports to our own storage. Being able to point Fibery at S3, Google Drive, or just a webhook in the settings, pick how often, and have it run with nobody involved.

Second, and this one matters more — restoring from such a copy into a new workspace, as of a date. Not merging into something that already exists, not importing on top, not mapping fields by hand. Just “take the folder from September 15th and unfold it into an empty workspace exactly as everything was at that moment.”

With all of it: databases, fields, single-selects, relations, formulas, automations, views, whiteboards, documents, attached files, and permissions. Keeping ids and public ids intact, so external links keep working.

We understand this isn’t a small ask. But framed this way — “unfold a snapshot of a given date into a clean workspace” — it closes the scenario completely for companies where management is worried about this situations :smiley: