Your Creator app has four exits. Most teams use one.

The thing people get wrong

A Creator app is two assets stacked on each other: the structure you designed, forms, reports, pages, workflows, Deluge, and the data your team has poured into it since. They live in different places and come out through different doors. Back up one and you've backed up half your app.

Attachments are a third thing, and the messiest of the three. More on that in a minute.

Layer 1: application backup

Manage → Operations → Backup, then +New Backup. Pick the app, a frequency, and which components to include. That last choice is the one people click past:

• Schema Only: the app, no data
• Schema + Data: structure plus records
• Schema + Data + Files: everything, attachments included

Backups come out as a ZIP. Individual files cap at 256 MB and split beyond that. Downloads sit behind the three-dot menu on the backup row. Every backup obeys the retention window in Delete Backup After, so pull anything you want to keep permanently down to your own storage. Available on all paid plans.

Then attachments, where the docs get strange. Zoho’s operations docs say Creator won’t back up files in the image, file-upload, audio, video and signature fields. A few lines later they say file backup only applies to immediate backups, when you choose Now as the frequency, and that other frequencies can’t back up files. Those two statements don’t agree. My read: recurring backups are solid for schema and data, a manual Schema + Data + Files run is your best shot at attachments, and if uploaded files matter to your business, open the ZIP and check before you trust it.

Two smaller things. Backup targets Production, which is almost always what you want. And a restored app comes back without its previous sharing settings or published components, so budget a few minutes to re-share it. Better to know that now than at 2am.

Layer 2: the DS file

The most underused feature in Creator. Every developer I’ve shown it to has the same reaction.

In the Application IDE (Settings, in your app’s edit mode), click Export. You get a Deluge Script (.ds) file holding the complete schema of the app in Deluge format: every form and field setting, every report layout, every page, every function, schedule and custom script you’ve written.

It round-trips. Import a DS file into any Creator account and you get an identical copy of the application. Spinning up a clean copy of your app becomes a file upload.

It’s also plain text. Creator has no native Git integration, but a DS file drops straight into your repo. Commit it after each significant release and you’ve got a diffable history of your application logic, reviewable in pull requests like any other code. Worth the two minutes on its own.

What it doesn’t hold: records, and image files used in pages and print templates. Export is also blocked outright if any report in the app displays 150 or more fields.

Layer 3: report exports

For the “send me the Q3 orders” request, export straight from the report. Hamburger icon, top right, Export. The user’s profile needs export permissions enabled or the option won’t show.

Formats are XLSX, PDF, HTML, XML, JSON, CSV and TSV (XLSX replaced XLS in March 2024). You get real control on the way out: pick columns explicitly, export Quick View or Detail View field sets, split subforms into separate columns or their own sheet, password-protect anything sensitive.

Limits worth memorising: HTML stops at 50,000 records, PDF at 12 MB, XLSX at 150 MB of raw data (70 MB for newer accounts).

Layer 4: the Bulk Read API

For the hands-off nightly job, Zoho points straight at the Bulk API. It exists to back up your data without hammering your API limits. It’s asynchronous: create a job, poll it, download the result.

curl "https://www.zohoapis.com/creator/v2.1/bulk/jason18/zylker-store/report/All_Orders/read" \
  -X POST \
  -H "Authorization: Zoho-oauthtoken 1000.8cb99dxxxxxxxxxxxxx9be93" \
  -H "Content-Type: application/json" \
  -d '{"query": {"fields": ["Customer_Name","Amount","Status","Added_Time"], "max_records": 200000}}'

Poll the same path plus the returned job id until status reads Completed, then hit that path plus /result for a ZIP with your CSV.

Then follow the cursor. max_records is the batch size, not the total. When records remain, the download response returns a recordCursor header you pass back for the next batch. It expires after 15 minutes, so loop straight through instead of sleeping between batches. The value has a minimum and default of 100,000, a maximum of 200,000, and must be a multiple of 1,000.

Scopes are ZohoCreator.bulk.CREATE and ZohoCreator.bulk.READ. Swap zohoapis.com for your region’s base URL (.eu, .in, .com.au, .ca, .jp, .sa, .ae, .com.cn). Results stay downloadable for 24 hours, so fetch the ZIP in the same run that created the job.

One architectural note: drive this from an external scheduler, cron, a Lambda, Zoho Catalyst, whatever you already run, not a scheduled Deluge function. Deluge caps at 5,000 statements per function and counts looped statements per iteration. That makes it fine for small incremental pushes, yesterday’s new records via a criteria filter, uploaded with zoho.workdrive.uploadFile, and wrong for the full set.

The routine

One clarification that saves people a lot of time: environments are a release safety feature, not a backup. Zoho is explicit that data can’t be transferred during publishing or accessed from other environments. Your Development copy holds none of Production’s records, by design. Use environments to ship safely and the four layers above to protect data.

If you only do one thing this week, do the DS file. Ninety seconds, and it’s the half of your app you can’t rebuild from a CSV.