# API Integrator > Drag eighteen task types onto one canvas, chain them with output keys and JSON Path, fire them on a cron, on an HTTP endpoint, or from another flow — and let the same audit and identity stack as the gateway watch every step. *API Integrator · Task Flow Manager* ## Connect anything to anything. Without writing the integration. [Request a demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) **Highlights** - **Task types** — 18 on one canvas - **Triggers** — Cron · HTTP · Nested - **Schedule** — Quartz · timezone aware --- ## Capabilities ### 01 · From a blank canvas to a live task flow in six steps. The builder is a six-step wizard, not a feature-by-feature scavenger hunt. Name and describe the flow, drag tasks onto the canvas, decide if it should be a published HTTP endpoint, pin a cron, attach failure actions, and pick a log retention. Each step is small enough to review, and the canvas in the middle is the source of truth — reviewers read it, operators trust it. - Step 1 — Definition: name, description, environment - Step 2 — Tasks: drag-and-drop canvas, chained with output keys - Step 3 — Endpoint: publish as a REST endpoint protected by an API Key - Step 4 — Schedule: Quartz cron expression with timezone awareness - Step 5 — Failure Actions: page the oncall, log to SIEM, recover automatically - Step 6 — Retention: how long the execution log lives, by environment - Save at any step — pick up where you left off - Same wizard for a one-task flow as for a fifty-task flow **Concepts:** `Definition` · `Tasks` · `Endpoint` · `Schedule` · `Failure Actions` · `Retention` ### 02 · Eighteen task types on one canvas — no plugin to install. Most integration tools ask you to pick a vendor's marketplace and pray the connector you need is there. Apinizer ships eighteen task types in the box, every one configured by a form, none of them requiring code. Three buckets — connectors that talk to the outside world, compute that runs your logic, and control flow that lets one task flow call another. - API Call — outbound HTTP / REST with custom headers, methods, and bodies - Email — SMTP send with HTML or plain templates and dynamic recipients - Database — Select, Insert / Update / Delete, and Stored Procedure on the same canvas - Eight database engines — Oracle, PostgreSQL, MySQL, SQL Server, SAP Sybase, Apache Hive, Apache Impala, DB2 - Messaging — Kafka, RabbitMQ, ActiveMQ with topic / queue / partition routing - Files — FTP Read and FTP List for fixed-line and modern transfers - Logs and SIEM — Elasticsearch, Graylog, Syslog, Logback, SNMP traps - Webhook — push to any HTTP-reachable system, partner or internal - Script — inline Groovy / JavaScript for the logic in between - Linux Script — run a shell command on a remote host via secure connection - Notification — in-app notification to users or whole teams - Task Flow — call another task flow as a step, with its own audit **Concepts:** `14 connectors` · `2 compute types` · `Nested task flows` · `Form-configured` · `No code required` ### 03 · Chain steps with output keys. Iterate with JSON Path. No glue code. Every task writes its result to a named output key. The next task — or any task downstream — can reach in with a one-line JSON Path or XPath expression to pull a single field, iterate over an array, or template a request body. Loop over a database result. Iterate over a Kafka batch. Skip the request if a flag is missing. The variable drawer on the side lists everything in scope so the operator doesn't have to remember a single name. - Output keys per task — your result is available downstream by name - JSON Path / XPath syntax for nested field extraction - Loop variables — iterate over arrays with {{outputKey#.path}} expressions - Three variable scopes — this task's, previous tasks', and global / environment - Click to insert — variable picker means no typo-debugging - Once or Loop per task — turn iteration on at the task level - Continue on fail toggle keeps the loop running across bad rows - Static values, parameterized values, or expressions on every field **Concepts:** `Output key` · `JSON Path` · `XPath` · `Loop variable` · `Continue on fail` · `Variable scopes` ### 04 · Three ways to fire the same flow. Real integrations don't all run on the same clock. Some are nightly batches, some are partner pushes, some are downstream of another flow. Apinizer treats all three as first-class entry points — same canvas, same audit, same execution log. Pick a Quartz cron for the batch, publish a REST endpoint for the partner, or call the flow from another flow when composition is cleaner than copy-paste. - Schedule — Quartz cron expression with full timezone awareness - HTTP endpoint — auto-generated URL protected by a per-flow API Key - Nested call — invoke this flow as a step in another flow - Manual run — execute on demand from the Manager UI - Suspend toggle — pause the schedule without deleting the flow - Reachability indicator — the UI tells you when the Integration Server is offline - Same execution log captures every trigger source identically - Trigger configuration lives on its own builder step — no hidden settings **Concepts:** `Cron · Quartz` · `HTTP · REST` · `Nested` · `Manual run` · `API Key auth` · `Suspend` ### 05 · Wire failure to the page that wakes someone up. Every operator knows the worst flows are the ones that fail quietly. The Failure Actions step on the builder accepts any of the eighteen task types as a recovery path — page the oncall by email, fire an SNMP trap to the network operations center, push the failure trail to a webhook, log it to Graylog, push to Kafka for downstream alerts, or call a recovery task flow that rolls back the change. - Any of the eighteen task types can be a Failure Action - Email the oncall with the failure trail attached - SNMP trap to a NOC with severity and correlation ID - Webhook push to an incident management system - Graylog or Syslog write with full request and step context - Recovery task flow — call another flow to remediate without a human - Per-task retry with delay and condition - Continue-on-fail toggle for loops that should not abort on a bad row - Same audit applies to the failure action itself **Concepts:** `Any task type` · `Page oncall` · `SNMP trap` · `Webhook` · `Recovery flow` · `Retry + delay` ### 06 · Every step logged. Every flow charted. One tab. The execution log isn't a separate screen you have to remember to check. The same page that lists task flows sits above a KPI strip — total, succeeded, failed, in progress, success ratio — and a sortable table of every run. Click a run, expand it, and see the task log details plus the action log details, step by step, with timing and result on each line. - Five KPI cards — total, succeeded, failed, in progress, success ratio - Run-by-run table sortable by status, time, duration, or flow - Click a run to expand step-by-step task log details - Action log details — failure actions logged separately for clarity - Result types — SUCCESS, FAILURE, IN PROGRESS, INTERRUPTED - Filter by environment, by task flow, by date range - Per-task duration so you can spot the slow step in a flow - Retention setting from the builder controls how far back the log keeps **Concepts:** `5 KPI cards` · `Step-by-step log` · `Action log` · `Result types` · `Retention-aware` ### 07 · Same identity, same audit, same observability as the gateway. Most integration platforms come with their own login screen, their own RBAC model, and their own audit log. Apinizer's Integrator is built into the platform — which means the same operators who manage your APIs use the same identity, the same roles, the same audit trail, and the same Analytics Engine to see what their flows did. No second system to provision, no second account to manage. - Same Identity Manager — OIDC, OAuth 2.0, JWT, LDAP, AD, SAML - Same RBAC model — System, Project, and Team scoping - Same audit trail — who edited, who ran, who saw, with diffs - Same environment model — DEV → TEST → PROD promotion - Same APIops workflow — apply task flows alongside proxies - Same Analytics Engine surfaces success ratio, latency, and failures - Anomaly detection rules can target task flow metrics directly - Trace toggle per flow — same five-tab inspection as gateway traffic **Concepts:** `Identity Manager` · `Project + Team RBAC` · `Audit trail` · `DEV → TEST → PROD` · `APIops` · `Analytics Engine` --- ## Use cases ### Nightly ETL between systems your team didn't pick Read from one database, transform with a script in between, push to another — on a cron, with retry, continue-on-fail, and audit on every row. No bespoke ETL service to host. - Database → script → database in three drag-and-drop steps - Cron schedule with timezone awareness - Per-step retry and fallback connectors - Audit on every flow run kept by the retention setting ### Bridge protocols and systems via queues Read Kafka, transform with a script, publish to ActiveMQ. Or HTTP in, RabbitMQ out. Or FTP file in, database batch, queue notification. The canvas doesn't care which direction you're going. - Kafka, RabbitMQ, ActiveMQ ingestion and publishing - Multi-step transformation between protocols - Cross-protocol bridges — HTTP ↔ MQ ↔ FTP ↔ database - Event-driven triggering via the HTTP endpoint ### Automated report generation and delivery Pull from Elasticsearch with a custom query, format with a script, email + archive. The same flow runs daily without an extra service — and the failure path emails the right person if it doesn't. - Elasticsearch query as the data source - Format and transform inline with Script tasks - Email delivery with templated subjects and bodies - Archive to FTP or push to a Webhook ### Modern entry points on top of old systems Publish a REST endpoint that wraps a stored procedure, a Linux script, an SNMP poll, or a SOAP call — and let the partner consume a clean HTTP / JSON API while your legacy stays exactly where it is. - REST endpoint trigger backed by any task chain - Stored procedure, Linux script, or SOAP as the upstream - Same auth and audit as a hand-written gateway proxy - Trace toggle to debug a partner call step by step --- ## What ships in the box ### Designer & runtime - Six-step builder — Definition, Tasks, Endpoint, Schedule, Failure Actions, Retention - Drag-and-drop task canvas - Output-key chaining with JSON Path / XPath - Loop with continue-on-fail per task - Variable drawer — this task, previous tasks, global / environment - Per-task retry with delay and condition - Suspend toggle on the schedule - Trace toggle for step-by-step debugging ### Connectors & operations - Eighteen task types — 14 connectors, 2 compute, 2 control - Eight database engines supported on the DB connector - Three trigger modes — Cron, HTTP, Nested - HTTP endpoint protected by a per-flow API Key - Five-card KPI dashboard with success ratio - Step-by-step task and action execution log - Failure Actions on any of the eighteen task types - Same identity, audit, and Analytics Engine as the gateway --- ## Resources - [Task Flow Builder docs](https://docs.apinizer.com/en/integrations/api-integrator-task-flow-builder/overview) — The six-step builder — definition, canvas, endpoint, schedule, failure actions, retention — documented end to end. - [Task type reference](https://apinizer.com/developers/docs/task-types) — Every task type — connectors, compute, control flow — with config screenshots, examples, and tips. - [Output keys + JSON Path guide](https://apinizer.com/developers/docs/output-keys) — How to chain steps, iterate over arrays, and pick values out of nested responses without writing glue code. - [Scheduling with Quartz cron](https://apinizer.com/developers/docs/scheduling) — Cron expressions, timezone handling, suspend / resume, and the Integration Server reachability model. - [Failure Actions playbook](https://apinizer.com/developers/docs/failure-actions) — Patterns for paging the oncall, logging to SIEM, and triggering a recovery flow — without writing custom code. - [APIops + environment promotion](https://apinizer.com/developers/apiops) — Treat task flows like the rest of your platform — diff in the repo, validate in CI, apply across environments. - [Script + Linux Script](https://apinizer.com/developers/docs/scripting) — Inline Groovy and remote shell — when the logic between two connectors is best expressed in code. - [Architecture overview](https://docs.apinizer.com/en/concepts/architecture) — How the Integration Server sits next to the Manager and the gateway — and what runs where. --- ## Next step *Stop building bespoke integrations* **Connect anything to anything.** See the canvas, the eighteen task types, and a live failure-to-recovery cycle in a thirty-minute walkthrough — on the same platform that's already running your APIs. [Book a Demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## Links - Products: https://apinizer.com/products - AI Gateway: https://apinizer.com/products/ai-gateway - Solutions: https://apinizer.com/solutions - Pricing: https://apinizer.com/pricing - Developers: https://apinizer.com/developers - Documentation: https://docs.apinizer.com/index-en - Blog: https://apinizer.com/blog - Contact: https://apinizer.com/company/contact © 2026 Apinizer. All rights reserved.