Glossary

A customer's account — the container for everything they own in Ferry.

A workspace owns imports, connections, destinations, widgets, API keys, and team members. Every Ferry user belongs to exactly one workspace.

One end-to-end data transfer — from a source, through the Stage, into a destination.

Imports are the central unit of work in Ferry. Whether started by uploading a file, pulling from a connection, or generating mock data, every transfer is an Import. “Job” is the legacy term in the codebase — we're consolidating on Import in the UI.

The three-panel workspace where you prep, review, and approve an Import before it ships.

The Studio has a Sources panel (where data comes from), a Stage (the editable table in the middle), and a Destinations panel (where it heads next). Multiple teammates can open the same Studio and collaborate live.

One execution of an Import. An Import can be re-run after edits.

Each run records a webhook delivery transcript, error counts, and how long it took. Reviewing past runs is the audit trail for a customer.

The interactive table at the heart of the Studio — where every cell can be reviewed, edited, and validated before it's imported.

The Stage is best-in-class on purpose: virtualised rows, multi-select, drag-to-reorder columns, find/replace, and an AI command bar that can rewrite columns or filter rows by description. Nothing leaves Ferry until the Stage is approved.

The column-by-column relationship between source data and the destination schema.

Ferry suggests a mapping automatically using column name heuristics and value patterns; you confirm or correct it on the Stage. Each cell shows a confidence badge.

The typed shape destination data must match.

Customers define schemas via the API or the Destinations panel. The Stage validates every cell against the schema and surfaces errors inline.

Where data for an Import comes from.

Sources can be uploaded files, saved Connections to external systems, or AI-generated mock data. Every Import has at least one Source.

Saved credentials and configuration for a specific source system.

A Connection is what lets Ferry pull data from Mindbody, Pike13, GloFox, etc. It belongs to a Workspace and can be reused across many Imports.

A catalog entry that defines how Ferry talks to a specific source system. “Adapter” is the internal term for the same thing.

Connectors describe the credential fields, supported data types, and a preview/test routine. Adding a new source system means writing a new Connector.

AI-generated test data that acts as a fake source for testing Imports.

Describe the data you want (“200 yoga members from MindBody”) and Ferry produces a realistic synthetic dataset. Great for building widgets, demoing to customers, or stress-testing a destination.

Where an approved Import is heading.

A destination is the combination of a target schema and a delivery channel (usually a Webhook). Many Imports can share one Destination.

The HTTP endpoint Ferry POSTs to with batches of imported records.

Every batch is HMAC-signed and includes idempotency headers. Retries are automatic with exponential backoff. Webhook responses are visible per-run.

A chunk of records delivered to a webhook in a single request.

Batch size defaults to 250 records and is configurable per destination. Each batch carries a unique batch ID for safe retries.

A secret that authenticates programmatic calls to the Ferry API.

API Keys belong to a Workspace and are hashed at rest. Customers create them in /dashboard/keys; they're shown once.

The internal cockpit at /backstage. Ferry team only — not for customers.

Backstage is where we monitor every customer, every import, every webhook delivery, every email send. It also houses the University and Glossary.

An embeddable UI component customers drop into their own app to add Ferry to it.

Widgets ship for React, Svelte, Vue, vanilla JS, and as an iframe. The full library lives at /dashboard/widgets with copy-paste install snippets.

The public, no-auth, ephemeral Import Studio at /sandbox for trying Ferry without signing up.

Sessions live 24 hours, then everything is wiped. The Sandbox runs the real product UI with a pre-seeded Mock Source — there's no separate “demo” mode.