How to export your data from Tines before a renewal or exit
Before a renewal, a pricing change, a residency review or a move off Tines, you need to know exactly what leaves the platform. Stories can be exported as story files from the Tines UI or through the API, but a story file omits run history, so event data has to be pulled separately through the events API. Treat the export as two jobs: a complete inventory of stories and their configuration, and a separate record of what those stories actually did.
The story export is a JSON file that carries the story metadata, agent configurations, the links between agents and the diagram layout. The API route is GET /api/v1/stories/{story_id}/export, which also takes optional parameters to randomize URLs, clear recipients or export a specific draft. Clearing recipients and randomizing URLs are decisions to make deliberately: the first removes contact details from a file you may share with a new platform, and the second changes values that other systems may depend on. Check the Tines importing and exporting stories guide for what each option changes before you run a bulk export.
The events API, GET /api/v1/events, returns 20 events per page by default and at most 500, filters by time range, story or team, and returns a 422 error when a response exceeds 200MB. A long retention window therefore means many filtered, paged requests, so script the pull by story and by date range and write each page to storage as you go. Confirm with Tines how far back event history is available in your plan and whether your contract requires you to keep it, because the API will not return what the platform no longer holds. Record the export date, the story count and the event totals per window so you can prove completeness later.
What Tines documents as exportable, and how
This table lists only the export paths Tines documents: story files from the UI or API, and event history from the events API. Use it to see what each path returns, which limits apply and where each limit is stated, then plan your pulls around those limits.
| Export path | What it returns | Documented limits or options |
|---|---|---|
| Story file via UI | A story file for the selected story, downloadable from the story's export option | Story files exclude event data (Tines importing and exporting docs); confirm the current menu path in your edition |
| Story file via API (GET /api/v1/stories/{story_id}/export) | JSON story file with metadata, agent configurations, links between agents and diagram layout | Optional parameters randomize URLs, clear recipients or export a specific draft (Tines API: Export a story) |
| Story file contents | Structure needed to rebuild a story: agents, their settings and how they connect | Does not contain event data, so run history must be pulled separately (Tines docs) |
| Events via API (GET /api/v1/events) | Event history for run and action outputs | Returns 20 events per page by default and at most 500 (Tines API: List events) |
| Event filters | Narrows event pulls by time range, story or team | Filters for time range, story and team (Tines API: List events) |
| Oversized event responses | Response fails when the payload is too large | Returns a 422 error if the response payload exceeds 200MB (Tines API: List events); page in smaller windows |
| Secrets and credentials | Not listed as part of the documented story file contents | Confirm with Tines how stored credentials and connection secrets are handled before relying on a file as a full backup |
What a Tines story file leaves out and how to capture it
A story file captures the design of a workflow, not the operating state around it. The cards below list what sits outside the file, what to confirm with Tines before you rely on that assumption, and a practical way to capture each item before you migrate or leave the platform.
Run history and event data
The story file does not contain event data, so every past run, payload and error must be pulled separately through the events API. Plan this as its own export job. Filter by story and time range, page through results, and store each window as it is retrieved so a later failure does not lose earlier pages. Confirm with Tines which retention applies to events in your plan before you decide how far back to go.
Credentials and connection settings
Credentials, API keys and connection configuration are the items most likely to be absent from a story file, and they must never be copied into a repository in clear text. Inventory every connection each story uses, record which service and account it points to, and note who owns the secret. Confirm with Tines how credentials are represented in an export before assuming any value travels with the file. Re-issue secrets in the target platform rather than moving them.
Schedules and trigger details
Schedules and webhook endpoints live in the running environment, and a story file may describe the agent that triggers a flow without confirming the live cron timing or the URL external systems call. Record each schedule, its timezone and its frequency from the Tines interface, along with the webhook paths that upstream tools post to. Confirm with Tines what the export includes for these agents, and keep a list of every system that sends events in.
Recipients, notifications and sharing
Export options can clear recipients, so the file may not show who receives alerts, approvals or case notifications. Write down each recipient group, channel and escalation path from the live stories, and confirm with your own team who is responsible for each one. This is the list most often lost in a migration, and a missed notification can stay silent until an incident needs it.
Drafts, versions and unpublished changes
A story export can target a specific draft, so the version you export is not always the version running in production. Compare the exported file with the live story, identify any unpublished edits, and export each draft you still need. Record the story version and the date of export with the file so the evidence trail stays clear.
Undocumented behavior and local knowledge
Some behavior exists only in the experience of the people who run the stories, such as manual steps, shared scripts, exceptions for specific alerts or workarounds for a vendor's rate limits. Interview the owners of each story, review recent incidents for manual interventions, and list every behavior the documentation does not describe. Treat each item as unverified until you have confirmed it against the running story and tested it in the target platform.
The sequence for a complete Tines export
This sequence turns a Tines tenant into a dated, checksummed archive of story files and event history that you can verify before any migration or renewal decision. Each step produces an artifact you can re-open and count, so the export is provable rather than assumed.
Freeze the story and team inventory
Before exporting anything, list every story and team you need to keep, using the Tines UI or the stories listing in the API. Record each story ID, name, team and status in a manifest file, and note which stories are live. Freezing the list first means later edits or new stories do not silently change what you think you exported. Done means you have a complete inventory file with one row per story and a count you can cite.
Export each story file
For each story in the inventory, download its story file from the UI, or call GET /api/v1/stories/{story_id}/export through the API with a token that has access to that story. Use the API when you need repeatable runs, and choose the draft export option when a story has unpublished changes you want to keep. Save each file under a name that includes the story ID. Done means every inventory row has a matching JSON file and none are missing.
Define the event query windows
Decide the time range you need for run history and split it into windows small enough that each response stays well under the payload limit. The events API returns 20 events per page by default and at most 500, filters by time range, story or team, and returns a 422 error when the response exceeds 200MB. Record each window's start, end and story or team filter in the manifest so the query is reproducible. Done means every window and filter is written down before the first events request.
Pull events page by page
Request GET /api/v1/events for each window and story or team filter, following the paging until no further pages are returned. Paging must cover the full time window: stopping at the first page or at a visible count silently drops history. If a response returns a 422 error, shrink the time window and retry rather than accepting a partial file. Save each page as its own JSON file, keeping the query parameters beside it. Done means each window ends on an empty next page.
Store files with checksums and a manifest
Write every story file and events page into a single archive directory with a consistent folder layout. Generate a checksum for each file, such as SHA-256, and store them in a checksum file. Update the manifest with file names, checksums, query parameters, page counts and export timestamps. Keep the archive on storage your organization controls and restrict access to it, because story files and events can contain sensitive operational detail. Done means the archive opens without the export tooling and every file has a recorded checksum.
Verify by re-opening and counting
Re-open each story file and confirm it parses as JSON and contains the expected story name and agent entries. Then recount the events from the saved pages and compare the total against the paged query: the number of events in the files should match what the query reported for that window and filter. Recompute checksums and compare them with the checksum file. Investigate any mismatch before you consider the archive complete. Done means every file passes parsing, every count matches and every checksum matches.
Record what the export does not contain
Add a short gaps section to the manifest. Story files do not contain event data, so run history lives only in the events files. Note any Tines features you could not export through these methods, along with credentials and connection secrets that a story file does not carry, so the next team knows what must be rebuilt or obtained from the source system. Confirm each gap with Tines documentation or your own tenant before you rely on the archive for migration. Done means a reviewer can see what the archive can and cannot restore.
Pulling event history without hitting the 200MB limit
Run history is the part of a Tines export that a story file will not give you, so it has to be pulled through GET /api/v1/events. The endpoint returns 20 events per page by default and at most 500 per page, and it returns a 422 error when the response payload exceeds 200MB. Your job is to pick time windows small enough that every page stays under that ceiling, then walk each window page by page until the results run out. Set the page size explicitly to 500 for speed, but expect that a page of large events can still breach the payload limit, so the window size matters more than the page size.
Narrow each request with the filters the endpoint supports: a time range, a story, or a team. Filtering by story is useful when a few high-volume workflows dominate the history, because you can export those stories on their own and keep the rest of the team's history in larger windows. Start with one small window, for example a single day for one story, and check three things before scaling up: the number of events returned, whether the paging parameters move you to new events without duplicates, and the size of the response body. Record the result in your migration log. The paging behavior and the size of your events depend on your own workflows and payloads, so confirm both in your environment against the Tines API documentation for listing events rather than relying on any general assumption.
If a request returns a 422, do not retry the same window. Split it in half by time, export each half as its own sequence of pages, and repeat the split only on the windows that still fail. Keep a record of each window's start and end, the number of events it returned, and any window that needed splitting, so that an auditor or a later re-run can verify completeness and spot gaps. Because the output is only as complete as your window boundaries, make the windows contiguous and check that the last event of one window is followed by the first event of the next. Plan for this as an operational task with a named owner, since large histories can require many requests.
What to plan before the Tines contract ends
Export is only one step in leaving Tines. The decisions below decide what you export, where it lands and whether you can still read it after the contract ends. Work through them before the renewal or termination date so the export is tested while Tines is still available.
Confirm the export inventory
List every story you need to keep, including drafts, stories that are live but rarely edited, and stories owned by teams that have since left. Each one needs its own story file export, so the inventory is the starting checklist. Mark which stories are only needed as reference and which must be rebuilt on another platform.
Set run history retention
Story files do not include event data, so run history must be pulled separately through the events API. Decide how far back you need run records for audits, incident reviews and troubleshooting, and export that window before access ends. Ask Tines how long event data stays available after your contract ends.
Choose where exports live
Pick a storage location for story JSON and event exports before the first pull, with access controls, encryption and a retention schedule that matches your records policy. Use the events API time filters to split large histories into files that stay under the response size limit. Record who can read them.
Plan the Free edition fallback
If the team downgrades instead of leaving, the Free edition keeps unlimited users, spaces and connectors but caps live workflows. Count your currently live stories against that limit and decide which ones must be switched off or consolidated. Confirm the current limits on the pricing page, since editions can change.
Schedule a test restore
Import a sample of exported stories into the platform that will receive them and confirm the structure, links between actions and diagram layout survive. Check that events you exported can be read back and matched to their stories. Do this while Tines is still running so gaps can be fixed.
Confirm notice and deletion dates
Ask Tines directly for the notice period for non-renewal, the date access to exports ends and when account data is deleted after termination. Get the answers in writing and build your export schedule backward from the earliest date. Do not rely on assumptions about deletion timing.
Questions teams ask before exporting data from Tines
How much effort does a full export from Tines take?
The effort depends on how many stories you have, how much event history you need, the time window you pull, and where the output will be stored. Story files are exported one story at a time through the API or the UI, so the work scales with story count. Event history is a separate pull with a default page of 20 events and a maximum of 500 per page, so high event volumes mean many more requests. Before you start, count your stories and estimate event volume for the window you need, then time a test export of a few stories to set your own baseline. Tines does not publish a per-story export duration in the sources we reviewed, so measure it in your own tenant.
Can our team export Tines data alone using the documented API?
Yes, a team with API experience can script the export using the documented endpoints. Story files come from GET /api/v1/stories/{story_id}/export, which returns a JSON file with metadata, agent configurations, links between agents and diagram layout. Event history comes from GET /api/v1/events, which filters by time range, story or team. Your engineers need to handle paging, the 422 error returned when a response exceeds 200MB, and retries. The UI export is simpler for a small number of stories. Confirm the current endpoint behavior and rate handling in the Tines API documentation before you build the script.
What does our team need to provide for a Tines export?
You need an API token with permission to read the stories and events you plan to export, storage with enough capacity for story files and event payloads, and named owners who can check each exported story. Story files do not contain event data, so plan storage for both. Owners should confirm that each story's purpose, connected services and recipients are still correct, because the export describes structure rather than a verified business record. Ask your Tines administrator which team and story scopes the token covers, and whether any stories are restricted to people who must approve their export.
Does exporting Tines stories affect workflows that are still running?
Exporting a story reads its definition and does not stop it, but you should confirm this in your own tenant before a large run. Story files include an option to export a specific draft, so teams with unpublished edits should decide which version is the reference. The export can also randomize URLs or clear recipients, which changes what you get back, so use those options deliberately and record which ones you used. Schedule heavy event pulls outside peak alert periods where possible, and keep live triggers unchanged until you have verified the exported copies.
What does a Tines story file leave out, and how do we get run history?
A Tines story file contains metadata, agent configurations, links between agents and diagram layout. It does not contain event data, so run history must be pulled separately through the events API. Credentials and secret values are not described as part of the story file in the sources reviewed, so confirm with Tines how stored credentials are handled before you assume a complete backup. Treat the story file as a definition for rebuilding workflows, and treat event exports as a separate record with its own retention and access rules.
How should we store and protect exported Tines data?
Store story files and event exports in a location you control, with access limited to the people who need them. Event payloads can contain sensitive alert, user or case data, so apply the same classification you use for source logs. Document who exported what, when, and with which filters, so an auditor or migration team can trace the set. Retention is your decision: set it based on your legal, contractual and operational needs rather than on the export format. Confirm with your compliance lead which regulations apply to the event history before you copy it to any new system.
Is outside help worth it for a full Tines export?
Outside help is worth considering when the export is large, the event history is high volume, or your team lacks time to script and verify it. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure, and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For Tines editions and hosting options, see the Tines pricing page, and ask any provider for a written scope that lists the stories, time window, storage target and verification steps.
Using exported stories as input for a Shuffle or Tracecat rebuild
Exported story files work best as the inventory and specification for a rebuild. Each file records the stories' metadata, agent configurations, the links between agents and the diagram layout, so you can count every workflow, read which actions call which systems and see how the branches connect before you touch a new platform. Use the GET /api/v1/stories/{story_id}/export call or the UI export to produce one file per story, store them under version control or in your change records, and treat that set as the baseline you will check the rebuild against. If a story has an unpublished draft that matters, confirm whether you need to export that draft specifically, since the API supports exporting a specific draft.
Story files do not carry credentials, secrets or event history. Saved connection details and API keys have to be recreated in the target platform by its owners, and the run history held in Tines is pulled separately through the events API, subject to its paging and payload limits. Before you start, ask the people who own each integration which accounts, service identities and tokens each story depends on, and record who can supply them. Confirm with Tines which export options apply to your edition by reading the Tines documentation on importing and exporting stories, since the exact behavior of the export parameters is the authority on what your files contain.
The rebuild itself is a separate project. Converting HTTP actions, webhooks, schedules and case handling into Shuffle or Tracecat is planned, tested and switched over one workflow at a time, and it has its own scope, owners and acceptance checks. The sibling pages on migrating to Shuffle and migrating to Tracecat cover those steps in detail. Plan for the export as the first deliverable of that project, and decide early which stories will move, which will retire and which need a different tool.
How DeployOpen scopes and delivers an export and exit
DeployOpen treats a Tines export as a fixed-scope engagement: we agree in writing which stories, drafts and event histories to pull, where the archive lives and how it is verified. The result is an inventory and archive you can use for a migration to Shuffle or any other platform, inside your own infrastructure.
How we scope
- Inventory every live and draft story in scope, with owners, teams and the trigger types each one uses.
- Agree whether exports cover story files only or also event history, and for which date range and stories.
- Record the data that story files omit, such as run history and credentials, and who will handle each gap.
How we build
- Script story file exports through the Tines API so each run is repeatable and logged, rather than relying on manual downloads.
- Pull event history page by page within the documented 500-event maximum and the 200MB payload limit, with retries for 422 responses.
- Store archives in your own storage with checksums, naming conventions and access controls agreed with your security team.
How we hand over
- Deliver the story file archive, event exports, an inventory spreadsheet and a short runbook for repeating the export.
- Document which fields were randomized or omitted by export options, so later reviewers know what the file does not show.
- Walk your team through the archive structure and confirm acceptance against the scope agreed at the start.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines confirmed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if you need help after handover.
- Ask for a written quote based on your story count, event history range and storage location, since DeployOpen does not publish prices.
