Getting Started

The core idea

A workflow is a named container for one or more routes. Each route pairs a trigger — what starts it: an incoming API call, a webhook, a schedule, a GraphQL query, or a file event — with an ordered sequence of steps. Each step is a connector action: a call to a third-party API, a piece of internal logic, or a branch/transform. A step's output can be referenced by later steps in the same route.

That's the whole model. Everything else — connections, variables, execution settings, caching, locking — exists to configure one of those three things (workflow, route, step) more precisely.

Building your first workflow

1. Create a workflow — give it a name, a slug (auto-generated from the name, but editable), and a description.
2. Add a route — pick a trigger (an API Endpoint trigger is the simplest to test immediately, since it just gives you a URL to call) and decide whether the route is public (no auth) or private (requires an API key or JWT).
3. Add a step — choose a connector and one of its actions. Each connector's own doc page lists every action's exact parameters and how to read its response.
4. Name the step — see Step Name for how a step's display name becomes the camelCase reference (e.g. "Get Product" → getProduct) later steps use to read its output — see Step Reference for the {{<stepReference>.x.y}} syntax that does that.
5. Test it — every route gets a Tests tab; a test execution never counts against rate limits.
6. Publish — snapshots the workflow into a new version, then deploy that version to an environment (defaulting to the store's default environment if none is specified) to make the route reachable at its real endpoint and turn on rate limiting (if enabled on the workflow).

The AI Assistant inside the workflow builder can also build and edit routes/steps for you from a plain-language description, if you'd rather describe what you want than assemble it step by step.

Where to go next

• Workflows, Routes, Connections, and Variables — the four building blocks, explained in full.
• Triggers — every trigger type (API Endpoint, GraphQL, Webhook, Schedule, File Event) and its own configuration.
• Step Name and Step Reference — how steps are named and how to read one step's output from another.
• Execution Settings, Caching, and Locking — the optional per-step behaviors most connector actions expose.
• Publishing — what happens when you publish a workflow, and how versioning works.
• Environments — deployment targets like Production and Staging, and how a request picks one.
• If you installed Younifyd from an app marketplace, its own install guide covers what was set up for you automatically — check the Guides section for yours.