# Edgaze Documentation: Full Corpus

> Turn your AI workflows into products people actually pay for.

Generated from https://www.edgaze.ai/docs. Each section below is a complete documentation page. Canonical HTML lives at the `source` URL in each front-matter block.


---

---
title: Edgaze vs n8n | Which Is Best For You?
description: Compare Edgaze and n8n across workflow ownership, marketplace distribution, hosting, pricing, APIs, MCP, customization, and the work each platform asks you to own.
source: https://www.edgaze.ai/compare/n8n
last_reviewed: September 14, 2026
type: comparison
---

# Edgaze vs n8n | Which Is Best For You?

Use n8n when your team wants to design and operate its own automations with deep control over the execution graph. Use Edgaze when you want to publish, discover, buy, and run hosted workflow products without making every buyer understand or maintain the graph behind them.

## Short answer

These products overlap at workflow execution, but they start from different jobs. n8n is primarily an automation-building environment. Edgaze is a distribution and commerce layer for hosted AI workflow products. The better choice depends on whether you want to own the automation or consume and distribute the outcome.

## Edgaze is best for

Creators selling runnable workflow products, buyers purchasing an outcome, and developers or agents invoking the same published workflow through the marketplace, REST API, or MCP.

## n8n is best for

Technical teams building internal automations, especially when self-hosting, custom nodes, source-level extensibility, or direct control of each workflow step matters.

## Capability grid

### Product and commerce

| Capability | Edgaze | n8n |
| --- | --- | --- |
| Public page for a finished workflow product | Yes — A published product page explains the outcome, collects inputs, and starts the run. | No — The [workflow template library](https://n8n.io/workflows/) helps builders start workflows; it is not a checkout for hosted third-party runs. |
| Buyer-facing marketplace checkout | Yes — Marketplace buyers can inspect, fund, and run a creator-owned workflow. | No — n8n is sold as automation software rather than a marketplace for purchasing individual workflow outcomes. |
| Creator earnings from successful runs | Yes — Creator earnings are connected to successful paid executions. | No — No native buyer-to-creator settlement model is presented for template runs. |
| Workflow-specific price visible before execution | Yes — The [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) is shown before the buyer starts the selected workflow. | Different model — [n8n pricing](https://n8n.io/pricing/) is plan-based around workflow executions, with separate AI credit allowances on listed plans. |
| One commercial product across web, API, and MCP | Yes — The same published version is available on its page, through the [Edgaze REST API](https://www.edgaze.ai/docs/api), and through [Edgaze MCP](https://www.edgaze.ai/docs/mcp). | No — The [n8n API](https://docs.n8n.io/connect/n8n-api/) and [MCP Server Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger/) operate automations, but not a shared buyer-facing paid product identity. |

### Building and operation

| Capability | Edgaze | n8n |
| --- | --- | --- |
| Visual workflow builder | Yes — [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) provides a connected visual graph. | Yes — The visual workflow editor is a central and mature n8n capability. |
| Managed cloud execution | Yes — [Edgaze-managed execution](https://www.edgaze.ai/docs/managed-execution) operates eligible published runs. | Yes — [n8n Cloud](https://n8n.io/pricing/) provides managed execution. |
| Self-hosted runtime | No — Edgaze is a managed platform, not a self-hosted runtime. | Yes — [Community Edition](https://docs.n8n.io/deploy/host-n8n/community-edition-features/) and paid self-hosted options make this a genuine n8n strength. |
| Programmatic workflow execution | Yes — The [Edgaze REST API](https://www.edgaze.ai/docs/api) exposes product discovery, contracts, runs, and status. | Yes — The [n8n API](https://docs.n8n.io/connect/n8n-api/) and webhooks support programmatic operation. |
| MCP-based execution | Yes — Agents can search, inspect, authorize, and run eligible marketplace products. | Yes — An [MCP Server Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger/) can expose an n8n workflow as an MCP tool you operate. |

## Where Edgaze changes the equation

### A workflow can become a paid product

- **Edgaze:** Publish the finished workflow with a product page, inputs, a [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow), checkout, and [creator earnings](https://www.edgaze.ai/docs/sell-everywhere).
- **n8n:** n8n templates help another builder recreate or adapt an automation; they are not individual paid hosted runs.

### One release can serve people, apps, and agents

- **Edgaze:** A single [immutable workflow version](https://www.edgaze.ai/docs/managed-execution) can run from the marketplace, [Edgaze REST API](https://www.edgaze.ai/docs/api), or [Edgaze MCP](https://www.edgaze.ai/docs/mcp).
- **n8n:** n8n supports API, webhook, and MCP access, but those interfaces do not share an Edgaze-style marketplace product and checkout.

### The buyer does not have to become the builder

- **Edgaze:** The buyer sees the promised outcome, required inputs, price, progress, and result—not the creator's editable graph.
- **n8n:** Using an n8n template normally means importing, configuring, credentialing, and maintaining the workflow yourself.

### Commerce and execution ship together

- **Edgaze:** Managed execution, funding, run records, product discovery, and creator settlement live around the workflow by default.
- **n8n:** n8n supplies the automation platform; a team selling outcomes must assemble its own buyer and payment layer.

## Detailed comparison

| Topic | Edgaze | n8n |
| --- | --- | --- |
| Primary job | Turn workflows into public products people and agents can discover, pay for, and run. | Build, connect, and operate automations for a team or organization. |
| Typical user | Workflow creators, buyers, application developers, and AI-agent users. | Automation builders, technical operators, and engineering-adjacent teams. |
| Build or buy | Supports building, but also makes finished workflow products directly purchasable and runnable. | Centers on constructing and maintaining your own workflows from nodes and templates. |
| Hosting | Published marketplace and API runs execute on Edgaze-managed infrastructure. | Offers [n8n Cloud](https://n8n.io/pricing/) and self-hosted editions, with different operational responsibility. |
| Self-hosting | Not positioned as a self-hosted runtime. | A major strength; a [Community Edition](https://docs.n8n.io/deploy/host-n8n/community-edition-features/) is available for self-hosting. |
| Marketplace | A commerce surface for creator-owned products with public pages, per-run prices, demos, and [creator earnings](https://www.edgaze.ai/docs/sell-everywhere). | Provides a large [workflow template library](https://n8n.io/workflows/); the core product is not a buyer-facing pay-per-run workflow marketplace. |
| Pricing unit | Buyers see a workflow-specific price before a run; creators set margin within platform rules. | [n8n pricing](https://n8n.io/pricing/) is primarily metered by complete workflow executions rather than individual steps, with separate AI credit allowances on listed plans. |
| API and agents | The same published product can run from its page, the [Edgaze REST API](https://www.edgaze.ai/docs/api), or [Edgaze MCP](https://www.edgaze.ai/docs/mcp). | Provides the [n8n API](https://docs.n8n.io/connect/n8n-api/), webhooks, an [AI Agent node](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/), and an [MCP Server Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger/) for automations you operate. |
| Graph visibility | Buyers can run the product without being exposed to its editable workflow graph. | The graph is the main environment in which builders configure and debug automation. |
| Maintenance burden | Edgaze operates hosted execution while the creator maintains the published product and integrations. | The team building the automation owns workflow design and, when self-hosting, the runtime stack too. |

## The real difference is ownership

n8n gives a technical team a powerful environment for assembling triggers, integrations, code, branching logic, and AI steps. That control is valuable when the workflow is part of internal infrastructure and the team wants to inspect or change every node.

Edgaze begins one layer later. A creator publishes a tested workflow as a product with a public explanation, input contract, immutable version, and visible run price. A buyer or agent can use that product without rebuilding it. The creator owns the product logic; Edgaze operates the hosted run path.

- Choose control of the graph when the automation itself is your team's responsibility.
- Choose a published product when the result matters more than editing every implementation detail.

## Self-hosting is a genuine n8n advantage

If data residency, network access, custom nodes, or infrastructure policy requires a self-managed deployment, n8n has the clearer fit. Its [Community Edition](https://docs.n8n.io/deploy/host-n8n/community-edition-features/) is available for self-hosting under the [Sustainable Use License](https://docs.n8n.io/n8n-community-license/sustainable-use-license/), while paid self-hosted editions add collaboration and governance features.

Edgaze deliberately trades that level of infrastructure control for a managed commercial surface. Creators do not provision queue workers, usage ledgers, buyer checkout, or [marketplace discovery](https://www.edgaze.ai/docs/sell-everywhere) for each workflow. That is an advantage only when managed execution and distribution are the desired outcome.

## Distribution changes the economics

An n8n workflow normally creates value inside the organization operating it. An Edgaze workflow can also be packaged for outside buyers, invoked by applications, or discovered by agents through MCP. All three channels point to the same published version and pricing rules.

That does not make Edgaze a replacement for every internal automation. It makes Edgaze relevant when a workflow is meant to travel: when its creator wants a product page, public discovery, payment per successful run, and a runtime the buyer does not have to administer.

## Frequently asked questions

### Is Edgaze an n8n alternative?

Edgaze can be an alternative when the goal is to publish, buy, or run a hosted workflow product. It is not a direct replacement for teams that choose n8n specifically for self-hosting, custom nodes, or hands-on control of an internal automation graph.

### Can I self-host Edgaze like n8n?

No. Edgaze is positioned as a managed marketplace and execution platform. n8n offers self-hosting and is the stronger option when running the automation infrastructure yourself is a requirement.

### How does pricing differ?

n8n plans are generally based on workflow execution allowances and deployment features. Edgaze buyers see a price for a specific published workflow run, while creators set a margin and Edgaze adds applicable hosted compute.

### Can AI agents run workflows on both platforms?

Both platforms support agent-related workflows and programmatic execution. Edgaze's distinction is that an agent can discover and run the same published marketplace product exposed to human buyers through [Edgaze MCP](https://www.edgaze.ai/docs/mcp).

### Which is better for selling workflows?

Edgaze is purpose-built around [public product page](https://www.edgaze.ai/docs/sell-everywhere)s, [marketplace discovery](https://www.edgaze.ai/docs/sell-everywhere), per-run purchasing, and [creator earnings](https://www.edgaze.ai/docs/sell-everywhere). n8n is better known as a platform for building and operating automations rather than selling each workflow run as a product.

## Sources

- [Edgaze: sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Edgaze: managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Edgaze pricing](https://www.edgaze.ai/pricing)
- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Edgaze REST API](https://www.edgaze.ai/docs/api)
- [Edgaze Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio)
- [Edgaze run pricing and billing](https://www.edgaze.ai/docs/billing/run-a-workflow)
- [n8n pricing](https://n8n.io/pricing/)
- [n8n editions and Community features](https://docs.n8n.io/deploy/host-n8n/community-edition-features/)
- [n8n Sustainable Use License](https://docs.n8n.io/n8n-community-license/sustainable-use-license/)
- [n8n workflow templates](https://n8n.io/workflows/)
- [n8n public API](https://docs.n8n.io/connect/n8n-api/)
- [n8n AI Agent node](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/)
- [n8n MCP Server Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger/)

Last reviewed: September 14, 2026


---

---
title: Edgaze vs Zapier | Which Is Best For You?
description: Compare Edgaze and Zapier across automation, AI agents, integrations, workflow commerce, pricing, APIs, MCP, hosting, and the best fit for each platform.
source: https://www.edgaze.ai/compare/zapier
last_reviewed: September 14, 2026
type: comparison
---

# Edgaze vs Zapier | Which Is Best For You?

Use Zapier when you want a mature automation platform connecting a very broad catalog of business applications. Use Edgaze when a creator-built AI workflow should become a priced product that humans, applications, and agents can run through one hosted surface.

## Short answer

Zapier offers substantially broader app automation and an established orchestration suite. Edgaze offers a different commercial model: publish a workflow once, price each run, and make the same product available to marketplace buyers, API callers, and MCP-connected agents.

## Edgaze is best for

Creators distributing AI workflow products and buyers who prefer to purchase a finished outcome rather than configure the automation themselves.

## Zapier is best for

Individuals and organizations automating repeatable work across a large app ecosystem with Zaps, tables, forms, agents, and related orchestration tools.

## Capability grid

### Product and commerce

| Capability | Edgaze | Zapier |
| --- | --- | --- |
| Public page for a finished workflow product | Yes — Every published product has a buyer-facing explanation and run path. | No — [Zapier templates](https://zapier.com/templates) accelerate setup, but the customer still configures a Zap for their own account. |
| Marketplace for purchasing a workflow outcome | Yes — Buyers discover and purchase individual creator-built runs. | No — Zapier's app and template catalogs are not a third-party pay-per-run workflow marketplace. |
| Creator earnings from successful runs | Yes — Successful paid runs create [creator earnings](https://www.edgaze.ai/docs/sell-everywhere) under platform rules. | No — Zapier does not position Zap executions as buyer-funded creator products. |
| Workflow-specific price visible before execution | Yes — The selected workflow's [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) is known before it starts. | Different model — Zap workflows and [Zapier MCP](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP) use plan tasks; [Zapier Agents](https://zapier.com/agents) are measured in [agent activities](https://help.zapier.com/hc/en-us/articles/26559132765325-How-is-Zapier-Agents-usage-measured). |
| One commercial product across web, API, and MCP | Yes — Each interface resolves to the same published workflow product. | No — Zapier offers multiple automation and agent surfaces, not one shared paid marketplace product identity. |

### Building and operation

| Capability | Edgaze | Zapier |
| --- | --- | --- |
| Visual workflow builder | Yes — [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) combines a visual graph with publishing controls. | Yes — Zapier provides a mature no-code automation builder. |
| Managed cloud execution | Yes — Published runs execute on Edgaze-managed infrastructure. | Yes — Zapier operates its cloud automation runtime. |
| Large prebuilt app-action catalog | Different model — Edgaze has focused blocks, HTTP access, and reusable workflow composition. | Yes — Zapier documents [9,000+ apps and 40,000+ actions](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP)—a major breadth advantage. |
| AI-agent surface | Yes — External agents discover and run published products through MCP. | Yes — [Zapier Agents](https://zapier.com/agents) act across connected apps and knowledge sources. |
| MCP access | Yes — MCP exposes catalog search, product inspection, funding, and execution. | Yes — [Zapier MCP](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP) exposes app actions; each successful tool call currently consumes [two tasks](https://help.zapier.com/hc/en-us/articles/45645738385805-How-Zapier-MCP-usage-works). |

## Where Edgaze changes the equation

### Sell an outcome instead of configuring another account

- **Edgaze:** A creator publishes a runnable product and a buyer pays for the selected result.
- **Zapier:** Zapier is optimized for customers building automations inside their own workspace and connected apps.

### Keep one identity across every run surface

- **Edgaze:** The product page, API contract, MCP listing, immutable version, and [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) stay connected.
- **Zapier:** Zapier's Zaps, Agents, app actions, and MCP access are powerful but remain distinct product surfaces.

### Quote the exact workflow before it runs

- **Edgaze:** The buyer sees one workflow-specific [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) before authorizing execution.
- **Zapier:** Usage is accounted through plan tasks and, for Agents, separate [agent activities](https://help.zapier.com/hc/en-us/articles/26559132765325-How-is-Zapier-Agents-usage-measured) rather than a creator-set run price.

### Turn successful runs into creator earnings

- **Edgaze:** Commerce is native to publishing, so the creator can earn when a paid hosted run succeeds.
- **Zapier:** Zapier's public model centers software subscriptions and automation usage, not marketplace settlement per creator workflow.

## Detailed comparison

| Topic | Edgaze | Zapier |
| --- | --- | --- |
| Primary job | Publish and sell runnable AI workflow products. | Automate work across applications and teams. |
| Typical user | Workflow creators, outcome buyers, developers, and agent users. | Business users, operations teams, and automation specialists. |
| Integrations | A growing set of workflow blocks plus HTTP and composable workflow capabilities. | A defining strength: Zapier documents [9,000+ apps and 40,000+ actions](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP) available through its automation and MCP ecosystem. |
| Marketplace model | Buyers can discover and pay to run creator products. | [Zapier templates](https://zapier.com/templates) accelerate setup, but Zaps are mainly automations customers configure for their own accounts. |
| Pricing unit | A visible price for the selected workflow run. | Zap workflows and [Zapier MCP](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP) consume plan tasks; [Zapier Agents](https://zapier.com/agents) is measured separately in [agent activities](https://help.zapier.com/hc/en-us/articles/26559132765325-How-is-Zapier-Agents-usage-measured). |
| AI agents | Agents discover and run published workflow products through MCP. | [Zapier Agents](https://zapier.com/agents) create AI teammates that act across connected apps and knowledge sources. |
| MCP | MCP exposes the marketplace catalog and run lifecycle. | [Zapier MCP](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP) exposes app actions to compatible AI clients; each successful tool call currently consumes [two tasks](https://help.zapier.com/hc/en-us/articles/45645738385805-How-Zapier-MCP-usage-works) from the connected plan. |
| Builder experience | Visual [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) plus publishing, pricing, and product-page setup. | A mature no-code automation builder with broad trigger and action coverage. |
| Hosting | Published runs use [Edgaze-managed execution](https://www.edgaze.ai/docs/managed-execution). | Zapier operates the cloud automation platform and connected task execution. |
| Best reason to choose | You are productizing and distributing workflow outcomes. | You need wide app coverage and business automation breadth. |

## Breadth versus productization

Zapier's integration catalog and years of business-automation tooling are its clearest advantages. A company that wants to connect common SaaS tools, automate operational handoffs, and give teams a familiar no-code environment should weigh that maturity heavily.

Edgaze is narrower in integration breadth and broader in the commercial treatment of a workflow. It combines creation with a [public product page](https://www.edgaze.ai/docs/sell-everywhere), a marketplace, visible per-run pricing, [creator earnings](https://www.edgaze.ai/docs/sell-everywhere), and one execution identity across web, API, and MCP.

## Agents exist on both sides, but they serve different products

[Zapier Agents](https://zapier.com/agents) are designed as AI teammates that use connected applications and data sources to perform work. [Zapier MCP](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP) gives AI assistants access to actions across Zapier's ecosystem. Those are significant capabilities and should not be reduced to a missing-feature checkbox.

Edgaze's agent story is tied to its marketplace. The agent searches for a creator-published workflow, inspects its inputs and price, and runs that same product. The useful distinction is not whether an agent exists; it is whether the callable unit is an app action, a customer-owned automation, or a purchasable workflow product.

## Choose based on who should assemble the solution

Zapier is usually the better fit when the customer wants to configure the automation around their own accounts and processes. Edgaze is the better fit when a specialist creator has already assembled the workflow and the customer wants to evaluate and run the finished product.

Some teams may use both: Zapier for internal app orchestration and Edgaze for externally sourced AI workflow products that are called from an application or agent.

## Frequently asked questions

### Is Edgaze a Zapier replacement?

Not for every use case. Zapier is stronger when broad SaaS integration coverage and customer-built automation are the priority. Edgaze is designed for publishing, selling, buying, and running completed AI workflow products.

### Does Zapier support AI agents?

Yes. Zapier offers Agents and other AI orchestration capabilities. Edgaze differs by making creator-published marketplace workflows directly discoverable and runnable by agents through MCP.

### Which platform has more integrations?

Zapier has the substantially larger established app ecosystem. Edgaze supports workflow blocks, APIs, and HTTP connections, but integration count is not its primary differentiator.

### Which is better for creators selling a workflow?

Edgaze is built around public workflow product pages, per-run pricing, marketplace distribution, and [creator earnings](https://www.edgaze.ai/docs/sell-everywhere). Zapier primarily helps customers build and run automations for themselves.

### Can developers trigger Edgaze workflows programmatically?

Yes. Published workflows can be discovered and run through the [Edgaze REST API](https://www.edgaze.ai/docs/api), with asynchronous run status, spend controls, and webhook support.

## Sources

- [Edgaze: sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Edgaze: managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Edgaze pricing](https://www.edgaze.ai/pricing)
- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Edgaze REST API](https://www.edgaze.ai/docs/api)
- [Edgaze Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio)
- [Edgaze run pricing and billing](https://www.edgaze.ai/docs/billing/run-a-workflow)
- [Zapier platform pricing](https://zapier.com/pricing)
- [Zapier app directory](https://zapier.com/apps)
- [Zapier workflow templates](https://zapier.com/templates)
- [Zapier Agents](https://zapier.com/agents)
- [How Zapier Agents usage is measured](https://help.zapier.com/hc/en-us/articles/26559132765325-How-is-Zapier-Agents-usage-measured)
- [What Zapier MCP exposes](https://help.zapier.com/hc/en-us/articles/48308034391821-What-is-Zapier-MCP)
- [Zapier MCP usage and billing](https://help.zapier.com/hc/en-us/articles/45645738385805-How-Zapier-MCP-usage-works)
- [How Zapier task usage is measured](https://help.zapier.com/hc/en-us/articles/8496196837261-How-is-task-usage-measured-in-Zapier)

Last reviewed: September 14, 2026


---

---
title: Edgaze vs Make | Which Is Best For You?
description: Compare Edgaze and Make across visual workflow building, AI agents, MCP, API access, hosting, marketplace distribution, pricing, and workflow ownership.
source: https://www.edgaze.ai/compare/make
last_reviewed: September 14, 2026
type: comparison
---

# Edgaze vs Make | Which Is Best For You?

Use Make when your team wants a visual-first platform for building scenarios across a large integration catalog. Use Edgaze when the workflow itself should be packaged, priced, discovered, and run as a creator product rather than assembled by every customer.

## Short answer

Make is the stronger general-purpose visual automation suite. Edgaze is the stronger fit when distribution, product presentation, creator monetization, and purchase-per-run access are central requirements.

## Edgaze is best for

Productizing AI workflows for marketplace buyers and exposing the same published run through product pages, REST APIs, and MCP.

## Make is best for

Teams visually designing business automations and AI scenarios across a broad library of apps, routers, filters, and operational controls.

## Capability grid

### Product and commerce

| Capability | Edgaze | Make |
| --- | --- | --- |
| Public page for a finished workflow product | Yes — Publishing produces a buyer-facing product and run experience. | No — [Make templates](https://www.make.com/en/templates) are starting points for scenarios, not purchases of hosted third-party outcomes. |
| Buyer-facing workflow marketplace | Yes — Marketplace discovery leads directly to inspection, funding, and execution. | No — Make's public catalog centers integrations and scenario templates. |
| Creator earnings from successful runs | Yes — A creator can earn from successful paid product runs. | No — Scenario executions are not sold through a native creator settlement layer. |
| Workflow-specific price visible before execution | Yes — The [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) is attached to the published workflow product. | Different model — [Make pricing](https://www.make.com/en/pricing) uses [credits](https://help.make.com/credits); most app operations use one credit and hosted AI can add token-based usage. |
| One commercial product across web, API, and MCP | Yes — Human, application, and agent runs share one published product identity. | No — Make exposes scenarios through several interfaces, but not as one paid third-party marketplace product. |

### Building and operation

| Capability | Edgaze | Make |
| --- | --- | --- |
| Visual workflow builder | Yes — [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) builds a graph that can be published as a product. | Yes — Visual scenario design is a core Make strength. |
| Managed cloud execution | Yes — Edgaze manages eligible marketplace, API, and MCP runs. | Yes — Make runs scenarios on its managed cloud platform. |
| Broad prebuilt integration catalog | Different model — Edgaze combines focused blocks, HTTP, and reusable workflows. | Yes — [Make integrations](https://www.make.com/en/integrations) are a major general-purpose automation advantage. |
| Scenario or workflow API | Yes — The [Edgaze REST API](https://www.edgaze.ai/docs/api) discovers products and manages the run lifecycle. | Yes — The [Make scenario API](https://developers.make.com/api-documentation/api-reference/scenarios) creates, runs, activates, and manages scenarios. |
| MCP access | Yes — [Edgaze MCP](https://www.edgaze.ai/docs/mcp) exposes an evolving marketplace catalog and paid run path. | Yes — [Make MCP Server](https://www.make.com/en/mcp) connects external AI systems to Make scenarios. |

## Where Edgaze changes the equation

### Publish the scenario as a finished product

- **Edgaze:** [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) publishing adds a public page, input contract, immutable version, price, and buyer run path.
- **Make:** A Make template helps a customer construct a scenario; it does not sell the finished scenario run as a third-party product.

### Give every channel the same contract

- **Edgaze:** Marketplace, [Edgaze REST API](https://www.edgaze.ai/docs/api), and [Edgaze MCP](https://www.edgaze.ai/docs/mcp) calls resolve to the same published workflow version.
- **Make:** Make supports APIs and MCP, but those surfaces are centered on scenarios owned and maintained by the customer.

### Make the commercial decision legible upfront

- **Edgaze:** A buyer sees the workflow-specific [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) before the run begins.
- **Make:** Make usage is expressed in [credits](https://help.make.com/credits) and can vary with operations and hosted AI token consumption.

### Let the creator maintain the logic once

- **Edgaze:** The creator releases new immutable versions while buyers continue consuming the product rather than editing its graph.
- **Make:** Make customers or implementation teams normally configure and maintain their own scenarios.

## Detailed comparison

| Topic | Edgaze | Make |
| --- | --- | --- |
| Primary job | Create and distribute runnable workflow products. | Design and operate visual automation scenarios. |
| Visual builder | [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) builds publishable AI products. | Visual scenario design is a core and mature product strength. |
| App ecosystem | Focused workflow blocks, HTTP access, and reusable published workflows. | [Make integrations](https://www.make.com/en/integrations) provide a broad catalog of application modules for triggers, actions, search, and data transformation. |
| Marketplace | A buyer-facing marketplace with paid runs and [creator earnings](https://www.edgaze.ai/docs/sell-everywhere). | [Make templates](https://www.make.com/en/templates) help users start scenarios; they are not primarily sold as per-run third-party products. |
| Pricing unit | Workflow-specific price shown before execution. | [Make pricing](https://www.make.com/en/pricing) uses [credits](https://help.make.com/credits): most non-AI app operations consume one credit, while Make-hosted AI features can add token-based usage. |
| AI agents | Agents call published products through the marketplace-oriented MCP surface. | Make includes [Make AI Agents](https://www.make.com/en/ai-agents) and Maia alongside its automation platform. |
| MCP | Catalog search, product inspection, and execution are available through [Edgaze MCP](https://www.edgaze.ai/docs/mcp). | [Make MCP Server](https://www.make.com/en/mcp) connects external AI systems to Make scenarios. |
| API | Discover products, inspect schemas, create runs, watch status, and receive webhooks. | The [Make scenario API](https://developers.make.com/api-documentation/api-reference/scenarios) can create, run, activate, inspect, and manage scenarios and their interfaces. |
| Hosting | Edgaze manages published marketplace and API runs. | Make runs scenarios on its managed cloud platform, with enterprise connectivity options. |
| Who maintains logic | The creator maintains the published product; buyers consume a versioned run. | The customer or implementation team maintains its scenarios. |

## Both are visual, but the destination is different

Make's visual canvas is designed to help a team map and operate its own processes. Routers, filters, schedules, data mapping, and a large module ecosystem make it a capable automation environment from prototype through enterprise use.

Edgaze [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) also uses a graph, but publishing moves the result into a commerce system. The workflow gains a public page, version, input envelope, run price, buyer experience, API identity, and agent-accessible tool surface.

## Do not compare MCP as a yes-or-no feature

Make publicly offers [Make MCP Server](https://www.make.com/en/mcp) and [Make AI Agents](https://www.make.com/en/ai-agents). The meaningful comparison is what each MCP endpoint exposes. Make connects an AI system to scenarios and the automation platform. Edgaze lets an agent search a marketplace of published products, inspect the selected workflow, see the terms of the run, and execute it.

For an internal operations team, Make's approach may be exactly right. For a workflow creator seeking distribution to agents they do not control, Edgaze's marketplace model is the more relevant distinction.

## The buyer experience is the dividing line

A Make user generally opens the platform to build or manage a scenario. An Edgaze buyer generally opens a product page to understand an outcome, supply inputs, confirm a [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow), and run it. That difference affects design, billing, permissions, and how much technical context the end user needs.

## Frequently asked questions

### Is Edgaze an alternative to Make?

Edgaze is an alternative when the desired outcome is a published, purchasable AI workflow product. Make remains the stronger choice for broad visual automation that your own team builds and manages.

### Does Make have AI agents and MCP?

Yes. Make offers AI Agents and an MCP server. Edgaze differentiates around [marketplace discovery](https://www.edgaze.ai/docs/sell-everywhere), creator distribution, and a shared paid product identity across human, API, and agent runs.

### Which has the larger integration catalog?

Make has the larger established integration catalog. Edgaze focuses on composing AI workflows and turning them into hosted products.

### How do their pricing models differ?

Make sells platform plans with credit allowances. Edgaze displays a product-specific price before each paid workflow run and settles creator margin on successful runs.

### Can an Edgaze workflow run without showing its graph to the buyer?

Yes. Buyers use the published input and result experience; the creator's editable [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) graph is not the buyer interface.

## Sources

- [Edgaze: sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Edgaze: managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Edgaze pricing](https://www.edgaze.ai/pricing)
- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Edgaze REST API](https://www.edgaze.ai/docs/api)
- [Edgaze Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio)
- [Edgaze run pricing and billing](https://www.edgaze.ai/docs/billing/run-a-workflow)
- [Make pricing](https://www.make.com/en/pricing)
- [How Make credits work](https://help.make.com/credits)
- [Make integrations](https://www.make.com/en/integrations)
- [Make scenario templates](https://www.make.com/en/templates)
- [Make AI Agents](https://www.make.com/en/ai-agents)
- [Make MCP server](https://www.make.com/en/mcp)
- [Make API documentation](https://developers.make.com/api-documentation)
- [Make scenarios API](https://developers.make.com/api-documentation/api-reference/scenarios)

Last reviewed: September 14, 2026


---

---
title: Edgaze vs Gumloop | Which Is Best For You?
description: Compare Edgaze and Gumloop for AI workflow creation, agents, templates, APIs, MCP, hosted execution, marketplace distribution, and creator monetization.
source: https://www.edgaze.ai/compare/gumloop
last_reviewed: September 14, 2026
type: comparison
---

# Edgaze vs Gumloop | Which Is Best For You?

Use Gumloop when a team wants to build and deploy AI agents that use its tools and company knowledge, then automate them with triggers, schedules, and APIs. Use Edgaze when a workflow creator wants to publish the finished system as a priced product that outside buyers, applications, and agents can discover and run.

## Short answer

Gumloop and Edgaze both reduce the work required to build AI workflows. Gumloop centers the builder and team automation experience. Edgaze centers the published product, its distribution, its buyer experience, and creator revenue from successful runs.

## Edgaze is best for

Creators commercializing AI workflows and customers buying a clear, hosted outcome with a visible price per run.

## Gumloop is best for

Teams building no-code AI workflows, agents, and internal automations with prebuilt nodes, integrations, triggers, and interfaces.

## Capability grid

### Product and commerce

| Capability | Edgaze | Gumloop |
| --- | --- | --- |
| Public interface for running a workflow | Yes — Published products include a buyer-facing input and result experience. | Yes — Gumloop [Hosted Pages](https://docs.gumloop.com/core-concepts/hosted_pages) can expose agents through a shareable web interface. |
| Marketplace for purchasing creator workflows | Yes — The marketplace is a native discovery and commerce surface. | No — Gumloop provides templates and shared resources; resale per workflow run is not its central model. |
| Creator earnings from successful runs | Yes — Successful paid runs can create [creator earnings](https://www.edgaze.ai/docs/sell-everywhere). | No — Public positioning centers subscriptions for teams building their own agents. |
| Workflow-specific price visible before execution | Yes — The [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) is quoted before the selected product runs. | Different model — [Gumloop credits](https://docs.gumloop.com/core-concepts/credits) meter usage; agent cost can vary with tokens and tool use. |
| One commercial product across web, API, and MCP | Yes — All three interfaces point to the same published version and price. | No — Gumloop exposes several deployment surfaces, but not one buyer marketplace identity with per-run settlement. |

### Building and operation

| Capability | Edgaze | Gumloop |
| --- | --- | --- |
| Visual workflow builder | Yes — [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) connects models, tools, logic, and outputs visually. | Yes — Gumloop provides a visual drag-and-drop workflow builder. |
| Managed cloud execution | Yes — Published marketplace and API runs use [Edgaze-managed execution](https://www.edgaze.ai/docs/managed-execution). | Yes — Gumloop hosts flows and agent execution. |
| Agent-building workspace | Different model — Edgaze publishes workflows that outside agents can discover and invoke. | Yes — [Gumloop Agents](https://docs.gumloop.com/core-concepts/agents) combine connectors, knowledge, skills, and workflows for a team. |
| Official API and SDK access | Yes — The [Edgaze REST API](https://www.edgaze.ai/docs/api) covers product inspection and durable runs. | Yes — Gumloop offers REST APIs plus official [Python SDK](https://docs.gumloop.com/api-reference/sdk/python) and [JavaScript SDK](https://docs.gumloop.com/api-reference/sdk/javascript) clients. |
| MCP access | Yes — Agents discover, inspect, fund, and run eligible marketplace products. | Yes — The [Gumloop MCP server](https://docs.gumloop.com/mcp-server/overview) connects compatible AI clients to Gumloop. |

## Where Edgaze changes the equation

### Turn the workflow into marketplace inventory

- **Edgaze:** Publishing makes the product discoverable to outside buyers with a page, price, purchase, and hosted run path.
- **Gumloop:** Gumloop is positioned around organizations building and deploying their own agents and automations.

### Give every buyer the same product identity

- **Edgaze:** The web page, [Edgaze REST API](https://www.edgaze.ai/docs/api), and [Edgaze MCP](https://www.edgaze.ai/docs/mcp) all resolve to one published product and immutable version.
- **Gumloop:** [Hosted Pages](https://docs.gumloop.com/core-concepts/hosted_pages), APIs, SDKs, and MCP are available, but they are not tied together by a paid creator marketplace listing.

### Price the outcome before it starts

- **Edgaze:** The buyer sees the selected workflow's [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) before authorizing the run.
- **Gumloop:** Workflow credits are predictable in many cases, while Gumloop documents variable agent costs from tokens and tool use.

### Connect execution directly to creator earnings

- **Edgaze:** A successful paid run flows through the platform's creator settlement model.
- **Gumloop:** [Gumloop pricing](https://www.gumloop.com/pricing) supports customers operating automations for their own work rather than third-party creator payouts per run.

## Detailed comparison

| Topic | Edgaze | Gumloop |
| --- | --- | --- |
| Primary job | Publish, sell, discover, and run workflow products. | Build and deploy AI agents, then automate them with triggers and schedules. |
| Audience | Creators, buyers, developers, and agent users. | Automation builders, operations teams, and organizations adopting AI workflows. |
| Builder | Visual graph plus product publishing and marketplace setup. | Visual drag-and-drop workflow builder with a broad node library. |
| Agents | External agents can discover and run marketplace workflows through MCP. | [Gumloop Agents](https://docs.gumloop.com/core-concepts/agents) orchestrate connectors, knowledge, skills, and workflows for a team. |
| MCP | A distribution surface for discoverable published products. | The [Gumloop MCP server](https://docs.gumloop.com/mcp-server/overview) connects compatible AI clients to Gumloop, while hosted and custom MCP connectors can become agent tools. |
| Marketplace | Commerce is native: [public product page](https://www.edgaze.ai/docs/sell-everywhere)s, pricing, purchases, and creator payouts. | Provides templates and shared automation resources; workflow resale is not the central product model. |
| Pricing | Buyer pays the [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) for a selected workflow run. | [Gumloop credits](https://docs.gumloop.com/core-concepts/credits) meter workflow and agent activity: workflow costs are designed to be predictable, while agent cost varies with tokens and tool use. |
| API | The public catalog and run lifecycle are designed for application integration. | The [Gumloop API](https://docs.gumloop.com/api-reference/getting-started) can create agents, start sessions, and trigger automations; official [Python SDK](https://docs.gumloop.com/api-reference/sdk/python) and [JavaScript SDK](https://docs.gumloop.com/api-reference/sdk/javascript) clients are available. |
| Hosting | Marketplace and API runs use Edgaze's managed runtime. | Gumloop hosts agent execution and can publish agents as [Hosted Pages](https://docs.gumloop.com/core-concepts/hosted_pages), Slack apps, Teams experiences, or email inboxes. |
| Commercial model | A creator earns from successful runs of a published product. | Customers subscribe to build and operate automations for their own work. |

## Builder quality is not the only question

Gumloop offers a polished environment for AI workflows and [Gumloop Agents](https://docs.gumloop.com/core-concepts/agents), including connectors, [Agent Triggers](https://docs.gumloop.com/core-concepts/agent_triggers), company knowledge, skills, hosted interfaces, and an expanding library of tools. It is a credible option for teams that want to assemble and deploy AI automation without writing the full system in code.

Edgaze asks what happens after the workflow works. Publishing creates a product that can be presented to buyers, priced, versioned, discovered in a marketplace, and called from the web, API, or MCP. That downstream distribution layer is the main reason to choose it.

## The agent models point in different directions

Gumloop helps customers create agents and connect them to tools. Edgaze helps creators expose finished workflows to agents as discoverable tools. One starts with the organization assembling an agent; the other starts with a product catalog an agent can search and use.

Neither model is universally better. Internal automation teams may prefer Gumloop's integrated building environment. Independent workflow creators and applications consuming third-party workflow products may prefer Edgaze's publication and commerce model.

## A marketplace creates a separate trust problem

Selling workflow runs requires more than sharing a template. Buyers need a clear explanation, stable input schema, visible price, demo or proof, versioning, run status, and rules for failed execution. Edgaze's product and billing surfaces are designed around that transaction.

## Frequently asked questions

### Is Edgaze a Gumloop alternative?

Yes for teams or creators focused on publishing and selling hosted workflow products. Gumloop may be the better choice when the main job is building internal no-code AI automations and agents.

### Can Gumloop workflows be triggered through an API?

Yes. Gumloop documents webhooks, REST APIs, SDKs, and MCP-related tools for triggering and managing flows. Edgaze's API distinction is its direct relationship to the public marketplace product and pricing model.

### Which is better for selling AI workflows?

Edgaze is purpose-built for creator product pages, [marketplace discovery](https://www.edgaze.ai/docs/sell-everywhere), paid runs, and [creator earnings](https://www.edgaze.ai/docs/sell-everywhere). Gumloop's public positioning centers organizational workflow and agent building.

### Do both platforms host execution?

Both provide managed cloud execution. Edgaze packages that runtime together with a buyer-facing product, payment, and distribution surface.

### Which is better for a nontechnical operations team?

Gumloop's no-code builder may be the better fit when the team wants to construct its own automation. Edgaze can be simpler when the team wants to run an already-built product rather than maintain a workflow graph.

## Sources

- [Edgaze: sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Edgaze: managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Edgaze pricing](https://www.edgaze.ai/pricing)
- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Edgaze REST API](https://www.edgaze.ai/docs/api)
- [Edgaze Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio)
- [Edgaze run pricing and billing](https://www.edgaze.ai/docs/billing/run-a-workflow)
- [Gumloop product documentation](https://docs.gumloop.com/)
- [Gumloop pricing](https://www.gumloop.com/pricing)
- [Gumloop Agents](https://docs.gumloop.com/core-concepts/agents)
- [Gumloop credits](https://docs.gumloop.com/core-concepts/credits)
- [Gumloop Agent Triggers](https://docs.gumloop.com/core-concepts/agent_triggers)
- [Gumloop API getting started](https://docs.gumloop.com/api-reference/getting-started)
- [Gumloop Python SDK](https://docs.gumloop.com/api-reference/sdk/python)
- [Gumloop JavaScript SDK](https://docs.gumloop.com/api-reference/sdk/javascript)
- [Gumloop MCP server](https://docs.gumloop.com/mcp-server/overview)
- [Gumloop Hosted Pages](https://docs.gumloop.com/core-concepts/hosted_pages)

Last reviewed: September 14, 2026


---

---
title: Edgaze vs Apify | Which Is Best For You?
description: Compare Edgaze and Apify across workflow marketplaces, web scraping, Actors, pricing, APIs, MCP, hosting, creator monetization, and intended users.
source: https://www.edgaze.ai/compare/apify
last_reviewed: September 14, 2026
type: comparison
---

# Edgaze vs Apify | Which Is Best For You?

Use Apify when the core job is web scraping, crawling, browser automation, or operating code-based Actors with purpose-built storage and proxy infrastructure. Use Edgaze when the product is a broader AI workflow that should be visually built, publicly explained, and sold per run to humans, applications, and agents.

## Short answer

Apify has the more mature web-data runtime, Actor ecosystem, proxies, storage, and scraping tooling. Edgaze offers a broader visual AI workflow product model and a simpler buyer-facing experience for outcomes that are not primarily data extraction jobs.

## Edgaze is best for

Creators packaging multi-step AI outcomes and buyers who want to run them without managing code, [datasets](https://docs.apify.com/storage), proxy configuration, or workflow infrastructure.

## Apify is best for

Developers and data teams building or purchasing web data extraction, crawling, browser automation, and code-based Actors at scale.

## Capability grid

### Product and commerce

| Capability | Edgaze | Apify |
| --- | --- | --- |
| Public catalog of runnable products | Yes — The marketplace distributes published AI workflow products. | Yes — [Apify Store](https://docs.apify.com/actors/running/actors-in-store) distributes runnable Actors. |
| Creator monetization | Yes — Creators earn from successful paid workflow runs. | Yes — Actor developers can monetize through [pay-per-event](https://docs.apify.com/actors/publishing/monetize) and [pay-per-usage](https://docs.apify.com/actors/running/actors-in-store) models. |
| One all-in price visible before a run | Yes — The workflow's [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) is known before execution. | Different model — Actor charges can combine pricing events with compute, storage, proxy, and transfer usage. |
| No-code visual construction of the sold product | Yes — The product is assembled as a visual graph in [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio). | No — The core Actor artifact is a program built with JavaScript, Python, or Docker tooling. |
| General multi-step AI workflow as the core artifact | Yes — Models, tools, APIs, logic, and results compose into one workflow product. | Different model — Actors can automate many jobs, but Apify's deepest specialization is web scraping and browser automation. |

### Building and operation

| Capability | Edgaze | Apify |
| --- | --- | --- |
| Managed cloud execution | Yes — Edgaze operates eligible published workflow runs. | Yes — Apify provides managed Actor compute. |
| Programmatic execution API | Yes — The [Edgaze REST API](https://www.edgaze.ai/docs/api) exposes product contracts and durable runs. | Yes — The [Apify API](https://docs.apify.com/api/v2) and clients manage Actors, runs, and results. |
| MCP catalog discovery and execution | Yes — [Edgaze MCP](https://www.edgaze.ai/docs/mcp) searches and runs published workflow products. | Yes — [Apify MCP](https://docs.apify.com/integrations/mcp) searches and runs Actors and accesses results. |
| Purpose-built web-data infrastructure | Different model — Web scraping can be one block inside a broader workflow. | Yes — [Apify SDK](https://docs.apify.com/sdk), [Apify Proxy](https://docs.apify.com/proxy), [datasets](https://docs.apify.com/storage), browsers, and specialist Actors are major strengths. |
| Buyer experience hides runtime primitives | Yes — The buyer supplies published inputs and receives the intended product result. | Different model — Ready-made Actors are approachable, while advanced use often exposes [datasets](https://docs.apify.com/storage), run configuration, and usage infrastructure. |

## Where Edgaze changes the equation

### Build the product as a visual workflow

- **Edgaze:** Connect models, APIs, reusable workflows, logic, and results in [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio), then publish that graph directly.
- **Apify:** Apify's core product unit is a code-based Actor built with JavaScript, Python, Docker, or templates.

### Show one all-in workflow price upfront

- **Edgaze:** The buyer sees one [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) for the selected workflow before the run starts.
- **Apify:** Apify costs can reflect Actor events plus compute, storage, proxy, and data-transfer usage depending on the product.

### Center the experience on an AI outcome

- **Edgaze:** The public product describes the job, collects its input contract, and presents the final result without requiring data-platform concepts.
- **Apify:** [Apify Store](https://docs.apify.com/actors/running/actors-in-store) is excellent for Actors, but advanced products often surface runs, [datasets](https://docs.apify.com/storage), storage, or web-data configuration.

### Publish without maintaining an Actor build

- **Edgaze:** A tested [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) graph becomes an immutable hosted release without a Docker image or SDK project.
- **Apify:** Actor development offers deeper programmable control but normally asks the creator to own code, builds, and runtime configuration.

## Detailed comparison

| Topic | Edgaze | Apify |
| --- | --- | --- |
| Primary job | Productize and distribute multi-step AI workflows. | Build and run web scrapers, crawlers, automations, and serverless Actors. |
| Core artifact | A versioned workflow product built from connected blocks. | An Actor: a serverless program with input, execution, storage, and output contracts. |
| Marketplace | Creator workflows are sold as hosted runs with [public product page](https://www.edgaze.ai/docs/sell-everywhere)s. | [Apify Store](https://docs.apify.com/actors/running/actors-in-store) distributes Actors with [pay-per-event](https://docs.apify.com/actors/publishing/monetize) and [pay-per-usage](https://docs.apify.com/actors/running/actors-in-store) models, each documented on the Actor page. |
| Web scraping | Available as one workflow capability among models, logic, APIs, and other blocks. | A foundational strength with [Apify SDK](https://docs.apify.com/sdk) support for JavaScript and Python, [Apify Proxy](https://docs.apify.com/proxy), [datasets](https://docs.apify.com/storage), browser tooling, and specialized Actors. |
| Builder | Visual [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio) aimed at creators packaging a complete product. | Developer-oriented Actor creation with JavaScript, Python, Docker, templates, and Console tooling. |
| Pricing | One [displayed price](https://www.edgaze.ai/docs/billing/run-a-workflow) for the selected workflow run. | [Apify pricing](https://apify.com/pricing) combines prepaid platform usage with Actor-specific [pay-per-event](https://docs.apify.com/actors/publishing/monetize) or [pay-per-usage](https://docs.apify.com/actors/running/actors-in-store) charges; compute, storage, proxy, and transfer costs can affect a run. |
| API | Discover marketplace workflows and run the same published version used by buyers. | The [Apify API](https://docs.apify.com/api/v2) and clients manage Actors, runs, [datasets](https://docs.apify.com/storage), key-value stores, request queues, schedules, and results. |
| MCP | Agents search, inspect, authorize, and run published workflow products. | [Apify MCP](https://docs.apify.com/integrations/mcp) lets agents search and run Actors, access results and storage, and query Apify documentation. |
| Hosting | Managed execution for published workflow products. | Managed Actor compute plus web-data infrastructure and optional standby/server modes. |
| Best reason to choose | A clear visual product and general AI-workflow commerce surface. | Deep web-data specialization and programmable Actor infrastructure. |

## Apify is the specialist when the web is the data source

Apify is built around extracting and processing web data. Its [Apify SDK](https://docs.apify.com/sdk), managed browsers, [Apify Proxy](https://docs.apify.com/proxy), [datasets](https://docs.apify.com/storage), storage primitives, schedules, and [Apify Store](https://docs.apify.com/actors/running/actors-in-store) form a mature environment for scraping and browser automation. Edgaze should not claim parity with that specialization.

Edgaze's web-scrape block can participate in a larger AI workflow, but the platform's center of gravity is different: combine inputs, models, tools, logic, reusable workflows, and outputs, then package the full outcome as a product.

## Both have marketplaces, with different units of value

[Apify Store](https://docs.apify.com/actors/running/actors-in-store) distributes Actors and supports creator monetization through [pay-per-event](https://docs.apify.com/actors/publishing/monetize) and [pay-per-usage](https://docs.apify.com/actors/running/actors-in-store) models. It is the closest comparison in this set to Edgaze's marketplace concept.

The distinction is the artifact and buyer experience. An Actor is a programmable serverless unit often tied to [datasets](https://docs.apify.com/storage) and web-data infrastructure. An Edgaze product is a visual workflow with a buyer-facing explanation, input experience, displayed run price, and output page across marketplace, REST API, and MCP channels.

## MCP makes both catalogs available to agents

[Apify MCP](https://docs.apify.com/integrations/mcp) lets agents search for Actors, inspect input and pricing detail, run allowed Actors, and retrieve results. [Edgaze MCP](https://www.edgaze.ai/docs/mcp) similarly exposes discovery and execution, but for the same general AI workflow products sold to human marketplace buyers.

Choose based on the job behind the tool call. For a reliable scraper or crawler, start with Apify. For a broader creator-built AI outcome with visual workflow composition and a unified product page, evaluate Edgaze.

## Frequently asked questions

### Is Edgaze an Apify alternative?

Edgaze can be an alternative for general AI workflow products, but it is not a replacement for Apify's specialist scraping, proxy, browser, dataset, and Actor infrastructure.

### Does Apify have a marketplace?

Yes. [Apify Store](https://docs.apify.com/actors/running/actors-in-store) distributes Actors and supports [pay-per-event](https://docs.apify.com/actors/publishing/monetize) and [pay-per-usage](https://docs.apify.com/actors/running/actors-in-store) pricing. Edgaze's marketplace focuses on broader visually composed AI workflow products and a shared human, API, and MCP run experience.

### Which platform is better for web scraping?

Apify is generally the stronger choice for dedicated scraping, crawling, proxy management, and large-scale web-data jobs. Edgaze can include scraping as one step inside a wider AI workflow.

### Can agents run products from both platforms?

Yes. Both publish MCP capabilities for catalog discovery and execution. Their catalogs differ: Apify exposes Actors, while Edgaze exposes published workflow products.

### Which is easier for a non-developer buyer?

Edgaze is designed around a product page and input-to-result run experience. Apify also offers ready-made Actors, but many advanced use cases assume familiarity with [datasets](https://docs.apify.com/storage), run configuration, or developer tooling.

## Sources

- [Edgaze: sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Edgaze: managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Edgaze pricing](https://www.edgaze.ai/pricing)
- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Edgaze REST API](https://www.edgaze.ai/docs/api)
- [Edgaze Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio)
- [Edgaze run pricing and billing](https://www.edgaze.ai/docs/billing/run-a-workflow)
- [Apify pricing](https://apify.com/pricing)
- [Actors in Apify Store](https://docs.apify.com/actors/running/actors-in-store)
- [Apify MCP server](https://docs.apify.com/integrations/mcp)
- [Monetize Actors](https://docs.apify.com/actors/publishing/monetize)
- [Apify Actor usage and resources](https://docs.apify.com/actors/running/usage-and-resources)
- [Apify SDK](https://docs.apify.com/sdk)
- [Apify Proxy](https://docs.apify.com/proxy)
- [Apify storage](https://docs.apify.com/storage)
- [Apify API](https://docs.apify.com/api/v2)

Last reviewed: September 14, 2026


---

---
title: AI Workflows for Agents | Discover and Run with Edgaze
description: Give AI agents a catalog of published Edgaze workflows they can discover, inspect, and run with clear inputs, pricing, authorization, and durable results.
source: https://www.edgaze.ai/use-cases/ai-agents
last_reviewed: September 13, 2026
type: use-case
---

# Give AI agents workflows that already know how to do the job

An agent should not rebuild every specialized process from a prompt. Edgaze lets it search a [marketplace](https://www.edgaze.ai/marketplace) of published workflows, inspect the exact input contract and price, run the right product, and follow the result to completion.

## What this enables

Most agents are good at deciding what should happen next and much less reliable at reconstructing a specialist process while a user waits. A creator-built Edgaze workflow gives the agent a finished operating path: the prompts, models, tools, branches, input limits, and final result have already been designed and tested. The same published product can serve a person on its [marketplace](https://www.edgaze.ai/marketplace) page, an application through the [REST API](https://www.edgaze.ai/docs/api), and an AI agent through [Edgaze MCP](https://www.edgaze.ai/docs/mcp), so the useful part of the system is maintained once instead of being copied into three integrations.

That changes the agent's job from improvising a workflow to choosing and operating one responsibly. It starts with the user's desired outcome, searches the [marketplace](https://www.edgaze.ai/marketplace) in those words, and inspects a promising product before proposing execution. Inspection supplies the real field names, examples, price, and demo availability, which means the agent can ask only for information that is actually missing. Sign-in, [wallet funding](https://www.edgaze.ai/docs/mcp/wallet), and approval of a paid price stay visible to the user. Once accepted, the agent starts one durable run, waits at the interval returned by the service, and delivers readable text in the conversation or an [Edgaze run URL](https://www.edgaze.ai/runs) when the result is a file, image, video, or other rich asset.


## Give an agent its first workflow

The shortest responsible path is to connect the hosted server, verify that its five tools are present, and use a real request to test discovery before testing payment. This proves the client, authorization, product contract, and run lifecycle separately, so an empty wallet or an unsuitable search result is not mistaken for a broken connection.

Add https://mcp.edgaze.ai as a remote HTTP server in the AI client, complete the browser OAuth flow with the Edgaze account that should own the runs, and confirm that catalog, search, inspect, run, and watch are all available. [Open connection guide](https://www.edgaze.ai/docs/mcp/connect).

Give the agent an outcome rather than a guessed product slug. Let it browse the public catalog, stop honestly when search reports no match, and inspect one candidate's current input schema, displayed price, and demo state before asking you for data. [Browse workflows](https://www.edgaze.ai/marketplace).

For the first execution, follow catalog, search, inspect, run, and watch in order. Use the inspected field names, set a maximum accepted cost at or above the quoted price, and never create a second run merely because a watch call returned no new output. [Follow the first-run guide](https://www.edgaze.ai/docs/mcp/first-run).

If inspection says a free demo is available, use it only when the user wants that path; it is a real run, not a canned preview. For paid work, add wallet funds after the exact price is known, then retry the intended run without reconnecting the MCP server. [Understand MCP funding](https://www.edgaze.ai/docs/mcp/wallet).


## A marketplace is more useful than an uncurated tool pile

Giving an agent more tools does not automatically give it more useful capability. A large set of low-level actions forces the model to choose the right tool, infer the order, translate data between steps, recover from partial failure, and decide what counts as a finished answer—all inside the user's conversation. That is exactly where seemingly capable agents become inconsistent: the plan is rebuilt on every attempt, and small changes in context can produce a different sequence.

A published workflow compresses that operational knowledge into a product with a name, a specific job, a typed input contract, an immutable version, a visible price, and a deliberate result. The agent still decides whether the product fits the request, but it does not have to rediscover how to perform the underlying work. A research workflow, for example, can own its retrieval, ranking, synthesis, and output formatting while the agent concentrates on gathering the right brief and presenting the answer well.

This also creates a cleaner maintenance boundary. The creator can improve prompts, switch supported models, repair an integration, or publish a new version without asking every agent developer to reproduce the change in a tool definition. The agent calls a stable product identity and inspects the live contract before use. That is more dependable than hiding a long chain of instructions in a system prompt and hoping every client executes it the same way.

## Selection and payment should be inspectable

An agent should be able to explain why it chose a workflow before it spends money or sends sensitive input. Edgaze separates discovery from execution for that reason. Search answers the broad question—what products appear relevant—while inspect returns the selected workflow's accepted fields, examples, access state, displayed price, and whether a demo is available. If there is no match, the correct behavior is to say so and continue with another method, not to invent a slug that sounds plausible.

The same discipline applies to input collection. The agent should reuse information the person already supplied, map it to the published schema, and ask only for required values that are still absent. Unknown keys and conflicting aliases should be treated as errors rather than silently ignored. This makes the run reproducible and gives the user a chance to notice when the requested data is too broad, too sensitive, or simply unrelated to what the workflow promises.

Commercial intent remains equally explicit. A zero wallet balance is a normal account state, not a failed installation. A [free demo](https://www.edgaze.ai/docs/billing/run-a-workflow) is available only when inspection says the product qualifies, and it runs the actual published workflow with the user's input without charging the wallet or paying the creator. A paid run should begin only after the agent has shown the current price and the user has chosen to proceed. Wallet funding belongs to the user's Edgaze account and does not require rebuilding or reconnecting the agent integration.

- No invented workflow slugs or guessed input names.
- No paid run before the price and required inputs are known.
- No second agent-only copy of the workflow to maintain.

## The run should outlive the conversation turn

Useful workflow products often take longer than a normal tool call. They may coordinate several models, fetch external pages, call third-party APIs, repeat work over a list, pause between steps, or produce a large media file. Edgaze gives each execution durable state, so the agent does not need to hold one browser tab or request open and pretend that silence means failure. It starts the run once, retains the run identifier and cursor, and uses watch until the service reports a terminal outcome.

Watching is intentionally different from retrying execution. When a watch returns no new output, the agent waits for the supplied polling interval and watches the same run again. It should not create a duplicate paid run for the same request. This distinction matters in real products, where network interruptions and long model latency are ordinary and where a repeated execution can create a second external action or charge.

Result presentation is part of the contract too. Text and markdown can be turned into a useful answer in the chat instead of dumping raw JSON. If the workflow sends an email, opens a ticket, or publishes a post, the agent can describe the action and include the confirmation data returned by the workflow. Images, video, files, and other media are better served through the durable [Edgaze run URL](https://www.edgaze.ai/runs), where the owner can view or download the output without forcing binary content through the conversation.

## Frequently asked questions

### How do AI agents find Edgaze workflows?

After [Edgaze MCP](https://www.edgaze.ai/docs/mcp) is connected, an agent can browse categories or search the published catalog, then inspect a workflow's description, inputs, price, and availability before running it.

### Can an agent spend money without asking?

The MCP flow is designed to keep authentication, funding, price visibility, and the user's paid-run intent explicit. Implementations should not start a paid run before showing the price.

### Does the creator build a separate MCP tool?

No. The same published workflow product is available to [marketplace](https://www.edgaze.ai/marketplace) buyers, [REST API](https://www.edgaze.ai/docs/api) callers, and MCP-connected agents.

### What happens when an agent-run workflow takes a long time?

The run has durable state. The agent can poll or watch progress and return after completion rather than keeping one synchronous request open.

### Can an agent show image or file results?

The agent can share the Edgaze run page for output that is better viewed or downloaded outside the chat, while returning plain text directly when appropriate.

## Sources

- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Your first MCP run](https://www.edgaze.ai/docs/mcp/first-run)
- [Sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Managed execution](https://www.edgaze.ai/docs/managed-execution)

Last reviewed: September 13, 2026


---

---
title: AI Workflow API | Run Marketplace Workflows with Edgaze
description: Discover and run published AI workflows through one REST API with typed inputs, asynchronous execution, spend controls, event history, and signed webhooks.
source: https://www.edgaze.ai/use-cases/workflow-api
last_reviewed: September 13, 2026
type: use-case
---

# Call finished AI workflows through one API

Use the Edgaze REST API when your application needs a complete creator-built workflow rather than another low-level model endpoint. Discover a product, read its live input schema and price, start an asynchronous run, and consume the result through polling, events, or webhooks.

## What this enables

The [workflow API](https://www.edgaze.ai/docs/api) is useful when your product needs a completed process, not another raw model response. A published workflow can already contain the input form, prompts, model choices, tool calls, branches, retries, and output selection that turn a capability into a repeatable result. The API runs the same immutable workflow version available on the marketplace, under the same input, funding, execution, and failure rules, so an integration does not create a private fork that quietly drifts away from the product a buyer can inspect.

A production integration begins with a scoped secret and the live workflow contract. Your application fetches the selected product immediately before execution, validates against its current input schema, and starts one asynchronous run with an idempotency key that represents the business action. A 202 response means the request was accepted, not completed, so the application stores the run identifier and follows canonical status. Simple clients can poll every one to three seconds; richer products can read ordered events or accept signed webhooks. Only a terminal run should trigger downstream delivery, accounting, or user-facing success.


## Ship one workflow API integration

Start with one workflow and one narrow user journey. Wire the integration around the live contract and durable run identifier before adding background scheduling or a catalog browser. That gives you a correct execution path first and makes retries, spending, and completion behavior visible in development.

Issue a secret in the Developer console, give it only the scopes the service needs, and set spend boundaries that match the environment. Keep the plaintext in a secrets manager because Edgaze shows it only once and a leaked key should be revoked rather than recovered. [Open API keys](https://www.edgaze.ai/developer/keys).

Set the bearer token against the documented production base URL and make a small authenticated discovery request before integrating a workflow. Treat 401, insufficient scope, and entitlement errors as different operational problems rather than retrying every response. [Start the API quickstart](https://www.edgaze.ai/docs/api/quickstart).

Fetch the live input schema immediately before the POST, validate locally, and send a stable Idempotency-Key for the logical request. Store the returned run id and status URL; reusing the same key with the same request retrieves the original acceptance rather than creating another billable run. [See the create-run contract](https://www.edgaze.ai/docs/api/create-run).

Poll canonical status for a simple client, or verify the raw body and HMAC signature of a webhook before updating downstream systems. Webhook delivery is at least once and ordering is not guaranteed, so deduplicate on the delivery id and reconcile missed terminal runs when correctness depends on it. [Configure webhooks](https://www.edgaze.ai/docs/api/webhooks).


## The abstraction is a product, not a model call

A model API exposes a general capability and leaves the surrounding product work to your team. You still have to define the prompt, choose tools, validate input, sequence calls, recover from failures, decide which intermediate value is the answer, and operate that logic after launch. A [workflow API](https://www.edgaze.ai/docs/api) moves that configured process behind one product contract. This is most valuable when the workflow creator has real domain knowledge or when the process is involved enough that reproducing it would become a small application of its own.

That does not mean treating a workflow as an opaque magic endpoint. Before the first production run—and again whenever the active version may have changed—fetch the workflow detail. It exposes the current input schema, pricing, provider and credential requirements, version state, and whether the caller is entitled to execute it through the API. Build the request from that schema; there is no universal field such as topic, and unknown keys are rejected so a misspelling does not silently degrade the result.

The public product page provides a useful human companion to the machine contract. A product manager or customer can inspect what the workflow claims to do, while the backend resolves the exact schema and version used for execution. Because [marketplace runs](https://www.edgaze.ai/marketplace) and programmatic runs share the same engine, funding rules, and immutable versions, the explanation shown to a buyer and the operation called by code stay connected.

## Design for acceptance, progress, and completion

POST /runs returns 202 Accepted with a run id and polling URLs after the request passes synchronous checks. That response is evidence that Edgaze accepted the work; it is not evidence that the work succeeded. The run can still finish, fail, be cancelled, lack wallet funding after acceptance, or stop at a compute limit. A correct UI therefore moves from submitted to running and only shows success after GET /runs/{id} or a verified terminal event reports completion.

Polling is often enough for a first integration. Store the run id beside your own job or customer record, query status every one to three seconds while the user is waiting, and back off or move the work to a background process when the request outlives the screen. Ordered run events add step-level visibility for a dashboard or support investigation. Webhooks are better when the application should react without keeping a poller alive, but they require signature verification against the exact raw request bytes, replay protection, and idempotent handling.

Network ambiguity is a billing problem as well as a reliability problem. Every new integration should send an idempotency key for each logical run. Repeating the same workflow, normalized inputs, and version under that key returns the original accepted run; changing the request under the same key returns a conflict. A failed run remains the result of that key, so a deliberate second execution requires a new key. This prevents an ordinary client timeout from becoming duplicate work, duplicate external side effects, or a second charge.

## Make cost, access, and version drift explicit

A scoped key can have separate execute and read permissions, plus optional daily, monthly, or lifetime spend caps. Those controls solve different problems: scope limits what a leaked or misused key can do, while a spend cap limits the economic exposure. A cap can reject a run before it starts, but it does not replace checking the workflow's current displayed price or maintaining enough wallet or eligible bundle funding for the accepted version.

[Version pinning](https://www.edgaze.ai/docs/billing/version-pinning) is equally important for integrations that parse outputs or automate consequential work. Every API run resolves to one immutable version: an explicit entitled version, the caller's pinned access, or the current active version in that order. Workflow detail exposes pinnedVersionId, activeVersionId, and updateAvailable so the application can detect drift. When an update is available, review the new input and output shapes before accepting it; publishing a new creator version should not silently change a buyer who is pinned to an older contract.

Finally, code should model the documented terminal outcome rather than infer billing from the initial POST. Successful paid runs settle the displayed price. Ordinary failures and cancellations do not keep the creator margin, while a run stopped at its compute limit is shown separately because already-consumed compute may remain. Keeping run status, charge information, and a human-readable failure reason together gives support and finance teams something concrete to audit when a workflow does not end as expected.

## Frequently asked questions

### What can I do with the Edgaze workflow API?

You can list available workflows, inspect a workflow and its input schema, create an asynchronous run, list or fetch runs, read run events, cancel eligible runs, and receive signed lifecycle webhooks.

### Is the API synchronous?

No. Run creation is asynchronous and returns a run identifier. Use polling, events, streaming where supported, or webhooks to observe completion.

### How do I prevent duplicate workflow runs?

Send a stable idempotency key when creating a run. A retry with the same logical key can be resolved without blindly creating a second run.

### Can I limit API spending?

API keys can carry daily, monthly, or lifetime spend caps. The platform checks the cap before issuing a run when applicable.

### Do API runs cost more than marketplace runs?

The API uses the same displayed workflow price and funding rules for the published version. Callers should fetch current workflow detail rather than rely on a stale cached quote.

## Sources

- [Edgaze REST API](https://www.edgaze.ai/docs/api)
- [Create a run](https://www.edgaze.ai/docs/api/create-run)
- [API webhooks](https://www.edgaze.ai/docs/api/webhooks)
- [Sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)

Last reviewed: September 13, 2026


---

---
title: MCP Workflows | Connect AI Agents to Edgaze
description: Connect supported AI clients to Edgaze MCP so agents can search, inspect, demo, purchase, run, and monitor published workflow products.
source: https://www.edgaze.ai/use-cases/mcp-workflows
last_reviewed: September 13, 2026
type: use-case
---

# Turn the Edgaze marketplace into an agent-ready tool catalog

Edgaze MCP gives supported AI clients a structured way to discover and run marketplace workflows. The protocol connection exposes product context, inputs, access state, price, execution, and durable status without requiring each creator to ship a separate server.

## What this enables

MCP makes the marketplace legible to an AI client without flattening every workflow into a generic function call. Connect one remote server and the agent can discover an evolving catalog, read the exact contract for a selected product, show the user what it costs, run it, and follow durable execution to a useful result. The creator does not have to operate a separate MCP server, duplicate the graph, or rebuild authentication and billing for each client; the protocol surface points back to the same published workflow that people can inspect and run on Edgaze.

The server exposes five deliberately narrow tools. Catalog provides a category map when the request is vague; search looks for a workflow using the user's goal; inspect resolves one slug into real fields, examples, price, and demo availability; run creates the accepted execution; and watch follows that same run until terminal. This order is part of the safety model. The agent can stop when no product matches, avoid fabricated fields, keep payment visible, and distinguish waiting from starting over. Textual results can return in chat, while files and rich media remain available on the durable [Edgaze run page](https://www.edgaze.ai/runs).


## Connect an MCP client in minutes

The public server is https://mcp.edgaze.ai and the transport is remote HTTP. The client starts OAuth and the user approves permission to find and run workflows. There is no local package to launch, and copying an API key or adding a custom Authorization header creates the wrong setup.

Choose the exact client below because configuration keys and file locations differ, add the server as edgaze, and finish the browser-based authorization flow that the client starts. Do not open a bare consent URL manually; it will not contain a sign-in request. [See every client setup](https://www.edgaze.ai/docs/mcp/connect).

Confirm that edgaze_catalog, edgaze_search, edgaze_inspect, edgaze_run, and edgaze_watch are visible. Then ask the client to list catalog categories or search for a concrete outcome before attempting execution; an empty wallet does not mean installation failed. [Run the verification sequence](https://www.edgaze.ai/docs/mcp/first-run).

Inspect one search result and confirm the workflow slug, required fields, examples, displayed price, and demo_available value. Fill accepted inputs from the conversation and ask for anything essential that remains missing instead of inventing a value the form does not accept. [Review the inspect step](https://www.edgaze.ai/docs/mcp/first-run#the-loop).

For a paid run, show the inspected price and set max_cost_usd to the amount the user accepted. If funding is insufficient, send the user to the Edgaze wallet, wait for the balance to update, and retry the intended run without deleting or recreating the server. [Read wallet guidance](https://www.edgaze.ai/docs/mcp/wallet).


## MCP is the interface; the workflow is the product

MCP standardizes how a client discovers and invokes tools, but it does not make an underspecified tool useful. The value still comes from what sits behind the protocol: a clear job, an input contract, tested workflow logic, a versioned execution graph, an understandable price, and an output the user can act on. Edgaze treats those elements as the workflow product, while MCP is one interface through which that product can be selected and operated.

That distinction is important for creators. A creator builds and tests in [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio), defines what the buyer provides, chooses the result that should be published, and releases an immutable version. Edgaze can expose the eligible product through its [hosted Edgaze MCP surface](https://www.edgaze.ai/docs/mcp) without asking the creator to implement remote transport, OAuth consent, catalog search, tool schemas, wallet checks, run monitoring, and media delivery as separate infrastructure.

It is also important for users because the product has a public identity outside the conversation. A person can review the marketplace listing and its examples, then let the agent execute the same version. The agent receives the product contract and run tools, not the creator's editable graph or intellectual property. This preserves a clean boundary between buying an outcome and acquiring the system that produces it.

## The five-tool sequence prevents expensive guessing

Catalog and search are intentionally separate from execution. Catalog is useful when the person has a broad need and the agent needs to understand what kinds of products exist. Search uses the person's goal in their own words and returns candidates. If search returns no_match, the agent should stop searching Edgaze and use another capability; repeatedly changing the query until something vaguely related appears is not successful discovery.

Inspect is the decision point. It turns one workflow slug into the fields the product actually accepts, example values, the current displayed price, and whether a demo is available. The agent should show that information in ordinary language, reuse details already present in the conversation, and ask only for schema-required values that are missing. It should not manufacture a plausible slug, add an unrecognized parameter, or conceal the price inside a tool call.

Run and watch then operate one accepted execution. max_cost_usd is a ceiling at or above the inspected price, not permission to spend an unknown amount. Watch uses the returned run_id and cursor; after an empty read, the agent waits poll_after_ms and tries the same watch again. Starting a second run because the first is still working is both logically wrong and potentially billable. The sequence makes those boundaries clear enough for an agent to follow and for a person to audit.

## Authentication, demos, and results stay human-readable

Edgaze MCP uses browser OAuth so the person connects an Edgaze account and approves two understandable capabilities: finding workflows and running them. The client, not a copied consent link, initiates that flow. The configuration should contain the server URL and the transport syntax required by the client, but no Edgaze API key, bearer token, or homemade authorization header. Disconnecting the app later removes that connection without requiring a creator to change the workflow.

A [free demo](https://www.edgaze.ai/docs/mcp/first-run#demo) is a genuine run of the published workflow using the person's inputs. It is not a video or static sample, it does not debit the wallet or pay the creator, and it should only be requested when inspect reports that a demo is available. For normal paid execution, the agent quotes the price first. If the wallet cannot cover it, the useful response is a wallet link and a clear instruction to retry after funding—not a vague authentication error or a second MCP configuration.

The final handoff should match the output. When present is chat, the agent should render text or markdown as a readable answer and describe external actions such as a sent email or created ticket with any returned confirmation details. When present is edgaze_page, the result is better viewed outside chat; the agent provides the [Edgaze run page](https://www.edgaze.ai/runs) for images, video, files, or downloads. Raw JSON, base64, and binary payloads are implementation details, not a user experience.

## Frequently asked questions

### What is an MCP workflow?

It is a workflow an AI client can discover and invoke through the Model Context Protocol. On Edgaze, the MCP tool points to the same published product available on the marketplace and API.

### Do creators need to build their own MCP server?

No. Eligible published workflows are exposed through the [hosted Edgaze MCP surface](https://www.edgaze.ai/docs/mcp), so creators maintain the workflow product rather than separate protocol infrastructure.

### Which AI clients can connect to Edgaze MCP?

Edgaze publishes setup guidance for clients including ChatGPT, Codex, Claude, Cursor, VS Code, Devin Desktop, OpenCode, and other MCP-compatible clients. Support can vary by client version.

### Can MCP run paid workflows?

Yes, subject to authentication, access, wallet or bundle funding, the displayed product price, and explicit user intent before a paid run.

### Does MCP expose the creator's editable graph?

No. The agent receives the product contract and tools needed to discover and run it, not the creator's private editing surface.

## Sources

- [Edgaze MCP](https://www.edgaze.ai/docs/mcp)
- [Your first MCP run](https://www.edgaze.ai/docs/mcp/first-run)
- [Sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [Run a workflow](https://www.edgaze.ai/docs/billing/run-a-workflow)

Last reviewed: September 13, 2026


---

---
title: Hosted AI Workflows | Publish Without Running Infrastructure
description: Build and publish hosted AI workflows while Edgaze operates scheduling, execution, retries, progress, usage records, billing, and result delivery.
source: https://www.edgaze.ai/use-cases/hosted-ai-workflows
last_reviewed: September 13, 2026
type: use-case
---

# Publish an AI workflow without becoming its infrastructure team

Edgaze hosts the execution path for published workflows. Creators design and maintain the product; the platform schedules runs, coordinates supported models and tools, records progress, applies platform retry behavior, and settles successful paid execution.

## What this enables

A workflow becomes much harder to ship when the creator must also build the queue, worker fleet, retry logic, status model, usage ledger, checkout path, and result page around it. Edgaze lets the creator move from a tested graph to a runnable public product without assembling that entire operational shell. The [managed runtime](https://www.edgaze.ai/docs/managed-execution) executes the published version, records progress, makes results available after the initiating session ends, and connects successful execution to the same marketplace, API, MCP, funding, and run-history surfaces buyers already use.

The useful path begins with product discipline rather than infrastructure. Build the smallest complete input-to-result graph in [Workflow Studio](https://www.edgaze.ai/docs/builder/workflow-studio), test it with realistic buyer data, and make sure the Result block contains the thing the listing promises. At publish time, define an honest description, input envelope, credential mode, examples, and creator margin. Publishing creates an immutable version that Edgaze can run across the marketplace, [REST API](https://www.edgaze.ai/docs/api), and MCP. Later edits become a new version, which lets the creator improve the workflow without silently rewriting the contract of every existing run or pinned buyer.


## Take a workflow from graph to product

Begin with a result a stranger can recognize and work backward to the minimum input needed to produce it. A compact, observable first version is easier to test, price, explain, and support than an ambitious graph whose failure can only be described as something went wrong.

Create a graph with explicit Ask for Input and Result blocks before adding branches, loops, or external services. Give every connection an obvious purpose and use plain input labels so the published form can stand on its own without creator guidance. [Open Workflow Studio](https://www.edgaze.ai/builder).

Use realistic test data, inspect the order in which blocks complete, and verify that no key, token, provider response, or internal configuration leaks into output or logs. Builder tests are free, so exercise empty, maximum-size, and failure-prone inputs before publishing. [Read the Studio guide](https://www.edgaze.ai/docs/builder/workflow-studio).

Design the buyer experience around durable work rather than one browser request. Choose meaningful Result values, expect supported retries and provider failover to affect timing, and make the listing honest about third-party dependencies that Edgaze cannot control. [Understand the runtime](https://www.edgaze.ai/docs/managed-execution).

Publish with a truthful title, tested examples, an input envelope that covers the promised job, a deliberate credential mode, and a price that a buyer can evaluate before running. The same immutable product can then reach people, applications, and agents without a channel-specific graph. [Plan distribution](https://www.edgaze.ai/docs/sell-everywhere).


## Managed execution covers the run lifecycle

A published graph may combine input forms, model calls, tools, [external APIs](https://www.edgaze.ai/docs/builder/nodes/http-request), conditions, merges, repeats, delays, and final outputs. Running that graph reliably means more than evaluating nodes in order. The system has to accept the job, select the immutable version, preserve its state, record progress, handle supported retry or failover behavior, and make the result available even if the buyer closes the page. The [managed runtime](https://www.edgaze.ai/docs/managed-execution) owns that execution path for eligible marketplace, API, and MCP runs.

Durable status is what makes the workflow usable as a product rather than a browser demo. Buyers see live progress in the run panel and can return through run history. Developers can poll canonical state, read ordered events, or use the optional stream and signed webhooks. Agents can start a run and watch it to terminal. Those surfaces differ, but they point to one execution record and one result instead of creating incompatible copies of the same job.

The runtime also connects execution to commercial state. It determines whether a matching bundle or wallet can fund the run, reserves the displayed amount where required, records usage, settles successful execution, and releases ordinary charges when a run fails or is cancelled. That is difficult infrastructure to reproduce correctly because it must agree with the run's actual terminal state, not merely the fact that a buyer clicked Run.

## Managed does not mean responsibility-free

Edgaze operating the runtime does not transfer product judgment to the platform. The creator still owns the graph, prompts, tool configuration, input design, product claims, pricing margin, and legal or domain-specific suitability of the workflow. If the listing needs an external provider, the creator must choose and disclose the supported credential mode. If it makes consequential recommendations, the creator must set realistic expectations and design output that invites the right level of human review.

Credential mode deserves particular care. Edgaze-hosted execution includes applicable hosted compute in the displayed price. Creator-connected execution uses encrypted creator Vault keys and bills that provider usage to the creator. Buyer-brings-keys requires each eligible runner to supply the required Vault credentials and places provider charges with the buyer. A non-hosted listing does not silently fall back to Edgaze credentials when a required key is missing, so the product page should make the dependency obvious before a run begins.

Third-party systems remain third-party systems. A model can change behavior, an external API can reject a request, and a scraped source can disappear. Supported retries and model failover can improve resilience, but they cannot guarantee the correctness of creator-authored logic or the availability of every provider. A premium workflow is honest about these boundaries, produces useful error messages, and avoids claims that infrastructure alone cannot support.

## Hosting is connected to distribution

The [managed runtime](https://www.edgaze.ai/docs/managed-execution) is not a generic background-job service detached from the product. It sits behind [marketplace discovery](https://www.edgaze.ai/marketplace), the public listing, the [REST API](https://www.edgaze.ai/docs/api), MCP, wallet and bundle funding, run history, and buyer-facing result presentation. A creator can therefore publish one product identity and meet different kinds of demand without turning each distribution channel into a separate engineering project.

For a human buyer, the listing explains the outcome and collects the published inputs. For an application, the API exposes the same schema and immutable version in a machine-readable form. For an agent, MCP supplies a discovery-and-execution sequence around the same product. Successful execution uses the same pricing and settlement rules across those surfaces. This is what allows improvements to compound: the creator maintains the workflow and its public contract once while each channel benefits from the next release.

The approach is especially useful for an independent creator or small team that has a strong process but does not want to build a conventional SaaS wrapper before testing demand. It does not remove the need to make a good product. It removes a large amount of undifferentiated runtime and commerce work so the creator can spend more time on whether the workflow produces a result worth buying.

## Frequently asked questions

### What does Edgaze host for a workflow?

Edgaze operates the supported execution path, including scheduling, graph execution, durable status and events, usage records, [billing settlement](https://www.edgaze.ai/docs/billing), and result availability for eligible published runs.

### Do I need to run my own queue workers?

No for workflows executed through Edgaze's managed marketplace, API, and MCP surfaces. The platform operates its runtime infrastructure.

### Who maintains the workflow?

The creator maintains the graph, prompts, integrations, product copy, input limits, and credential configuration. Edgaze maintains the platform runtime.

### Are failed hosted runs charged?

Under the current Edgaze rules, failed or cancelled paid runs do not keep the creator margin, and demos and builder test runs are not billed. Consult the billing documentation for exact edge cases.

### Can a hosted workflow use external APIs?

Yes, where the workflow and credential mode support them. External services remain third-party dependencies with their own availability, policies, and possible charges.

## Sources

- [Managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Sell to humans and agents](https://www.edgaze.ai/docs/sell-everywhere)
- [When runs fail](https://www.edgaze.ai/docs/billing/when-runs-fail)
- [Edgaze pricing](https://www.edgaze.ai/pricing)

Last reviewed: September 13, 2026


---

---
title: Long-Running AI Workflows | Durable Execution with Edgaze
description: Run asynchronous AI workflows with durable status, progress events, cancellation, webhooks, and results that remain available after the initiating request ends.
source: https://www.edgaze.ai/use-cases/long-running-workflows
last_reviewed: September 13, 2026
type: use-case
---

# Let the workflow keep running after the request is gone

Long AI workflows should not depend on one open browser tab or a fragile request timeout. Edgaze creates durable run state so applications, agents, and marketplace buyers can leave, return, watch progress, and retrieve the final outcome.

## What this enables

Long-running work becomes reliable when execution is treated as a lifecycle rather than one HTTP response that must remain open until every model, tool, and external service has finished. Edgaze gives each run a durable identity, canonical status, ordered events, explicit terminal outcomes, and a result that remains available after the initiating request or browser session ends. That lets a product acknowledge work immediately, show meaningful progress, recover from a lost connection, and complete the same run instead of accidentally starting another one.

The caller submits schema-valid input, receives an accepted run identifier, and stores it beside its own user or job record. Edgaze can continue through model calls, external APIs, loops, delays, and supported retries while status and step events accumulate on that run. A foreground interface can poll while the user waits; a backend can use [signed webhooks](https://www.edgaze.ai/docs/api/webhooks) to react after the original request is gone; and support tooling can query the same canonical record later. The integration only declares success when the run reaches completed, and it treats failure, cancellation, and a compute-limit stop as distinct outcomes with their own billing and recovery behavior.


## Build around a durable run

The embedded Blog to Thread workflow makes the lifecycle concrete: one submitted source can move through several transformations before a final result exists. Use a graph like this to test what your product shows at acceptance, during quiet periods, and at every terminal outcome—not only the happy path.

Open the embedded Blog to Thread template below and inspect how one input becomes a multi-stage result. Reuse it when useful, but first identify which events and final output your own interface needs so the graph and product language agree. [Use the template](https://www.edgaze.ai/templates/blog-to-thread).

Resolve the current input schema, submit valid fields with an idempotency key, and keep the returned run identifier instead of waiting for the whole workflow in one request. A 202 response means accepted, so do not show the job as finished at that point. [Read the creation contract](https://www.edgaze.ai/docs/api/create-run).

Fetch the run itself whenever the product needs authoritative status, timestamps, output, charge information, or terminal failure detail. Use the ordered event feed for step-level progress, but let the run record remain the source of truth for final state. [See the run response](https://www.edgaze.ai/docs/api/get-run).

Verify webhook signatures against the exact raw body before parsing, reject stale timestamps, and deduplicate on the delivery id. Delivery is at least once and ordering is not guaranteed, so make downstream handlers idempotent and reconcile terminal runs if a missed event would create a correctness gap. [Implement webhooks](https://www.edgaze.ai/docs/api/webhooks).


[Open the embedded workflow template](https://www.edgaze.ai/templates/blog-to-thread)

## Asynchronous execution is the honest contract

Research, scraping, media generation, external API work, repeated transformations, and deliberate delays can exceed normal request windows even when nothing is wrong. Trying to hide that reality behind a long-held synchronous request creates brittle behavior: proxies time out, mobile connections disappear, users refresh the page, and the caller cannot tell whether the work stopped or merely became unreachable. A durable run makes acceptance and completion separate, observable events.

The [public API](https://www.edgaze.ai/docs/api) reflects that model directly. POST /runs validates the request and returns 202 with a run id and status URLs. The product stores that id and can query GET /runs/{id} until the workflow reaches a terminal state. Marketplace buyers and MCP-connected agents use different interfaces, but they rely on the same underlying lifecycle. Closing a browser or ending a chat turn does not erase the execution record or make a fresh run necessary.

This separation matters most when the workflow has financial value or external side effects. An email campaign, research report, generated video, or batch of tickets should not be repeated simply because the initiating connection timed out. An idempotency key prevents an ambiguous retry of the same request from creating a second billable execution. If the first run genuinely fails and the user wants another attempt, the application creates a new key so the intent to execute again is explicit.

## Progress should answer useful questions

A spinner only says that the interface is waiting. Ordered [durable event records](https://www.edgaze.ai/docs/api/list-events) can say when the run started, which supported step progressed, and which terminal event ended the execution. Each event carries a monotonic sequence number and timestamp, so a client can request the next page after the last sequence it processed. That makes it possible to build a progress view, a support timeline, or a debugging surface without treating transient client state as the system of record.

Choose the delivery mechanism according to the user experience. Polling every one to three seconds is straightforward while a person is actively watching. Events add step-level context. Optional streaming can improve immediacy while the connection is healthy. Signed webhooks are appropriate when a backend must react after the foreground request has ended. None of these should create a second notion of status: the canonical run response remains the authoritative place to read terminal state and output.

Good interface copy should tell the user that they may safely leave and return, then make the run easy to find in history. It should also distinguish quiet from stuck. A workflow can spend time inside a provider or a long node without emitting a constant stream of updates. The application can show the last known event and elapsed time honestly rather than manufacturing progress percentages that the runtime never supplied.

## Terminal states keep billing understandable

Completion, failure, and cancellation are explicit terminal outcomes, and billing follows the outcome rather than the click that started the job. A successful wallet-funded run settles the displayed price, while a successful bundle-funded run consumes one matching prepaid run. Ordinary failures and cancellations do not keep the creator margin or consume a bundle run. Demos and builder tests remain free regardless of outcome.

A run stopped at its compute limit is deliberately shown separately from an ordinary failure because work already consumed may remain charged. Applications should preserve that reason rather than reducing every non-success state to failed. The same is true for an invalid input or spend cap rejected before execution: those are request-time problems and should lead the user back to a field or funding decision, not to a generic retry loop.

Cancellation is also a real state transition, not proof that every provider operation vanished instantly. A product can request cancellation for an eligible in-flight run, then observe the recorded terminal state and present its documented billing outcome. For results that finish after a person leaves, surface the [Edgaze run URL](https://www.edgaze.ai/runs) alongside your own notification so there is a durable place to inspect the output and its history later.

## Frequently asked questions

### What is a long-running AI workflow?

It is an execution that may continue beyond a normal browser interaction or HTTP request because it coordinates multiple models, tools, APIs, loops, or delays.

### Do I need to keep the browser open?

No. Edgaze persists the run and its state so users can leave and return through run history or the run page.

### How does an API know when a run finishes?

It can poll run status, read durable events, use supported streaming, or receive a signed webhook for lifecycle changes.

### Can a long-running workflow be cancelled?

Eligible in-flight runs can be cancelled through supported product or API controls. Cancellation is recorded as a terminal state.

### What happens if a run fails?

The run records a failure state and buyer-facing reason where available. Current billing rules do not keep creator margin for failed or cancelled paid runs.

## Sources

- [Managed execution](https://www.edgaze.ai/docs/managed-execution)
- [Create a run](https://www.edgaze.ai/docs/api/create-run)
- [API webhooks](https://www.edgaze.ai/docs/api/webhooks)
- [When runs fail](https://www.edgaze.ai/docs/billing/when-runs-fail)

Last reviewed: September 13, 2026


---

---
title: Buy AI Workflows | Discover and Run on Edgaze
description: Browse creator-built AI workflow products, inspect what each run needs and costs, try eligible demos, and pay for successful hosted outcomes on Edgaze.
source: https://www.edgaze.ai/use-cases/buy-ai-workflows
last_reviewed: September 13, 2026
type: use-case
---

# Buy the workflow outcome instead of rebuilding the system

Edgaze lets buyers discover complete AI workflow products. Each strong listing explains the job, required inputs, creator, credential mode, expected result, and visible run price before execution begins.

## What this enables

Buying a workflow should mean paying for a repeatable outcome, not receiving a prompt file and a list of services you still have to assemble. On Edgaze, a published product brings its input contract, immutable execution version, credential requirements, displayed price, and hosted result together. A buyer can move from discovery to a real run without copying prompts, reconstructing the graph, or deploying the creator's infrastructure, while still seeing enough of the contract to decide whether the workflow is appropriate for the job and data involved.

A careful buyer starts with the desired outcome, then evaluates the listing that claims to deliver it. The useful questions are concrete: what fields must be supplied, which providers or credentials are involved, what a normal result looks like, what the workflow cannot guarantee, which version will run, and what that run costs. An eligible [free demo](https://www.edgaze.ai/docs/billing/run-a-workflow) can test the real workflow with the buyer's own input. A paid run uses a matching prepaid bundle first and wallet balance second, then persists in [run history](https://www.edgaze.ai/runs) so the buyer can leave, return, and inspect the final output or failure without paying for ownership of the creator's private graph.


## Evaluate and run a workflow

Treat the listing as a compact product contract rather than a promise that every polished example will generalize. Confirm that the workflow accepts the material you actually have, produces an output you can use, and discloses any model, provider, or human-review requirement that matters to your decision.

Search the marketplace by the outcome you need and compare complete products, not only titles or thumbnails. Read the creator's description and examples closely enough to distinguish a workflow that solves the job from one that merely uses the same model or category. [Browse the marketplace](https://www.edgaze.ai/marketplace).

Check the required inputs, size limits, expected output, credential mode, available version, and displayed per-run price before sharing valuable data. Understand what successful, failed, cancelled, demo, and compute-limit outcomes mean rather than assuming every click is charged alike. [Read the buyer guide](https://www.edgaze.ai/docs/billing/run-a-workflow).

Edgaze uses an eligible bundle for the selected workflow version before wallet balance. Add wallet funds only after choosing the product and reviewing its current price; insufficient funding prevents ordinary execution rather than placing a surprise charge on a card during the run. [Open your wallet](https://www.edgaze.ai/wallet).

The run remains available after the original browser session ends. Return to run history for status, readable outputs, failure context, and links to files or rich media, and keep the version and result together when the output feeds a later business decision. [View run history](https://www.edgaze.ai/runs).


## A workflow product should explain itself

A prompt file asks the buyer to supply the model, tools, data plumbing, retry behavior, and operating environment. A workflow product is different: it packages a configured process behind a focused input-to-result experience. That can save meaningful implementation time, but only if the listing makes the boundary of the product understandable before the buyer commits money or information.

The product page should answer what the workflow does in plain language, which inputs are required, what limits apply, whether the runner needs provider credentials, what normal output looks like, and what one execution costs. Examples are evidence of the intended result, not a guarantee that every input will produce identical quality. The creator's identity, description, and disclosed limitations matter because [marketplace](https://www.edgaze.ai/marketplace) software still reflects the judgment of the person who built it.

The buyer purchases execution of the selected published workflow version, not ownership of the creator's private graph, prompts, or intellectual property. That is a useful trade when the desired value is the finished outcome and the buyer does not want to operate the system. It is the wrong trade when the buyer needs to audit, modify, or permanently own every internal decision in the workflow. A good listing makes that distinction easy to understand.

## The displayed price belongs to a published version

Creators publish immutable workflow versions and set a margin within platform limits. For an Edgaze-hosted workflow, applicable compute at the published input limit is included with that margin so the buyer sees one per-run price instead of an open-ended token or infrastructure meter. Inputs above the published envelope are blocked before charge, and smaller inputs do not reduce the fixed displayed price. This makes the commercial decision simple enough to understand before the work starts.

Funding follows a predictable order. A prepaid bundle tied to the selected workflow version is used first when runs remain; otherwise Edgaze uses wallet balance. A wallet-funded run reserves the displayed amount while it works and settles it on success. An ordinary failed or cancelled run does not keep the creator margin, and a matching bundle run is not consumed. Demos and builder tests are free. A compute-limit stop is disclosed separately because already-consumed compute may remain charged.

Version choice matters because a new version can change the graph, input shape, output, and price. Bundles remain tied to the version purchased, while ordinary wallet-funded execution uses the selected available version. Before repeating a workflow after an update, check what changed rather than assuming the new release is interchangeable with the result you used previously. Published workflow versions make that decision visible instead of silently replacing the system behind an old purchase.

## Buying saves setup, not judgment

A [marketplace](https://www.edgaze.ai/marketplace) can remove setup and operating work, but it cannot decide whether a workflow is suitable for your context. Before submitting private, regulated, or commercially sensitive information, inspect what the product asks for and whether external services or buyer-provided credentials are involved. Do not provide data merely because a field exists. The minimum useful input is usually safer and easier to evaluate than an unfiltered archive.

AI output can be incomplete, inaccurate, or inappropriate for a consequential decision. A workflow may improve consistency by encoding a careful process, but it does not turn a model into a licensed professional or make an external source authoritative. Buyers should plan human review according to the stakes: a social draft may need editorial judgment, while legal, medical, hiring, credit, or safety-related output requires qualified review outside the workflow.

Use a [free demo](https://www.edgaze.ai/docs/billing/run-a-workflow) when the listing offers one and the test can be performed safely. A demo is a real execution using your input, so it is a better signal than a prerecorded example, but one good result still does not establish reliability across every case. Keep useful paid results in [run history](https://www.edgaze.ai/runs), compare repeated outcomes where consistency matters, and report product-specific problems with enough context for the creator to improve a later version.

## Frequently asked questions

### What do I receive when I buy an AI workflow run?

You receive execution of the selected published workflow version with your accepted inputs and access to its resulting output. You do not purchase ownership of the creator's private graph or intellectual property.

### Can I try a workflow before paying?

Some creators enable a one-time [free demo](https://www.edgaze.ai/docs/billing/run-a-workflow). Demo availability is shown by the product and demos do not create a paid charge or creator earnings.

### How is an Edgaze workflow priced?

The creator sets a margin and Edgaze adds applicable hosted compute under current platform rules. The buyer sees one displayed per-run price before starting.

### What happens when a paid workflow fails?

Current rules do not keep the creator margin for failed or cancelled runs, and an eligible bundle run is not consumed. Exact outcomes and exceptional cases are documented in the [billing guides](https://www.edgaze.ai/docs/billing).

### Can I run a purchased workflow again?

Yes, subject to the workflow remaining available, your access, the active or pinned version rules, required credentials, and funding for the next run.

## Sources

- [Edgaze marketplace](https://www.edgaze.ai/marketplace)
- [Run a workflow](https://www.edgaze.ai/docs/billing/run-a-workflow)
- [When runs fail](https://www.edgaze.ai/docs/billing/when-runs-fail)
- [Edgaze pricing](https://www.edgaze.ai/pricing)

Last reviewed: September 13, 2026


---

---
title: Builder Overview
description: How Workflow Studio, Composer, Templates, and API Vault fit together in Edgaze.
source: https://www.edgaze.ai/docs/builder
section: builder
---
# Builder Overview

> How Workflow Studio, Composer, Templates, and API Vault fit together in Edgaze.

**Audience: Creators building and publishing workflows.**

# Build from the buyer's result backward

The Edgaze builder helps you turn a promised result into a product people can run and pay for. Begin with what the buyer should receive, identify the information needed to create it, then add only the transformations between those two points.

## Choose the shortest path to the outcome

**Workflow Studio** is for products with visible steps, branching, external requests, or repeated work. You connect blocks on a canvas, configure them in the Inspector, test the buyer path, and publish an immutable version.

**Composer** can turn a prompt or outcome into an editable workflow. Prompt Studio creation is retired; [existing prompt products remain supported](/docs/legacy#retired-prompt-studio).

**Templates** are guided starting points. Pick an outcome, answer a few product questions, and land in Workflow Studio with a normal editable graph.

**API Vault** stores your model provider keys in one secure place so your workflows can run on OpenAI, Anthropic, Google, and similar providers without scattering secrets across nodes.

**Composer** lives inside Workflow Studio. Describe a result or change in plain language and Composer edits the graph: additive edits apply directly and can be undone, while destructive or costly changes wait for your approval. Test the result before publishing.

## Which one to open first

If one prompt can do the whole job, describe the outcome to **Composer** and keep the generated workflow as simple as it needs to be.

If the product needs several connected steps, branching, or post-processing, start in **Workflow Studio**.

If you know the result you want but not the graph, start with **Templates**.

Set up **API Vault** as soon as you want runs to use your own provider accounts reliably.

## A reliable creator path

1. Write one sentence describing what the buyer receives.
2. Add Output and name that result.
3. Add the smallest transformation that can produce it.
4. Add only the buyer inputs that transformation needs.
5. Test normal, empty, and failure cases.
6. Publish with a title, description, and price that describe the result rather than the implementation.

The question to keep in front of you: **What does the customer get back, and why is that easier than doing it manually?**

## Three common shapes

**Single prompt**

```text
Ask for Input -> Generate Text -> Result
```

Usually a small workflow created with Composer.

**Guided workflow**

```text
Ask for Input -> Get Content -> Generate Text -> Result
```

Usually Workflow Studio or a template.

**Multi-input creative workflow**

```text
Several inputs -> Merge -> Optimise -> Generate -> Output
```

Common for templates like AI Art Creator.

## See a real workflow before you build

This is the same graph rendering used in Workflow Studio previews and documentation. Read it from the buyer input on the left to the delivered result on the right.

```docsgraph
ai-art-creator
```

## If you are new here

Read this page once, then go where your product shape points you: [Workflow Studio](/docs/builder/workflow-studio) for full control, [Templates](/docs/builder/templates) for the fastest start, or [Composer](/docs/builder/composer-ai) to begin from an outcome. Read [API Vault](/docs/builder/api-vault) before you depend on your own provider keys.

## Before you publish

Strong Edgaze products are easy to understand at a glance.

Your title and description should name the outcome, not the technique. The customer should know what to enter and what they receive. If those answers are obvious, the builder work usually is too.

For pricing and earnings, see the [Billing guides](/docs/billing).

## Next step

[Workflow Studio](/docs/builder/workflow-studio) · [Templates](/docs/builder/templates) · [Composer](/docs/builder/composer-ai) · [Legacy features](/docs/legacy)


---

---
title: Workflow Studio
description: Build, test, and publish your first Edgaze workflow without learning every block at once.
source: https://www.edgaze.ai/docs/builder/workflow-studio
section: builder
---
# Workflow Studio

> Build, test, and publish your first Edgaze workflow without learning every block at once.

**Audience: Creators building and publishing workflows.**

# Workflow Studio

**Outcome: Publish a workflow whose input, transformation, and buyer result are obvious before anyone runs it.**

Workflow Studio is the visual editor for products that buyers can run. A workflow can be one model block or a connected process with inputs, tools, logic, and a final output. This page gets one working end to end; the [Block reference](/docs/builder/nodes/input) is authoritative for individual block settings.

## The shortest useful workflow

Start with three blocks:

1. **Ask for Input** asks the buyer for a topic or source text.
2. **Generate Text** turns that input into the requested result.
3. **Result** publishes the value buyers should receive.

Connect them from left to right. A connection carries the upstream block's output into the downstream block. Keep the first version small enough that every connection has an obvious purpose.

```docsgraph
llm-chat
```

## Build it

Open [Workflow Studio](/builder), create a workflow, and add the three blocks.

You can start without an account. A guest workflow is saved only in the current browser and is
limited to one local draft. Sign in to save it to your account, run it, or publish it. After sign-in,
Studio transfers the local draft to your account and returns to the action you selected.

In **Ask for Input**, add one question or a group of related questions. Use clear labels and mark only essential answers as required.

In **Generate Text**, write instructions that reference the connected answers. Choose a model based on quality, latency, and provider setup. The current default comes from the catalog: `gpt-6-sol`. The model picker is the source of truth for currently callable alternatives.

In **Result**, choose the value from Generate Text and give it a plain name such as `article` or `summary`. Only Result blocks become the buyer's final result.

## Use the Studio without losing context

The left library is for finding blocks. Use the category menu above the block grid to narrow the list, and search to filter blocks by name. Templates are not in the library: choose **Browse templates** when you start a workflow, or open [Templates](/docs/builder/templates).

Select a block to configure it in the Inspector. The Inspector is tied to that exact block, so switching between two blocks of the same type does not carry unfinished field values across. **Saving**, **Saved**, and **Error** show whether the current draft reached storage.

Connections describe data flow, not execution decoration. Start at an output port and finish at a compatible input port. If a connection is rejected, use the message beside the attempted connection to fix the type, occupied input, direction, or cycle.

On a narrow screen, the Inspector becomes a bottom sheet so the graph remains visible. Hidden Studio layers are removed from keyboard and screen-reader navigation while a modal editor is open.

## Repeat a transformation without cluttering the main graph

Use Repeat when the same steps should run an exact number of times. Each repetition receives the incoming value and the original submitted inputs.

Select the Repeat block and choose **Edit repeated steps** (or **Add repeated steps** on a new block) to work with the same library, canvas, connections, and Inspector inside Repeat. Saving returns you to the main graph.

```docsgraph
repeat
```

See [Repeat](/docs/builder/nodes/repeat) for result selection, limits, cost, and failure behavior.

## Test the buyer path

Select **Run**, enter realistic input, and run the workflow. Check all of these before publishing:

- The form asks only for information the workflow actually uses.
- Every block completes in the expected order.
- The Result block contains the complete buyer result.
- Errors explain what the creator or buyer needs to change.
- No provider key, token, or internal configuration appears in output or logs.

Builder test runs run the model each step is set to, on Edgaze's keys, and draw on your weekly Workflow Studio usage allowance (see [Pricing Limits](/docs/pricing-limits)). The ring next to **Run** shows how much of this week is left; it turns amber from 80% used, and the Run panel adds a short note. Each run gets an execution budget from its estimate before it starts. A run that needs more stops with "Stopped: execution budget reached" and keeps what it finished; run it again for a fresh budget.

When this week's allowance is used up, Studio asks before anything starts: turn on **Use wallet funds** to keep testing from your wallet (compute price, no margin, confirmed once a week), top up, or wait for the Monday reset. With Edgaze Plus and keys saved in [API Vault](/docs/builder/api-vault), turn on **Use my API keys** in the Run panel to run the steps whose provider has your key on that key; those steps use only their compute from the allowance. The row shows which steps move and which stay on Edgaze. Steps have no per-step key setting.

For Repeat workflows, test with a small count first. Confirm that each repetition produces the result you expect, then test the largest count you promise buyers.

## Choose provider credentials

Publishing offers three listing-level modes:

- **Edgaze hosted:** Edgaze supplies provider credentials and applicable hosted compute is included in the displayed run price. Buyers with Edgaze Plus can opt in to their own keys for the steps whose provider they have a key for; you earn the same margin either way, and the publish preview shows both prices.
- **Creator-connected:** the creator's encrypted Vault keys run the listing. The creator needs active Plus and every required provider key. Provider usage bills the creator directly.
- **Buyer brings keys:** each runner needs active Plus and the required Vault keys. Provider usage bills the buyer directly.

The publish screen derives required providers from the graph. A non-hosted listing never silently falls back to Edgaze credentials. If a required creator key is removed, the listing becomes unavailable until it is repaired.

Read [API Vault](/docs/builder/api-vault) and [BYOK billing](/docs/billing/byok) before choosing a non-hosted mode.

## Price and publish

Free workflows have no creator margin. For a paid workflow, set a per-run creator margin between **$0.05** and **$50.00**. The buyer sees one displayed price containing the creator margin plus applicable hosted compute. Creators receive **80% of their margin**, not 80% of the full displayed price.

Before publishing, confirm:

- The title and description say what the buyer gets.
- Required setup and providers are disclosed.
- The thumbnail and demos represent normal results.
- The input envelope covers the promised use case.
- The failure and cancellation expectations are accurate.

Publishing creates an immutable workflow version. Later edits create a new version when the executable graph or pinned execution contract changes.

## Remix rules

A creator may allow an original workflow to be remixed as one sealed **Remixed Workflow** block. A valid remix has one sealed parent and a meaningful change around it. A remix cannot itself be remixed, so composition depth is one. The publish screen rejects a remix of a remix before it becomes a listing.

Read [Remix and composed workflows](/docs/billing/remix-and-nested-workflows) and the [Remixed Workflow block](/docs/builder/nodes/remixed-workflow) for exact inputs and failure behavior.

## Where to go next

- [Ask for Input](/docs/builder/nodes/input)
- [Generate Text](/docs/builder/nodes/llm-chat)
- [Result](/docs/builder/nodes/output)
- [Get Content](/docs/builder/nodes/web-scrape)
- [Call an API](/docs/builder/nodes/http-request)
- [Decide](/docs/builder/nodes/condition)
- [Repeat](/docs/builder/nodes/repeat)
- [Composer](/docs/builder/composer-ai)
- [Templates](/docs/builder/templates)


---

---
title: Tutorial: Company Intelligence Workflow
description: Build, publish, and integrate a workflow that turns a company website into a structured sales-research brief.
source: https://www.edgaze.ai/docs/builder/tutorial-company-intelligence
section: builder
---
# Tutorial: Company Intelligence Workflow

> Build, publish, and integrate a workflow that turns a company website into a structured sales-research brief.

**Audience: Creators building and publishing workflows.**

## What you will build

This workflow accepts a company name, public website URL, and research goal. It retrieves the public page, asks an LLM to produce a concise evidence-aware company brief, and returns a reusable Markdown report.

The result is commercially useful for account research, sales preparation, partner screening, and market mapping. It is still an AI-generated research aid: users must verify claims against primary sources before relying on them.

## Prerequisites

- An Edgaze account with access to Workflow Studio.
- A public HTTPS company page that permits automated retrieval.
- A valid provider route for the selected LLM model. Review [API Vault](/docs/builder/api-vault) and disclose the listing's credential mode.
- For API integration, an API key with `run:read` and `run:execute`.
- For completion notifications, an HTTPS webhook endpoint and its Edgaze signing secret.

## 1. Create the workflow

Open **Workflow Studio**, choose **Start a blank workflow**, and name it `Company Intelligence Brief`.

Add these blocks:

1. **Ask for Input** with two questions: `Company name` and an optional `Research goal`.
2. **Get Content** to read the company website. It asks for the link itself, so the website URL is not a question in Ask for Input.
3. **Generate Text** configured to produce the brief.
4. **Result** named `Company intelligence brief`.

The public input schema is generated from Ask for Input and from Get Content's run-time link question. Keep these names stable after customers or API clients start using the workflow. API callers may use an input's exact `name` or its `nodeId`, but node IDs are safer when names may change.

## 2. Configure website retrieval

Select **Get Content** and set:

- **Content source:** `Web page`
- **Link source:** `Ask when the workflow runs`
- **Question:** `Website URL`
- **Description:** `Paste the company's public homepage or About page.`
- **Primary content:** `Markdown`
- **Allowed Hosts:** the company domain when building for one known source; otherwise leave this unset only when the product genuinely accepts arbitrary public sites

With **Ask when the workflow runs**, Get Content becomes an entry block: it has no input port, so do not connect Ask for Input into it. The runner pastes the link on the run form, next to the other questions.

Do not put secrets in the URL. Private IP ranges, internal hosts, unsafe redirects, and destinations rejected by Edgaze network policy fail the block, and so does a page that blocks automated retrieval. A run without a usable link is rejected with a message asking for a page to read.

## 3. Configure analysis

Connect both **Get Content** and **Ask for Input** to **Generate Text**. Use instructions like:

```text
Create a company intelligence brief from the retrieved public webpage.

Return Markdown with:
1. company summary
2. products and target customers
3. likely business priorities
4. three evidence-backed sales hypotheses
5. open questions and verification risks

Distinguish facts present in the source from inference. Do not invent revenue,
headcount, customers, funding, or contact details. Use the supplied company name
and research goal as context.
```

Reference the connected company name and research goal using the block connections or the variable controls shown by Workflow Studio. Keep the retrieved page as the model input and the instructions in the LLM prompt. Choose a current model from the inspector and set **Max Tokens** close to the expected report length.

Connect the generated text to **Result**. Keep the native Markdown text; the result renderer selects the appropriate presentation automatically.

## 4. Test realistic and failure cases

Use **Run** in Workflow Studio with:

```json
{
  "Company name": "Example Corp",
  "Website URL": "https://example.com",
  "Research goal": "Prepare for a first sales discovery call"
}
```

Verify all of the following before publishing:

- Get Content retrieves only the expected public destination.
- The report separates sourced facts from inference.
- Missing required inputs are rejected.
- A malformed or missing URL is rejected.
- A blocked or timed-out page produces an understandable failure, and an error page (`ok: false` in Get Content's output) is not reported as company research.
- The output has no raw credentials, internal block data, or unsupported certainty.

Ordinary failed and cancelled runs do not charge creator margin. A compute-limit stop is a distinct outcome where already consumed compute may remain charged. See [When Runs Fail](/docs/billing/when-runs-fail).

## 5. Review compute and set margin

Open the publishing flow and review **Compute estimate** using realistic input sizes. The estimate informs the buyer's displayed price; it is not deducted from creator earnings.

For a paid workflow, set a creator margin within the current limits shown in [Pricing Limits](/docs/pricing-limits). The buyer sees one displayed per-run price containing hosted compute plus creator margin. On a successful run, the creator earns 80% of the margin.

If the listing uses runner-managed provider keys, verify the BYOK requirements and pricing in [BYOK](/docs/billing/byok). Disclose required providers on the listing.

## 6. Publish and run from the marketplace

Add an accurate title, description, example output, credential disclosure, and limitations. Publish an immutable version, then open its marketplace product page.

Run it once as a buyer would:

1. Confirm the displayed price before funding.
2. Supply all required inputs.
3. Start the run.
4. Review the final report and wallet or bundle history.

Successful wallet runs charge the displayed price. A matching workflow bundle is selected before wallet funding. The full funding contract is in [Create Run](/docs/api/create-run#funding-and-acceptance-behavior).

## 7. Run through the API

Fetch the workflow first and build inputs from its actual `inputSchema`. Replace the example UUIDs and input keys below with the values returned for your published workflow.

```bash
curl --request POST "https://www.edgaze.ai/api/v1/runs" \
  --header "Authorization: Bearer $EDGAZE_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: company-example-corp-2026-07-30" \
  --data '{
    "workflow": "550e8400-e29b-41d4-a716-446655440000",
    "inputs": {
      "Company name": "Example Corp",
      "Website URL": "https://example.com",
      "Research goal": "Prepare for a first sales discovery call"
    }
  }'
```

The response is `202 Accepted` with `statusUrl`, `eventsUrl`, and `streamUrl`. Store the run id and idempotency key together. Reusing the same key and request returns the original run; changing workflow, normalized inputs, or requested version returns `409 idempotency_conflict`.

## 8. Poll or stream progress

For a simple server integration, poll no more than once per second and back off:

```javascript
const terminal = new Set(["completed", "failed", "cancelled"]);
let delayMs = 1000;

while (true) {
  const response = await fetch(statusUrl, {
    headers: { Authorization: `Bearer ${process.env.EDGAZE_API_KEY}` },
  });
  if (!response.ok) throw new Error(`Run read failed: ${response.status}`);
  const body = await response.json();
  if (terminal.has(body.status)) {
    console.log(body.outputs);
    break;
  }
  await new Promise((resolve) => setTimeout(resolve, delayMs));
  delayMs = Math.min(Math.round(delayMs * 1.6), 10000);
}
```

For a live UI, connect to `streamUrl` as Server-Sent Events. Persist each event `sequence` and resume with `Last-Event-ID`. Append `data.text` from `node.output.delta` events in sequence order. See [Streaming](/docs/api/streaming).

## 9. Receive completion through a webhook

Create a webhook subscription in the developer dashboard for `run.completed`, `run.failed`, and `run.cancelled`. Verify the signature against the raw request body before parsing JSON. Return a 2xx response only after your receiver has durably recorded the event.

A delivery that times out or gets a 5xx, 408, 425, or 429 response is retried with backoff, up to 6 attempts over roughly nine hours; other 4xx and redirect responses are not retried. An endpoint is disabled automatically after 15 consecutive failed deliveries. Make your receiver idempotent, and reconcile missed notifications by reading the run endpoint. Use the complete verifier in [Webhooks](/docs/api/webhooks).

## 10. Verify output and billing

After a terminal response:

- Confirm `status`, `reason`, and `outputs`.
- Confirm `billingStatus` is final rather than `pending`.
- Compare `displayedChargeUsd` with wallet history or the bundle counter.
- On success, confirm creator earnings were recorded at 80% of margin.
- On ordinary failure or cancellation, confirm `billingStatus` becomes `not_charged` and no creator earnings appear.
- If the run stopped at the compute limit, review the separately labeled partial-compute outcome.

You now have one workflow that is testable in Workflow Studio, saleable in the marketplace, and integrable through polling, SSE, and signed webhooks.


---

---
title: Templates
description: Start from an outcome, answer a few setup questions, and open an editable workflow in Workflow Studio.
source: https://www.edgaze.ai/docs/builder/templates
section: builder
---
# Templates

> Start from an outcome, answer a few setup questions, and open an editable workflow in Workflow Studio.

**Audience: Creators building and publishing workflows.**

# Templates

Templates help you start from the result you want instead of an empty canvas. Pick a template, answer a short guided setup, and open Workflow Studio with a working graph you can still edit.

## What a template gives you

A template is more than a copied file. It bundles product metadata, a preview of the workflow shape, setup questions, and the rules that turn your answers into a real graph.

That graph uses the same blocks as any workflow you build by hand. Nothing is hidden behind a separate system.

## Where to find them

Browse templates on the standalone library at `/templates`, or open the template modal inside Workflow Studio while you are already building. Both paths use the same catalog.

## Guided setup

Strong templates ask outcome questions first:

- How many inputs should this use?
- What should the optimizer focus on?
- Which model fits the job?
- What output shape do you want?

They should not ask you to think in node handles or internal wiring.

After setup, Edgaze generates a normal workflow in Workflow Studio. You can inspect, tweak, and publish it like any other graph.

## Example: AI Art Creator

AI Art Creator walks through input count, question text, optimizer instructions, image model, and aspect ratio, then assembles a creative pipeline.

```docsgraph
ai-art-creator
```

Fewer inputs produce a simpler graph. More inputs add merge paths before generation.

## Template detail pages

A detail page should answer what the template creates, what setup you will see, and who it is for. It is a preview of the product, not a dump of internal configuration.

## When templates help most

Use templates when you want speed, sensible defaults, and less manual assembly.

Build from scratch when the graph is tiny, highly custom, or experimental enough that guided setup would get in the way.

## Good habits

- Name the outcome clearly before you pick a template.
- Keep setup answers honest; they shape the first graph.
- Open the inspector after generation and fix only what matters.
- Test once with realistic input before you publish.

## What to read next

- [Workflow Studio](/docs/builder/workflow-studio)
- [API Vault](/docs/builder/api-vault)
- [Builder Overview](/docs/builder)


---

---
title: API Vault
description: How buyers and creators save provider keys, and which key owner is billed in each workflow credential mode.
source: https://www.edgaze.ai/docs/builder/api-vault
section: builder
---
# API Vault

**Audience: Buyers using their own provider keys and creators choosing a listing credential mode.**

API Vault stores provider keys for the account that owns them. Keys stay server-side and are never placed in a public workflow graph, API response, event, stream, or client-side run payload.

## Why it matters

Without a central vault, keys get copied into individual blocks and become difficult to rotate safely. Vault gives each account one connection point per provider. A listing's credential mode determines whose Vault is used and who receives the provider bill.

## Where you see it

Vault appears in account settings (Settings, API keys). Run panels show a **Use my API keys** row for Edgaze Plus members with a saved key, and a quiet "Add keys" link otherwise. Listing cards and product pages disclose the credential mode and required providers before a run.

Vault is the only place a key enters a run. Steps have no per-step key setting, and no run panel asks you to paste a key.

## The three credential modes

| Listing mode          | Credentials used             | Who pays the provider | Buyer requirement                           |
| --------------------- | ---------------------------- | --------------------- | ------------------------------------------- |
| **Edgaze-hosted**     | Edgaze platform credentials  | Edgaze                | None (Plus can opt in to their own keys)    |
| **Creator-connected** | Listing creator's Vault keys | Creator               | No buyer provider key                       |
| **Buyer brings keys** | Buyer's Vault keys           | Buyer                 | Active Plus and every required provider key |

Credential requirements are determined by the workflow's listing-level credential mode. They are not inferred from which account happens to have a key saved.

Some models are Edgaze-hosted only. Kimi-K2.6 and DeepSeek-V4-Pro run on Edgaze's own deployment and have no provider key you can save in Vault, so a workflow that uses either one can only be published as Edgaze-hosted. Publishing it as creator-connected or buyer-BYOK is rejected until you switch those blocks to a direct-provider model.

Before creating a run, Edgaze checks every required provider. A missing or unreadable key stops preflight before wallet funds or a bundle run are reserved. Creator-connected listings become unavailable if the creator removes a required key; they never silently fall back to Edgaze-hosted credentials.

## What creators should do

Pick the model for the job and choose the listing credential mode before publishing. Creator-connected publication requires active Plus and all required creator Vault keys. Buyer-BYOK listings must clearly disclose the buyer's required providers. If the graph uses an Edgaze-hosted-only model such as Kimi-K2.6 or DeepSeek-V4-Pro, publish it as Edgaze-hosted.

Do not discover a missing key on launch day.

## Using your own keys on hosted listings

With active Plus, the run panel's **Use my API keys** switch runs every step whose provider (OpenAI, Anthropic or Google) has a key in your Vault on that key. Other steps, including Kimi-K2.6 and DeepSeek-V4-Pro, stay on Edgaze's keys. Your choice is remembered for your account, and REST API and MCP runs follow it. Vault keys are read only while Plus is active.

## BYOK and billing

Steps on a Vault key cost Edgaze infrastructure only; steps on Edgaze's keys keep their full model cost. You pay the creator margin plus that compute, with $0.002 as the floor. The provider bills the key owner directly. See [BYOK](/docs/billing/byok).

## Good habits

- Keep keys only in vault.
- Match provider to model.
- Re-test after rotating or replacing a required key.
- Confirm the product page shows the intended credential mode before publishing.

## What to read next

- [Workflow Studio](/docs/builder/workflow-studio)
- [Templates](/docs/builder/templates)
- [BYOK](/docs/billing/byok)


---

---
title: Composer & Generative AI
description: How Composer assists workflow editing, what to verify before you apply changes, and how external AI providers are involved.
source: https://www.edgaze.ai/docs/builder/composer-ai
section: builder
---
# Composer & Generative AI

> How Composer assists workflow editing, what to verify before you apply changes, and how external AI providers are involved.

**Audience: Creators building and publishing workflows.**

# Composer & Generative AI

Composer is the AI-assisted editing panel inside Workflow Studio. You describe what you want in plain language and Composer edits the graph. Additive edits apply directly and can be undone; destructive or costly changes wait for your approval.

Composer uses generative AI. Suggestions can be wrong, incomplete, or unsuitable for your product. You are responsible for what you apply and what you publish.

**Effective date:** May 26, 2026  
**Last updated:** May 26, 2026

## What Composer is

Composer helps you inspect the current workflow, propose supported edits (add blocks, update settings, connect nodes), validate those edits against Edgaze rules, and explain what it intends to change.

Composer is not a general chatbot, legal advisor, or guarantee that a workflow will run correctly in production. It never replaces your whole graph, removes blocks, or adds costly or externally visible steps without your approval.

## Composer in the docs

The **Ask** button in the documentation opens the same Composer in a read-only mode. It searches and reads the documentation to answer your question, links the page each answer is based on, and cannot open, edit or run a workflow. Docs questions draw on the same Composer allowance as Workflow Studio at a reduced rate, with a small daily limit of their own. Answers can be wrong: open the linked page before you rely on one.

## External AI providers

Composer sends your prompt and relevant workflow context to third-party model providers to generate responses. Edgaze does not operate those models. Providers, versions, and routing can change.

Your use is subject to Edgaze policies and the provider's terms. Do not submit secrets, passwords, or data you are not allowed to share.

## How Edgaze keeps control

The model proposes structured actions. It does not get unrestricted write access to your canvas.

Edgaze validates proposals against supported blocks and connection rules before anything applies. Additive edits, such as adding blocks, changing settings, and connecting nodes, apply directly; use **Undo** in the changes panel to roll back the last Composer change. These changes always wait for your approval: replacing the whole graph, deleting or disconnecting nodes, adding image generation, adding Repeat, external write actions through an API or integration block, anything Composer itself flags as high-risk, and any other change to steps that Composer's cost check rates as costly or risky, such as creator-shared credentials or very high token limits. If you reject a change, nothing is applied. Limits on turns, tool use, and graph size reduce runaway automation.

If you edit the canvas while Composer is working, Edgaze tries to detect conflicts so manual work is not overwritten quietly.

Composer cannot edit locked or read-only workflows.

## What we do not guarantee

Composer may misunderstand your intent, produce suboptimal graphs, miss policy or compliance needs, or be unavailable. Confident wording is not proof of correctness.

## Your responsibilities

Review each change Composer applies or asks you to approve, and the workflow's behavior before you publish. Test with representative inputs. Do not paste API keys or unnecessary sensitive data into prompts. Decide whether each suggestion should be applied, edited, or rejected.

## Data handling

Prompts, attachments where supported, and workflow context may be processed by Edgaze and external providers to operate the feature. See the [Privacy Policy](/docs/privacy-policy) for broader data practices.

## Related policies

- [Content Disclaimer](/docs/content-disclaimer)
- [Terms of Service](/docs/terms-of-service)
- [Acceptable Use Policy](/docs/acceptable-use-policy)
- [Privacy Policy](/docs/privacy-policy)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [Billing guides](/docs/billing)
- [Workflow Studio](/docs/builder/workflow-studio)

## Contact

Questions: `support@edgaze.ai`


---

---
title: Ask for Input
description: Ask one question or collect several related answers when the workflow starts.
source: https://www.edgaze.ai/docs/builder/nodes/input
section: builder
---
# Ask for Input

> Ask one question or collect several related answers when the workflow starts.

**Audience: Workflow creators.**

## Overview

Ask one question or collect several related answers when the workflow starts.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Customer support intake

**You will build:** A complete ticket with urgency and next action.

Collect the facts support needs before any model runs. Required fields prevent empty tickets from entering the workflow.

```docsgraph
block-input-customer-support-intake
```

[Open this template](/templates/block-input-customer-support-intake) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Creative campaign brief

**You will build:** A usable creative direction from one structured brief.

Long-form input keeps goals and constraints together. The runner can review the full brief before spending model credits.

```docsgraph
block-input-creative-campaign-brief
```

[Open this template](/templates/block-input-creative-campaign-brief) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Public page reviewer

**You will build:** A review plan tied to one validated URL.

A URL field makes the expected input obvious. Input validation catches malformed links before downstream work starts.

```docsgraph
block-input-public-page-reviewer
```

[Open this template](/templates/block-input-public-page-reviewer) and adapt the labels, prompts, or credentials to your own workflow.

## File uploads

Set a question's answer type to **File upload** when the runner provides a document, image, or code file. Runners can choose a file, drag it in, or paste it:

- **Keyboard:** press ⌘V or Ctrl+V anywhere on the run form. The file goes to the upload field that has focus. With nothing focused, it goes to the only field with room, one file per field when several are empty, or the runner picks the field.
- **Paste button:** every upload field has a **Paste** button for phones and tablets. If the browser blocks clipboard access, the field shows a paste area to touch and hold instead.
- **Pasted text:** pasting text into an upload field offers to attach it as a file. The runner can rename it, for example to `main.py`, so the model knows the format.

Turn on **Allow multiple files** to accept several files for one question, up to 10 (choose a lower limit if you like). Files in one question can total at most 50 MB. Every file reaches the next block together, so one Generate Text block can compare or summarize all of them.

Through the API, send a multiple-file answer as a list of file objects. A single file object is accepted too and treated as a list of one.

## Ports

- **Output: Data** (`out-right`): `any`, optional, single.

## Inspector

- **Question group title:** key `title`; text; default: `"Questions"`; Example: e.g. Project brief.
- **ask-for-input editor:** manages `fields` with edit, validate, preview support.

## Behavior

- **Input requirement:** This is an entry node and does not accept an inbound connection.
- **Execution:** Handled by the handler using `input`.
- **Timeout:** No node-level timeout is defined.

## Cost

No metered provider or compute cost is assigned to this node.

## Security

- No credentials are used.
- The node has no external side effects.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Generate Text
description: Generate text with GPT, Claude, or Gemini in an Edgaze workflow: write the prompt, pick the model, and feed in inputs from earlier steps.
source: https://www.edgaze.ai/docs/builder/nodes/llm-chat
section: builder
---
# Generate Text

> Generate text with GPT, Claude, or Gemini in an Edgaze workflow: write the prompt, pick the model, and feed in inputs from earlier steps.

**Audience: Workflow creators.**

## Overview

Generate text with GPT, Claude, or Gemini.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Meeting notes to decisions

**You will build:** Owners, decisions, deadlines, and unresolved questions.

A focused extraction prompt is more dependable than a generic summary. A bounded output format makes missing owners and dates visible.

```docsgraph
block-llm-chat-meeting-notes-to-decisions
```

[Open this template](/templates/block-llm-chat-meeting-notes-to-decisions) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Policy plain-language rewrite

**You will build:** A faithful rewrite that preserves obligations.

Separates clarity work from legal review. The prompt instructs the model not to invent or remove requirements.

```docsgraph
block-llm-chat-policy-plain-language-rewrite
```

[Open this template](/templates/block-llm-chat-policy-plain-language-rewrite) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Lead qualification memo

**You will build:** Fit signals, risks, and the next discovery question.

Turns inconsistent notes into a repeatable sales handoff. Explicit evidence fields keep the assessment traceable to the input.

```docsgraph
block-llm-chat-lead-qualification-memo
```

[Open this template](/templates/block-llm-chat-lead-qualification-memo) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, single.
- **Output: Response** (`out`): `string`, optional, single.

## Inspector

- **Prompt:** key `prompt`; textarea; default: `""`.
- **Style / System (optional):** key `system`; textarea; default: `""`.
- **Model:** key `model`; select; options: `gpt-6-astra`, `gpt-6-sol`, `gpt-6-luna`, `Kimi-K2.6`, `DeepSeek-V4-Pro`, `claude-sonnet-5`, `claude-opus-5-5`, `gemini-3.7-flash`, `gemini-3.1-pro-preview`, `gemini-3.5-flash-lite`, `gemini-3.1-flash-lite`; default: `"gpt-6-sol"`.
- **Max Tokens:** key `maxTokens`; number; range: 1 to 16000; default: `2000`.
- **Timeout (ms):** key `timeout`; number; range: 30000 to 600000; default: `120000`.
- **Stream:** key `stream`; inline switch; default: `true`.
- **expanded-text editor:** manages `prompt`, `system` with edit, expand support.

## Behavior

- **Input requirement:** Provide one of ports `in` or config fields `prompt`, `system`.
- **Execution:** Handled by the handler using `llm-chat`.
- **Timeout:** 120000 ms by default (30000 to 600000 ms).

## Cost

Uses a language-model provider and contributes model usage to the run cost.

## Security

- The step has no key setting of its own. The model key follows the listing's credential mode: Edgaze-hosted platform keys by default (or, for an Edgaze Plus runner who turns on Use my API keys, their own API Vault key for this step's provider), the creator's API Vault keys for a creator-connected listing, or the buyer's own keys for a buyer-BYOK listing. Some models are Edgaze-hosted only; see [API Vault](/docs/builder/api-vault). Secret values are not part of the published graph.
- The node reads from an external service without intentionally mutating it.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Generate Image
description: Generate images with Gemini or OpenAI from a text prompt in an Edgaze workflow, with working examples, model settings, and ports.
source: https://www.edgaze.ai/docs/builder/nodes/llm-image
section: builder
---
# Generate Image

> Generate images with Gemini or OpenAI from a text prompt in an Edgaze workflow, with working examples, model settings, and ports.

**Audience: Workflow creators.**

## Overview

Generate images with Gemini or OpenAI.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Editorial hero image

**You will build:** A landscape hero illustration.

Keeps art direction reusable across an editorial series. A fixed aspect ratio avoids layout surprises.

```docsgraph
block-llm-image-editorial-hero-image
```

[Open this template](/templates/block-llm-image-editorial-hero-image) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Product moodboard tile

**You will build:** A square product moodboard tile.

Provides a consistent visual exploration artifact. One-image output and a square ratio keep batches predictable.

```docsgraph
block-llm-image-product-moodboard-tile
```

[Open this template](/templates/block-llm-image-product-moodboard-tile) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Vertical campaign concept

**You will build:** A vertical concept for mobile placements.

Tests a campaign idea in its intended shape. The 9:16 constraint prevents accidental landscape renders.

```docsgraph
block-llm-image-vertical-campaign-concept
```

[Open this template](/templates/block-llm-image-vertical-campaign-concept) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Prompt** (`in`): `string`, optional, single.
- **Output: Generated media** (`out`): `image`, optional, single.

## Inspector

- **Prompt:** key `prompt`; textarea; default: `""`.
- **Model:** key `model`; select; options: `gemini-3.1-flash-image-preview`, `gemini-3-pro-image-preview`, `gemini-3.1-flash-lite-image`, `gpt-image-1-mini`, `gpt-image-2`, `gpt-image-1.5`; default: `"gemini-3.1-flash-image-preview"`.
- **Aspect ratio:** key `aspectRatio`; select; options: `1:1`, `2:3`, `3:2`, `3:4`, `4:3`, `4:5`, `5:4`, `9:16`, `16:9`, `21:9`, `1:4`, `4:1`, `1:8`, `8:1`; default: `"1:1"`.
- **Quality:** key `quality`; select; options: `low`, `medium`, `high`; default: `"medium"`.
- **Timeout (ms):** key `timeout`; number; range: 30000 to 600000; default: `180000`.
- **expanded-text editor:** manages `prompt` with edit, expand support.

## Behavior

- **Input requirement:** Provide one of ports `in` or config fields `prompt`.
- **Execution:** Handled by the handler using `llm-image`.
- **Timeout:** 180000 ms by default (30000 to 600000 ms).

## Cost

Uses an image-model provider and contributes model usage to the run cost.

## Security

- The step has no key setting of its own. The model key follows the listing's credential mode: Edgaze-hosted platform keys by default (or, for an Edgaze Plus runner who turns on Use my API keys, their own API Vault key for this step's provider), the creator's API Vault keys for a creator-connected listing, or the buyer's own keys for a buyer-BYOK listing. Some models are Edgaze-hosted only; see [API Vault](/docs/builder/api-vault). Secret values are not part of the published graph.
- The node reads from an external service without intentionally mutating it.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Get Content
description: Bring in content from a public web page or a YouTube video.
source: https://www.edgaze.ai/docs/builder/nodes/web-scrape
section: builder
---
# Get Content

> Bring in content from a public web page or a YouTube video.

**Audience: Workflow creators.**

## Overview

Bring in content from a public web page or a YouTube video.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Competitor landing-page capture

**You will build:** Readable page content for positioning analysis.

Brings public evidence into the workflow before analysis. Use only public pages and inspect the returned source metadata.

```docsgraph
block-web-scrape-competitor-landing-page-capture
```

[Open this template](/templates/block-web-scrape-competitor-landing-page-capture) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Documentation change review

**You will build:** A clean documentation snapshot.

Creates a stable input for release-impact analysis. Check the canonical URL and scrape timestamp before relying on the result.

```docsgraph
block-web-scrape-documentation-change-review
```

[Open this template](/templates/block-web-scrape-documentation-change-review) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Job description evidence pack

**You will build:** Role requirements and company language.

Gives outreach workflows first-party hiring context. Keep the source URL with the output so claims can be verified.

```docsgraph
block-web-scrape-job-description-evidence-pack
```

[Open this template](/templates/block-web-scrape-job-description-evidence-pack) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Link** (`in`): `any`, optional, single.
- **Output: Content** (`output`): `any`, optional, single. Legacy aliases: `out`.

## Inspector

- **Content source:** key `source`; select; options: `web`, `youtube`; default: `"web"`.
- **Link source:** key `sourceMode`; select; options: ``, `run_input`; default: `""`.
- **Fetch profile:** key `profile`; select; options: `static`, `adapter`; default: `"static"`; Browser rendering is unavailable until isolated request interception can enforce the same egress policy..
- **Link:** key `url`; text; default: `""`; Example: https://example.com/article.
- **Question:** key `question`; textarea; default: `"Which link should we use?"`.
- **Description:** key `description`; textarea; default: `"Paste one public link."`.
- **Caption language (optional):** key `language`; text; Example: e.g. en, es, hi.
- **Transcript style:** key `outputFormat`; select; options: `plain_text`, `timestamped`.
- **Primary content:** key `extract`; select; options: `markdown`, `text`, `structured`, `html`, `links`, `custom`; default: `"markdown"`.
- **Max pages:** key `maxPages`; number; range: 1 to 20; default: `1`.
- **Respect robots.txt:** key `respectRobots`; switch; default: `true`.
- **Blocked-page fallback:** key `fallback`; select; options: `none`, `amp`, `archive`; default: `"none"`.
- **Timeout (ms):** key `timeout`; number; range: 1000 to 120000; default: `30000`.
- **Max response bytes:** key `maxBytes`; number; range: 1024 to 5242880; default: `5242880`.
- **Allowed Hosts (comma-separated):** key `allowOnly`; text; default: `[]`.
- **Denied Hosts (comma-separated):** key `denyHosts`; text; default: `["127.0.0.1","localhost","0.0.0.0"]`.
- **Include HTML:** key `includeHtml`; switch; default: `false`.
- **Include app state:** key `includeAppState`; switch; default: `false`.
- **get-content editor:** manages `selectors`, `crawl`, `followPagination` with edit, validate, preview support.

## Behavior

- **Input requirement:** Provide one of ports `in` or config fields `url`, `sourceMode`.
- **Execution:** Handled by the handler using `web-scrape`.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- No credentials are used.
- The node reads from an external service without intentionally mutating it.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.

## Output Schema

Top-level fields: `url`, `finalUrl`, `status`, `ok`, `title`, `description`, `author`, `publishedAt`, `siteName`, `lang`, `canonicalUrl`, `image`, `content`, `markdown`, `text`, `html`, `structured`, `appState`, `links`, `images`, `fields`, `_meta`, `pages`, `complete`, `warnings`, `stopReason`.

Metadata fields under `_meta`: `strategy`, `source`, `extractorUsed`, `hadStructuredData`, `blocked`, `blockReason`, `robotsAllowed`, `attempts`, `bytes`, `truncated`, `durationMs`, `pagesFetched`, `pagesFailed`, `archiveSnapshot`.


---

---
title: Merge
description: Combines multiple data streams into one unified output.
source: https://www.edgaze.ai/docs/builder/nodes/merge
section: builder
---
# Merge

> Combines multiple data streams into one unified output.

**Audience: Workflow creators.**

## Overview

Combines multiple data streams into one unified output.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Compare two research briefs

**You will build:** One payload containing both research briefs.

Preserves both sources before synthesis. Named inputs make source order visible and reproducible.

```docsgraph
block-merge-compare-two-research-briefs
```

[Open this template](/templates/block-merge-compare-two-research-briefs) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Join brand voice and campaign goal

**You will build:** One brief with voice and campaign constraints.

Prevents either set of constraints from being lost. The merge is deterministic and does not rewrite either input.

```docsgraph
block-merge-join-brand-voice-and-campaign-goal
```

[Open this template](/templates/block-merge-join-brand-voice-and-campaign-goal) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Unify customer and order context

**You will build:** A single support-case payload.

Makes downstream triage operate on the same case context. Separate ports keep customer and order records distinguishable.

```docsgraph
block-merge-unify-customer-and-order-context
```

[Open this template](/templates/block-merge-unify-customer-and-order-context) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: in 1** (`in-1`): `any`, optional, single. Legacy aliases: `in1`.
- **Input: in 2** (`in-2`): `any`, optional, single. Legacy aliases: `in2`.
- **Input: in 3** (`in-3`): `any`, optional, single. Legacy aliases: `in3`.
- **Input: in 4** (`in-4`): `any`, optional, single. Legacy aliases: `in4`.
- **Input: in 5** (`in-5`): `any`, optional, single. Legacy aliases: `in5`.
- **Input: in 6** (`in-6`): `any`, optional, single. Legacy aliases: `in6`.
- **Input: in 7** (`in-7`): `any`, optional, single. Legacy aliases: `in7`.
- **Input: in 8** (`in-8`): `any`, optional, single. Legacy aliases: `in8`.
- **Input: in 9** (`in-9`): `any`, optional, single. Legacy aliases: `in9`.
- **Input: in 10** (`in-10`): `any`, optional, single. Legacy aliases: `in10`.
- **Output: Data** (`out`): `any`, optional, single. Legacy aliases: `out-right`.
- **Dynamic inputs:** `inputCount` selects 2 to 10 `in-N` ports; default 3.

## Inspector

- **Inputs:** key `inputCount`; number; range: 2 to 10; default: `3`.
- **Merge Mode:** key `mode`; select; options: `text`, `array`, `object`, `first`; default: `"text"`.

## Behavior

- **Input requirement:** At least 2 inbound connections are required.
- **Execution:** Handled by the handler using `merge`.
- **Timeout:** No node-level timeout is defined.

## Cost

Uses workflow compute and may contribute to the run's compute cost.

## Security

- No credentials are used.
- The node has no external side effects.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Decide
description: Branch using deterministic operators or an explicit AI rule.
source: https://www.edgaze.ai/docs/builder/nodes/condition
section: builder
---
# Decide

> Branch using deterministic operators or an explicit AI rule.

**Audience: Workflow creators.**

## Overview

Branch using deterministic operators or an explicit AI rule.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Route urgent support cases

**You will build:** Urgent cases separated from normal review.

Uses an explicit branch instead of burying routing in a prompt. A deterministic equality check is stable across runs.

```docsgraph
block-condition-route-urgent-support-cases
```

[Open this template](/templates/block-condition-route-urgent-support-cases) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Require approval for high spend

**You will build:** High-spend requests routed for approval.

Makes the control visible in the graph. A numeric greater-than rule is auditable and model-free.

```docsgraph
block-condition-require-approval-for-high-spend
```

[Open this template](/templates/block-condition-require-approval-for-high-spend) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Check publication readiness

**You will build:** Ready work separated from incomplete work.

Stops incomplete content before publication steps. The false branch remains visible instead of silently dropping work.

```docsgraph
block-condition-check-publication-readiness
```

[Open this template](/templates/block-condition-check-publication-readiness) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Value** (`input`): `any`, required, single.
- **Output: True Branch** (`true`): `any`, optional, single.
- **Output: False Branch** (`false`): `any`, optional, single.

## Inspector

- **AI Rule (optional):** key `humanCondition`; textarea; default: `""`.
- **Condition Type:** key `operator`; select; options: `truthy`, `falsy`, `equals`, `notEquals`, `gt`, `lt`; default: `"truthy"`.
- **Compare Value:** key `compareValue`; text; default: `""`.
- **condition editor:** manages `operator`, `compareValue`, `humanCondition` with edit, validate, preview support.

## Behavior

- **Input requirement:** Required input ports: `input`.
- **Execution:** Handled by the handler using `condition`.
- **Timeout:** No node-level timeout is defined.

## Cost

Uses a language-model provider and contributes model usage to the run cost.

## Security

- The step has no key setting of its own. The model key follows the listing's credential mode: Edgaze-hosted platform keys by default (or, for an Edgaze Plus runner who turns on Use my API keys, their own API Vault key for this step's provider), the creator's API Vault keys for a creator-connected listing, or the buyer's own keys for a buyer-BYOK listing. Some models are Edgaze-hosted only; see [API Vault](/docs/builder/api-vault). Secret values are not part of the published graph.
- The node reads from an external service without intentionally mutating it.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Repeat
description: Run an internal workflow a fixed number of times, one after another with fail-fast behavior, for example to draft several headline options.
source: https://www.edgaze.ai/docs/builder/nodes/repeat
section: builder
---
# Repeat

> Run an internal workflow a fixed number of times, one after another with fail-fast behavior, for example to draft several headline options.

**Audience: Workflow creators.**

## Overview

Run an internal workflow a fixed number of times.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Create three headline options

**You will build:** Three independent headline candidates.

Repeated generation gives an editor real choice. Sequential execution and fail-fast behavior make failures obvious.

```docsgraph
block-repeat-create-three-headline-options
```

[Open this template](/templates/block-repeat-create-three-headline-options) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Generate five ad angles

**You will build:** Five distinct campaign angles.

Creates a bounded batch without duplicating blocks manually. The fixed count caps cost before the run starts.

```docsgraph
block-repeat-generate-five-ad-angles
```

[Open this template](/templates/block-repeat-generate-five-ad-angles) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Draft a weekly idea set

**You will build:** One idea for each day of the week.

Turns one theme into a predictable planning batch. Collect-all returns every successful iteration in order.

```docsgraph
block-repeat-draft-a-weekly-idea-set
```

[Open this template](/templates/block-repeat-draft-a-weekly-idea-set) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`source`): `any`, optional, single.
- **Output: Result** (`result`): `any`, optional, single.

## Inspector

- **Number of times:** key `count`; number; range: 1 to 1000; default: `3`.
- **If one run fails:** key `failurePolicy`; select; options: `fail_fast`, `continue`; default: `"fail_fast"`.
- **Runs at once:** key `concurrency`; number; range: 1 to 8; default: `1`.
- **Return:** key `resultPolicy`; select; options: `collect-all`, `last`; default: `"collect-all"`.
- **nested-workflow editor:** manages `body` with edit, validate, preview support.

## Behavior

- **Input requirement:** No inbound value is required by the contract.
- **Execution:** Handled by the orchestrator using `repeat`.
- **Timeout:** No node-level timeout is defined.

## Cost

Uses workflow compute and may contribute to the run's compute cost.

## Security

- No credentials are used.
- The node has no external side effects.

## Retry

Retry and resume behavior is owned by the workflow orchestrator rather than a nested node retry loop.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Result
description: The Result block returns your workflow's final output to whoever ran it. Name it clearly so people and API clients know what they get back.
source: https://www.edgaze.ai/docs/builder/nodes/output
section: builder
---
# Result

> The Result block returns your workflow's final output to whoever ran it. Name it clearly so people and API clients know what they get back.

**Audience: Workflow creators.**

## Overview

Final result of your workflow.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Return a structured audit

**You will build:** A named JSON result for downstream consumers.

Makes the workflow contract clear to runners and API clients. A single terminal result avoids ambiguous completion output.

```docsgraph
block-output-return-a-structured-audit
```

[Open this template](/templates/block-output-return-a-structured-audit) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Deliver publish-ready copy

**You will build:** One clearly labeled text deliverable.

Separates working drafts from the customer-facing result. The terminal label tells operators exactly what completed.

```docsgraph
block-output-deliver-publish-ready-copy
```

[Open this template](/templates/block-output-deliver-publish-ready-copy) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Return an image asset

**You will build:** A clearly named image deliverable.

Gives the runtime one intended final artifact. Keeping one terminal block simplifies API result handling.

```docsgraph
block-output-return-an-image-asset
```

[Open this template](/templates/block-output-return-an-image-asset) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Result** (`in-left`): `any`, optional, single.

## Inspector

- **Output Name:** key `name`; text; default: `"Output"`; Example: e.g., Generated Content.

## Behavior

- **Input requirement:** At least 1 inbound connections are required.
- **Execution:** Handled by the handler using `output`.
- **Timeout:** No node-level timeout is defined.

## Cost

No metered provider or compute cost is assigned to this node.

## Security

- No credentials are used.
- The node has no external side effects.

## Retry

The runtime may retry this node according to the compiled execution policy.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Remixed Workflow
description: Use a pinned published workflow inside your own as a sealed black box: its logic stays private and its behavior stays fixed until you upgrade.
source: https://www.edgaze.ai/docs/builder/nodes/remixed-workflow
section: builder
---
# Remixed Workflow

> Use a pinned published workflow inside your own as a sealed black box: its logic stays private and its behavior stays fixed until you upgrade.

**Audience: Workflow creators.**

## Overview

Compose a pinned workflow as a sealed black box.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Reuse a vetted legal summarizer

**You will build:** A summary produced by a pinned published workflow.

Reuses reviewed logic without exposing or copying its internals. The pinned version keeps behavior stable until you choose to upgrade.

```docsgraph
block-remixed-workflow-reuse-a-vetted-legal-summarizer
```

[Open this template](/templates/block-remixed-workflow-reuse-a-vetted-legal-summarizer) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Embed a brand-approved writer

**You will build:** Copy produced through a sealed brand workflow.

Lets teams compose approved capabilities safely. Credentials and internal prompts remain owned by the parent workflow.

```docsgraph
block-remixed-workflow-embed-a-brand-approved-writer
```

[Open this template](/templates/block-remixed-workflow-embed-a-brand-approved-writer) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Compose a research specialist

**You will build:** A memo from a pinned specialist workflow.

Adds a maintained research capability as one block. Version pinning prevents silent behavior changes.

```docsgraph
block-remixed-workflow-compose-a-research-specialist
```

[Open this template](/templates/block-remixed-workflow-compose-a-research-specialist) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`input`): `any`, optional, single.
- **Output: Output** (`output`): `any`, optional, single.
- **Dynamic contract:** Ports are refined from the pinned `remixContract` metadata.

## Inspector

This node has no direct inspector fields.

## Behavior

- **Input requirement:** No inbound value is required by the contract.
- **Execution:** Handled by the orchestrator using `remixed-workflow`.
- **Timeout:** No node-level timeout is defined.

## Cost

Cost is inherited from the pinned sealed parent workflow.

## Security

- Credentials remain owned by the sealed parent workflow and are not exposed to the containing workflow.
- The node can create externally visible work as part of its execution.

## Retry

Retry and resume behavior is owned by the workflow orchestrator rather than a nested node retry loop.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Call an API
description: Make HTTP requests with explicit host and credential controls.
source: https://www.edgaze.ai/docs/builder/nodes/http-request
section: builder
---
# Call an API

> Make HTTP requests with explicit host and credential controls.

**Audience: Workflow creators.**

## Overview

Make HTTP requests with explicit host and credential controls.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Read a public JSON API

**You will build:** A parsed response from an allowlisted host.

Connects live public data to a workflow. GET requests are retry-safe; keep the host allowlist narrow.

```docsgraph
block-http-request-read-a-public-json-api
```

[Open this template](/templates/block-http-request-read-a-public-json-api) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Create an idempotent webhook event

**You will build:** One externally visible event per workflow run.

Supports controlled write integrations. A stable idempotency key prevents duplicate writes during retries.

```docsgraph
block-http-request-create-an-idempotent-webhook-event
```

[Open this template](/templates/block-http-request-create-an-idempotent-webhook-event) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Check service health

**You will build:** Current service status payload.

Makes an upstream dependency check visible. A short timeout prevents the workflow from waiting indefinitely.

```docsgraph
block-http-request-check-service-health
```

[Open this template](/templates/block-http-request-check-service-health) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Request** (`in`): `any`, optional, single.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **URL:** key `url`; text; default: `""`; Example: https://api.example.com/endpoint.
- **Method:** key `method`; select; options: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`; default: `"GET"`.
- **Credentials:** key `credentialMode`; select; options: `none`, `runner`, `creator_shared`; default: `"none"`.
- **Allowed Hosts (comma-separated):** key `allowOnly`; text; default: `[]`; Required when Credentials is Creator-shared credentials: list at least one host.
- **Denied Hosts (comma-separated):** key `denyHosts`; text; default: `["127.0.0.1","localhost","0.0.0.0"]`.
- **Require idempotency (POST/PUT/PATCH):** key `hasSideEffects`; switch; default: `false`.
- **Idempotency key:** key `idempotencyKey`; text.
- **Timeout (ms):** key `timeout`; number; range: 1000 to 120000; default: `30000`.
- **Follow Redirects:** key `followRedirects`; inline switch; default: `true`.
- **http-request editor:** manages `headers`, `query`, `body`, `credentialRequirements` with edit, validate, preview support.

## Behavior

- **Input requirement:** Provide one of ports `in` or config fields `url`.
- **Execution:** Handled by the handler using `http-request`.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- Credentials may be runner-provided or creator-shared according to the node configuration. Network destination policy is enforced at runtime.
- The configured operation may write externally. Mutating requests require explicit idempotency configuration for safe retries.

## Retry

Automatic retries are allowed only when the operation is retry-safe; mutating requests require a stable run-scoped idempotency key.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Wait
description: Wait for a specified duration before continuing execution.
source: https://www.edgaze.ai/docs/builder/nodes/delay
section: builder
---
# Wait

> Wait for a specified duration before continuing execution.

**Audience: Workflow creators.**

## Overview

Wait for a specified duration before continuing execution.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Pause before a follow-up

**You will build:** The message released after a short pause.

Makes timing an explicit workflow step. The orchestrator persists the wait instead of holding a process open.

```docsgraph
block-delay-pause-before-a-follow-up
```

[Open this template](/templates/block-delay-pause-before-a-follow-up) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Add a provider cooldown

**You will build:** A controlled pause between provider calls.

Reduces accidental burst traffic. A fixed duration is easier to reason about than hidden client-side sleeps.

```docsgraph
block-delay-add-a-provider-cooldown
```

[Open this template](/templates/block-delay-add-a-provider-cooldown) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Hold a scheduled review

**You will build:** The packet continues at the intended review time.

Keeps scheduling logic inside the graph. Durable orchestration resumes the run after worker restarts.

```docsgraph
block-delay-hold-a-scheduled-review
```

[Open this template](/templates/block-delay-hold-a-scheduled-review) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`input`): `any`, optional, single.
- **Output: Output** (`output`): `any`, optional, single.

## Inspector

- **Duration:** key `duration`; number; range: 0 to 604800000; default: `1000`; Pick milliseconds, seconds, minutes or hours next to the value; the wait is stored in milliseconds.

## Behavior

- **Input requirement:** No inbound value is required by the contract.
- **Execution:** Handled by the orchestrator using `delay`.
- **Timeout:** 1000 ms by default (0 to 604800000 ms).

## Cost

No metered provider or compute cost is assigned to this node.

## Security

- No credentials are used.
- The node has no external side effects.

## Retry

Retry and resume behavior is owned by the workflow orchestrator rather than a nested node retry loop.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Aviato
description: B2B person and company data: profiles, contact details, investors, posts. Nothing to connect: Edgaze calls Aviato and the cost is in the run's price.
source: https://www.edgaze.ai/docs/builder/nodes/integration-aviato
section: builder
---
# Aviato

> B2B person and company data: profiles, contact details, investors, posts. Nothing to connect: Edgaze calls Aviato and the cost is in the run's price.

**Audience: Workflow creators.**

## Overview

B2B person and company data: profiles, contact details, investors, posts.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You do not need an Aviato account or API key, and neither does anyone running the workflow. Edgaze is Aviato's customer: each action has a fixed published price that is already part of the workflow's per-run price, so a run simply costs what it shows.

### Actions

- **Enrich a person** - Full profile for one person: identity, work history, education, links. Needs: Person.
- **Enrich people in bulk** - Full profiles for up to 20 people in one call. Billed per successful lookup. Needs: People.
- **Get a person's contact info** - Email addresses and other contact channels for one person. Needs: Person.
- **Get contact info in bulk** - Contact channels for up to 20 people in one call. Billed per lookup. Needs: People.
- **Get a person's email hash** - Hashed email identifiers for one person, for audience matching. Needs: Person.
- **Get a person's phone number** - Phone numbers on record for one person. Needs: Person.
- **Companies a person founded** - Companies founded by this person, paged. Needs: Person.
- **A person's company investments** - Companies this person has invested in, paged. Needs: Person.
- **A person's fund investments** - Funds this person has invested in, paged. Needs: Person.
- **A person's vestings** - Equity vesting records for this person, paged. Needs: Person.
- **Search people** - Find people matching an Aviato DSL query, paged. Needs: Search query.
- **Enrich a company** - Full company profile: identity, traction, tech stack, jobs, links. Needs: Company.
- **Enrich companies in bulk** - Full company profiles for up to 100 lookups in one call. Billed per successful lookup. Needs: Companies.
- **A company's acquisitions** - Acquisitions this company has made, paged. Needs: Company.
- **A company's employees** - People working at this company, paged. Needs: Company.
- **A company's founders** - The founders of this company, paged. Needs: Company.
- **A company's funding rounds** - Funding rounds this company has raised, paged. Needs: Company.
- **Funds linked to a company** - Funds associated with this company, paged. Needs: Company.
- **A company's fund investments** - Fund investments involving this company, paged. Needs: Company.
- **A company's outbound investments** - Investments this company has made into others, paged. Needs: Company.
- **Search companies** - Find companies matching an Aviato DSL query, paged. Needs: Search query.
- **A company's LinkedIn posts** - Recent public posts from a company's LinkedIn page, paged. Needs: Company.
- **A person's LinkedIn posts** - Recent public posts from a person's LinkedIn profile, paged. Needs: Person.
- **Comments on a LinkedIn post** - Public comments on one LinkedIn post, paged. Needs: Post URN.
- **Reactions on a LinkedIn post** - Public reactions on one LinkedIn post, paged. Needs: Post URN.
- **Reshares of a LinkedIn post** - Public reshares of one LinkedIn post, paged. Needs: Post URN.
- **Generate a market map** - Start a market map of companies similar to one you name. Returns a map ID. Needs: Company name.
- **Geocode a place** - Resolve a place name to locations and coordinates. Needs: Place.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Limits and pricing

Prices are in USD per call, include the platform margin, and are shown rounded up to the next cent; billing itself computes exact amounts. A run always reserves the maximum an action can cost before it starts, and lookups the provider gates out (for example an unmet required field, or a free preview) are not billed.

| Action                                                          | Price                                 | What changes it                                                                                     |
| --------------------------------------------------------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------- |
| ![](/integrations/aviato.webp) Enrich a person                  | $0.06 per call                        | +$0.04 when looking up by email; +$0.03 when refreshing stale data; Preview mode is free            |
| ![](/integrations/aviato.webp) Enrich people in bulk            | $0.06 per lookup (up to 20 per call)  | +$0.04 per lookup when looking up by email; +$0.03 when refreshing stale data; Preview mode is free |
| ![](/integrations/aviato.webp) Get a person's contact info      | $0.09 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Get contact info in bulk         | $0.09 per lookup (up to 20 per call)  | -                                                                                                   |
| ![](/integrations/aviato.webp) Get a person's email hash        | $0.09 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Get a person's phone number      | $0.09 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Companies a person founded       | $0.006 per call                       | -                                                                                                   |
| ![](/integrations/aviato.webp) A person's company investments   | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A person's fund investments      | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A person's vestings              | $0.11 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Search people                    | $0.003 per call                       | -                                                                                                   |
| ![](/integrations/aviato.webp) Enrich a company                 | $0.17 per call                        | +$0.06 when refreshing stale data; Preview mode is free                                             |
| ![](/integrations/aviato.webp) Enrich companies in bulk         | $0.17 per lookup (up to 100 per call) | +$0.06 when refreshing stale data                                                                   |
| ![](/integrations/aviato.webp) A company's acquisitions         | $0.03 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A company's employees            | $0.006 per call                       | -                                                                                                   |
| ![](/integrations/aviato.webp) A company's founders             | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A company's funding rounds       | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Funds linked to a company        | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A company's fund investments     | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A company's outbound investments | $0.02 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Search companies                 | $0.003 per call                       | -                                                                                                   |
| ![](/integrations/aviato.webp) A company's LinkedIn posts       | $0.06 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) A person's LinkedIn posts        | $0.06 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Comments on a LinkedIn post      | $0.03 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Reactions on a LinkedIn post     | $0.03 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Reshares of a LinkedIn post      | $0.03 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Generate a market map            | $0.17 per call                        | -                                                                                                   |
| ![](/integrations/aviato.webp) Geocode a place                  | $0.002 per call                       | -                                                                                                   |

The most one call of this block can cost is $21.60 (Enrich companies in bulk with every option on). Batch actions bill per lookup and are capped at the vendor's own batch size.

### Trying it

Test runs make real Aviato calls and are metered exactly like a published run, so test with the smallest inputs first. Preview options return only enough to confirm a match and are free.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Investor profile lookup

**You will build:** A structured profile of the person, ready for an outreach or research step.

No API key or account is needed anywhere: the lookup price is already inside the run price. The run reserves the lookup's cost before it starts, and an unbilled miss never charges.

```docsgraph
block-integration-aviato-investor-profile-lookup
```

[Open this template](/templates/block-integration-aviato-investor-profile-lookup) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Company shortlist enrichment

**You will build:** Full profiles for a shortlist of companies in one pass.

Batching keeps research cheap: up to 100 companies per call, each billed only when found. Per-lookup billing means a gated or missing company never costs a credit, and the batch ceiling is reserved up front.

```docsgraph
block-integration-aviato-company-shortlist-enrichment
```

[Open this template](/templates/block-integration-aviato-company-shortlist-enrichment) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Founder funding research

**You will build:** The company's funding rounds, paged from real market data.

Funding history lands directly in the graph, without scraping or manual research. Reads are idempotent and priced per page, so re-running the research stays predictable.

```docsgraph
block-integration-aviato-founder-funding-research
```

[Open this template](/templates/block-integration-aviato-founder-funding-research) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose the action and where each field's value comes from. See _Setting it up_ above for what it costs.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the platform's managed data provider connection; Edgaze is the customer, no account is involved on the runner's side.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Makes a metered third-party data call that Edgaze itself pays for; the action's price is included in the workflow's run price. The run reserves the action's maximum possible cost before it starts.

## Security

- No account is connected by anyone: Edgaze is the data provider's customer and calls it with the platform's own key. The per-call price is metered into the workflow's run price.
- Calls carry the platform's key only; no runner account, token, or personal data access is ever involved.

## Retry

A call is never retried by the engine, so a bug can never bill the same lookup twice; transient provider failures are retried once inside the single attempt before the step fails.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: GitHub
description: Read and write issues and pull requests in repositories you connect. People running it connect their own GitHub account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-github
section: builder
---
# GitHub

> Read and write issues and pull requests in repositories you connect. People running it connect their own GitHub account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Read and write issues and pull requests in repositories you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's GitHub sign-in, and you do not need your own GitHub account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **Create an issue** - Opens a new issue in the selected repository. Makes a change. Needs: Title. Optional: Description, Labels. People running it are asked to allow: _Create issues in the repository they choose_.
- **Comment on an issue** - Adds a comment to an existing issue or pull request. Makes a change. Needs: Issue number, Comment. People running it are asked to allow: _Comment on issues in the repository they choose_.
- **Open a pull request** - Opens a pull request between two branches that already exist. Makes a change. Needs: Title, From branch, Into branch. Optional: Description, Open as draft. People running it are asked to allow: _Open pull requests in the repository they choose_.
- **List issues** - Reads issues from the selected repository. Only looks things up. Optional: Which issues, Only with labels, Maximum issues. People running it are asked to allow: _Read issues in the repository they choose_.
- **List pull requests** - Reads pull requests from the selected repository. Only looks things up. Optional: Which pull requests, Maximum pull requests. People running it are asked to allow: _Read pull requests in the repository they choose_.
- **Search issues** - Finds issues in the selected repository matching words you give it. Only looks things up. Needs: Look for. Optional: Which issues, Maximum issues. People running it are asked to allow: _Search issues in the repository they choose_.
- **Add labels to an issue** - Labels an existing issue or pull request. Makes a change. Needs: Issue number, Labels. People running it are asked to allow: _Label issues in the repository they choose_.

### Which repository it acts on

- **The person running picks a repository** - the default, and the right choice for anything you publish. They choose one of their own repositories before the run starts.
- **Always this repository** - fixed to one you name. Use it for a workflow only you will run.
- **Any repository they allow** - reaches every repository their connection covers. They see a clear warning, and the run gets a lower limit on actions.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample GitHub data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Bug report to GitHub issue

**You will build:** A filed issue in the repository the runner chose, with a link back.

The person running it connects their own GitHub and picks the repository, so the issue lands where they expect. The run cannot start until they authorize it, and a crash mid-write reconciles instead of filing a duplicate.

```docsgraph
block-integration-github-bug-report-to-github-issue
```

[Open this template](/templates/block-integration-github-bug-report-to-github-issue) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Weekly issue digest

**You will build:** A readable summary of what changed in the window you name, from real issues.

Reading needs no write permission, so the consent screen stays narrow. Reads are safe to retry, so a transient GitHub outage never loses the run.

```docsgraph
block-integration-github-weekly-issue-digest
```

[Open this template](/templates/block-integration-github-weekly-issue-digest) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Triage comment on an open issue

**You will build:** A comment added to the issue the runner named.

Commenting keeps the discussion where the team already works. The comment is reconciled after an interruption, so a retry never posts twice.

```docsgraph
block-integration-github-triage-comment-on-an-open-issue
```

[Open this template](/templates/block-integration-github-triage-comment-on-an-open-issue) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Slack
description: Post messages to channels you connect. People running it connect their own Slack account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-slack
section: builder
---
# Slack

> Post messages to channels you connect. People running it connect their own Slack account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Post messages to channels you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's Slack sign-in, and you do not need your own Slack account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **Post a message** - Posts a message to the selected channel. Makes a change. Needs: Message. Optional: Reply in thread. People running it are asked to allow: _Post messages to the channel they choose_.
- **Read recent messages** - Reads recent messages from the selected channel, then feeds them to a later step. Only looks things up. Optional: How many messages. People running it are asked to allow: _Read recent messages in the channel they choose_.
- **Add a reaction** - Adds an emoji reaction to a message in the selected channel. Makes a change. Needs: Message timestamp, Emoji name. People running it are asked to allow: _Add emoji reactions in the channel they choose_.
- **List channels** - Reads the public channels in the workspace. Only looks things up. Optional: Maximum channels. People running it are asked to allow: _See which channels Edgaze can post to_.

### Which channel it acts on

- **The person running picks a channel** - the default, and the right choice for anything you publish. They choose one of their own channels before the run starts.
- **Always this channel** - fixed to one you name. Use it for a workflow only you will run.
- **Any channel they allow** - reaches every channel their connection covers. They see a clear warning, and the run gets a lower limit on actions.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample Slack data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Post a summary to a channel

**You will build:** A message in the channel the runner picked.

The runner chooses the channel, so nothing is posted where they did not intend. A retried post is reconciled against recent history rather than duplicated.

```docsgraph
block-integration-slack-post-a-summary-to-a-channel
```

[Open this template](/templates/block-integration-slack-post-a-summary-to-a-channel) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Route a request to the right channel

**You will build:** The request lands in the channel that owns it.

Classification plus posting replaces manual triage. Channel selection happens at authorization, not at runtime, so routing cannot drift.

```docsgraph
block-integration-slack-route-a-request-to-the-right-channel
```

[Open this template](/templates/block-integration-slack-route-a-request-to-the-right-channel) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Daily standup prompt

**You will build:** A consistent prompt posted to one channel whenever someone runs it.

One run at the start of the day posts the prompt, so nobody has to write it from scratch. The call ceiling on the authorization stops a loop from flooding the channel.

```docsgraph
block-integration-slack-daily-standup-prompt
```

[Open this template](/templates/block-integration-slack-daily-standup-prompt) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Google Sheets
description: Read and append rows in spreadsheets you connect. People running it connect their own Google Sheets account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-google-sheets
section: builder
---
# Google Sheets

> Read and append rows in spreadsheets you connect. People running it connect their own Google Sheets account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Read and append rows in spreadsheets you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's Google Sheets sign-in, and you do not need your own Google Sheets account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **Append a row** - Adds a row to the end of the selected sheet. Makes a change. Needs: Row values. Optional: Tab. People running it are asked to allow: _Add rows to the spreadsheet they choose_.
- **Read a range** - Reads cells from the selected sheet. Only looks things up. Optional: Cells to read. People running it are asked to allow: _Read data from the spreadsheet they choose_.
- **Find rows** - Finds the rows where a column matches, so a later step can use them. Only looks things up. Needs: Column, Matching. Optional: Cells to read. People running it are asked to allow: _Find rows in the spreadsheet they choose_.

### Which spreadsheet it acts on

- **The person running picks a spreadsheet** - the default, and the right choice for anything you publish. They choose one of their own spreadsheets before the run starts.
- **Always this spreadsheet** - fixed to one you name. Use it for a workflow only you will run.
- **Any spreadsheet they allow** - reaches every spreadsheet their connection covers. They see a clear warning, and the run gets a lower limit on actions.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample Google Sheets data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Log run results to a sheet

**You will build:** One row added to the spreadsheet the runner chose.

A sheet is where most teams already keep records, so nothing new has to be learned. An interrupted append is checked before retrying, so a row is never doubled.

```docsgraph
block-integration-google-sheets-log-run-results-to-a-sheet
```

[Open this template](/templates/block-integration-google-sheets-log-run-results-to-a-sheet) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Read a sheet into a summary

**You will build:** A plain summary of what the sheet currently holds.

Reading requires no write access, keeping the consent screen minimal. Reads retry safely, so a slow response never fails the run.

```docsgraph
block-integration-google-sheets-read-a-sheet-into-a-summary
```

[Open this template](/templates/block-integration-google-sheets-read-a-sheet-into-a-summary) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Track intake requests

**You will build:** Every request captured in one place, timestamped.

Appending is the least invasive way to keep a shared record. The runner picks the spreadsheet, so nothing is written to a sheet they did not choose.

```docsgraph
block-integration-google-sheets-track-intake-requests
```

[Open this template](/templates/block-integration-google-sheets-track-intake-requests) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Google Docs
description: Create, read and append to documents you connect. People running it connect their own Google Docs account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-google-docs
section: builder
---
# Google Docs

> Create, read and append to documents you connect. People running it connect their own Google Docs account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Create, read and append to documents you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's Google Docs sign-in, and you do not need your own Google Docs account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **Create a document** - Creates a blank document with a title. Makes a change. Needs: Title. People running it are asked to allow: _Create documents_.
- **Read a document** - Reads the text of the selected document. Only looks things up. People running it are asked to allow: _Read the document they choose_.
- **Append text** - Adds text to the end of the selected document. Makes a change. Needs: Text to add. People running it are asked to allow: _Add text to the document they choose_.

### Which document it acts on

- **The person running picks a document** - the default, and the right choice for anything you publish. They choose one of their own documents before the run starts.
- **Always this document** - fixed to one you name. Use it for a workflow only you will run.
- **Any document they allow** - reaches every document their connection covers. They see a clear warning, and the run gets a lower limit on actions.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample Google Docs data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Append to a running log doc

**You will build:** Each run appends one entry to a shared document.

A document is the running note teams already keep. An interrupted append is checked against the end of the document, never doubled.

```docsgraph
block-integration-google-docs-append-to-a-running-log-doc
```

[Open this template](/templates/block-integration-google-docs-append-to-a-running-log-doc) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Read a brief from a doc

**You will build:** The workflow answers from the doc's current text.

Reading needs no write permission, so the consent screen stays narrow. Reads retry safely; a slow response never loses the run.

```docsgraph
block-integration-google-docs-read-a-brief-from-a-doc
```

[Open this template](/templates/block-integration-google-docs-read-a-brief-from-a-doc) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Meeting notes file

**You will build:** A fresh notes document, titled and linked.

A document per meeting beats hunting through one unending file. A document create cannot be checked after a crash, so the run fails openly rather than risking a duplicate.

```docsgraph
block-integration-google-docs-meeting-notes-file
```

[Open this template](/templates/block-integration-google-docs-meeting-notes-file) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Google Calendar
description: Read and add events on calendars you connect. People running it connect their own Google Calendar account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-google-calendar
section: builder
---
# Google Calendar

> Read and add events on calendars you connect. People running it connect their own Google Calendar account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Read and add events on calendars you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's Google Calendar sign-in, and you do not need your own Google Calendar account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **List events** - Reads upcoming events from the selected calendar. Only looks things up. Optional: Maximum events, Only after. People running it are asked to allow: _Read events from the calendar they choose_.
- **Create an event** - Adds an event to the selected calendar. Makes a change. Needs: Title, Starts, Ends. Optional: Description. People running it are asked to allow: _Add events to the calendar they choose_.

### Which calendar it acts on

- **The person running picks a calendar** - the default, and the right choice for anything you publish. They choose one of their own calendars before the run starts.
- **Always this calendar** - fixed to one you name. Use it for a workflow only you will run.
- **Any calendar they allow** - reaches every calendar their connection covers. They see a clear warning, and the run gets a lower limit on actions.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample Google Calendar data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Block time after a booking

**You will build:** A calendar event on the calendar the person chose.

The person picks the calendar, so nothing lands where they did not expect. An interrupted create reconciles against the slot, so no double booking appears.

```docsgraph
block-integration-google-calendar-block-time-after-a-booking
```

[Open this template](/templates/block-integration-google-calendar-block-time-after-a-booking) and adapt the labels, prompts, or credentials to your own workflow.

### 2. What's on today

**You will build:** A plain-language agenda from the calendar.

Reading needs no write permission, keeping the consent screen minimal. Reads retry safely, so a slow Calendar response never fails the run.

```docsgraph
block-integration-google-calendar-what-s-on-today
```

[Open this template](/templates/block-integration-google-calendar-what-s-on-today) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Schedule a reminder

**You will build:** A timed reminder on the person's own calendar.

A calendar reminder works even when the phone is away from the app that made it. The run's action ceiling stops a loop from filling the calendar.

```docsgraph
block-integration-google-calendar-schedule-a-reminder
```

[Open this template](/templates/block-integration-google-calendar-schedule-a-reminder) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Google Drive
description: Save and read text files created by Edgaze. People running it connect their own Google Drive account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-google-drive
section: builder
---
# Google Drive

> Save and read text files created by Edgaze. People running it connect their own Google Drive account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Save and read text files created by Edgaze.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's Google Drive sign-in, and you do not need your own Google Drive account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **Save a text file** - Saves text as a file in the person's Drive, visible as created by Edgaze. Makes a change. Needs: File name, File contents. People running it are asked to allow: _Save files to your Drive_.
- **List Edgaze files** - Lists files Edgaze created in the person's Drive. Only looks things up. Optional: Maximum files. People running it are asked to allow: _See the Drive files Edgaze created_.
- **Read a text file** - Reads the contents of a saved text file. Only looks things up. People running it are asked to allow: _Read the file they choose in your Drive_.

### Which file it acts on

- **The person running picks a file** - the default, and the right choice for anything you publish. They choose one of their own files before the run starts.
- **Always this file** - fixed to one you name. Use it for a workflow only you will run.
- **Any file they allow** - reaches every file their connection covers. They see a clear warning, and the run gets a lower limit on actions.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample Google Drive data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Save a report as a file

**You will build:** The report lands in Drive as a plain-text file.

Edgaze can only touch files it created or the person opened with it. Their Drive stays their own. An interrupted save is checked by file name before retrying.

```docsgraph
block-integration-google-drive-save-a-report-as-a-file
```

[Open this template](/templates/block-integration-google-drive-save-a-report-as-a-file) and adapt the labels, prompts, or credentials to your own workflow.

### 2. List Edgaze-made files

**You will build:** A list of what the workflow has actually saved.

drive.file scopes visibility to Edgaze-created files, so listing is safe by construction. Reads retry safely, so a transient Drive outage never fails the run.

```docsgraph
block-integration-google-drive-list-edgaze-made-files
```

[Open this template](/templates/block-integration-google-drive-list-edgaze-made-files) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Read back a saved file

**You will build:** The workflow answers from the file's saved text.

Only files the run picks are ever read. Reads retry safely; nothing is written.

```docsgraph
block-integration-google-drive-read-back-a-saved-file
```

[Open this template](/templates/block-integration-google-drive-read-back-a-saved-file) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Gmail
description: Send email from the Gmail account you connect. People running it connect their own Gmail account and approve what it can do.
source: https://www.edgaze.ai/docs/builder/nodes/integration-gmail
section: builder
---
# Gmail

> Send email from the Gmail account you connect. People running it connect their own Gmail account and approve what it can do.

**Audience: Workflow creators.**

## Overview

Send email from the Gmail account you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

## Setting it up

You never see anyone's Gmail sign-in, and you do not need your own Gmail account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

### Actions

- **Send an email** - Sends an email from the connected Gmail account. Makes a change. Needs: To, Subject, Message. People running it are asked to allow: _Send email from your Gmail account_.

### Filling in the fields

Every field can be filled three ways: **type it** (a fixed value), **from a step** (a value an earlier step produced - pick it from a list, no paths to type), or **text + steps** (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

### Trying it

Test runs from the canvas use sample Gmail data. Nothing reaches a real account until someone runs the published workflow with their own connection.

## Working examples

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

### 1. Follow-up email after a run

**You will build:** An email the person reviews goes out from their account.

Sending is all this can do. Nobody's inbox is ever read. A send that cannot be checked never retries blindly; the run fails instead of double-sending.

```docsgraph
block-integration-gmail-follow-up-email-after-a-run
```

[Open this template](/templates/block-integration-gmail-follow-up-email-after-a-run) and adapt the labels, prompts, or credentials to your own workflow.

### 2. Expense receipt to the bookkeeper

**You will build:** The receipt arrives in the right inbox, formatted.

One approved address per run keeps money-adjacent email deliberate. The approval screen names exactly this action before the run can start.

```docsgraph
block-integration-gmail-expense-receipt-to-the-bookkeeper
```

[Open this template](/templates/block-integration-gmail-expense-receipt-to-the-bookkeeper) and adapt the labels, prompts, or credentials to your own workflow.

### 3. Daily summary email

**You will build:** A summary lands in an inbox each time the workflow runs.

Email still beats chat for the people who matter here. A paused or interrupted run can't send half an email twice.

```docsgraph
block-integration-gmail-daily-summary-email
```

[Open this template](/templates/block-integration-gmail-daily-summary-email) and adapt the labels, prompts, or credentials to your own workflow.

## Ports

- **Input: Input** (`in`): `any`, optional, multi_object.
- **Output: Success** (`success`): `object`, optional, single.
- **Output: Error** (`error`): `object`, optional, single.

## Inspector

- **Action panel:** choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

## Behavior

- **Input requirement:** Choose an action. Fields can come from earlier steps or be typed in.
- **Execution:** Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
- **Timeout:** 30000 ms by default (1000 to 120000 ms).

## Cost

Uses outbound HTTP transport and may contribute to the run's compute cost.

## Security

- The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
- Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

## Retry

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

## Production checklist

- Test the happy path and one malformed or empty input.
- Keep credentials out of prompts and published graph configuration.
- Set a timeout that matches the operation's side effects.
- Name the final result so a runner can tell what success looks like.


---

---
title: Billing & Runs
description: How workflow runs are priced, funded, settled, and refunded. Guides for buyers, creators, and developers.
source: https://www.edgaze.ai/docs/billing
---

# Billing & Runs

> How workflow runs are priced, funded, settled, and refunded. Guides for buyers, creators, and developers.

## For buyers

- [Run a Workflow](https://www.edgaze.ai/docs/billing/run-a-workflow.md): How to open a workflow, fund a run, and what happens when it completes.
- [What You Pay For](https://www.edgaze.ai/docs/billing/what-you-pay-for.md): How the per-run price is built, what the creator earns, and what Edgaze keeps.
- [Funding Runs](https://www.edgaze.ai/docs/billing/funding-runs.md): How your wallet and workflow bundles fund runs started in the app or through the API.
- [When Runs Fail](https://www.edgaze.ai/docs/billing/when-runs-fail.md): What you pay when a run fails, is cancelled, or is stopped for exceeding its compute limit.
- [Refunds](https://www.edgaze.ai/docs/billing/refunds.md): How to ask Edgaze support to review a refund, what support checks, and what you get back for a wallet top-up, purchase, or run.

## For creators

- [Publish and Price](https://www.edgaze.ai/docs/billing/publish-and-price.md): How creators set margin, how compute is estimated, and what buyers see at checkout.
- [Creator Earnings Guide](https://www.edgaze.ai/docs/billing/creator-earnings-guide.md): How creator earnings from paid runs accrue, clear from pending to available, and pay out to your connected Stripe account, step by step.
- [BYOK (Bring Your Own Key)](https://www.edgaze.ai/docs/billing/byok.md): Run on your own API keys with Edgaze Plus: which steps use your keys, what you pay Edgaze, and what your provider bills.
- [Failover](https://www.edgaze.ai/docs/billing/failover.md): When Edgaze switches to a backup model, your price stays the same.

## For developers

- [API Runs](https://www.edgaze.ai/docs/billing/api-runs.md): Billing for workflow runs triggered through the REST API, including spend caps.
- [Version Pinning](https://www.edgaze.ai/docs/billing/version-pinning.md): How prices lock to a workflow version and what happens when creators publish new versions.
- [Remix Workflows](https://www.edgaze.ai/docs/billing/remix-and-nested-workflows.md): How a workflow can use one published parent workflow, how pricing works, and how each creator earns.

## Reference

- [Bundles Expiry and Refunds](https://www.edgaze.ai/docs/billing/bundles-expiry-refunds.md): When prepaid bundles expire, what happens to unused runs, and refund options.
- [Run Outcomes Reference](https://www.edgaze.ai/docs/billing/run-outcomes-reference.md): Quick reference for customer charges and creator earnings across common run scenarios.
- [Legacy Unlock](https://www.edgaze.ai/docs/billing/legacy-unlock.md): One-time purchase listings from before per-run pricing existed.


---

---
title: Run a Workflow
description: How to open a workflow, fund a run, and what happens when it completes.
source: https://www.edgaze.ai/docs/billing/run-a-workflow
section: billing
---
# Run a Workflow

> How to open a workflow, fund a run, and what happens when it completes.

**Audience: Buyers and creators using Edgaze.**

## Overview

Running a hosted workflow is a per-run purchase. You see one price upfront. That price covers the creator's margin plus the compute needed to run the workflow at its maximum allowed input size. You pay from a prepaid bundle tied to that workflow version, or from your wallet balance.

Successful runs charge the displayed price. The creator earns 80% of their margin. Failed or cancelled runs do not charge the creator's margin and do not use a bundle run. Demo runs are always free. Workflow Studio test runs use your weekly Studio usage allowance instead.

## What you pay

The run panel shows a single price. It equals the creator's margin plus the estimated compute at the input limit set when the workflow was published. You never see a breakdown of tokens, compute costs, or platform fees in the app.

```docprice
{"margin":0.05,"compute":0.012,"label":"Example at max input"}
```

Within the allowed input size, that price stays fixed. Smaller inputs do not reduce the price. Inputs above the limit are blocked before any charge.

## How funding works

When you start a run, Edgaze checks your funding in this order:

1. A prepaid bundle for this workflow and version, if you have runs left
2. Your wallet balance

If you have no bundle runs and your wallet cannot cover the run's reservation, the run will not start. You will see an insufficient funds message.

Bundle-funded runs use one prepaid run instead of debiting your wallet for that execution. Wallet-funded runs temporarily reserve a little more than the displayed price to cover compute variance. Only the displayed price is charged, and the unused reservation is released when the run finishes.

## Starting a run

Open the workflow product page, choose an available version, and confirm the displayed per-run price. Current per-run workflows do not require a separate access purchase. Checkout is used only to add wallet funds, buy a bundle, or purchase a supported [legacy unlock](/docs/legacy).

Provide input that fits within the workflow's limits (file size, pages, tokens, or other constraints set at publish). When you trigger the run, the workflow executes on Edgaze's hosted engine.

On success, wallet-funded runs charge your balance for the displayed price. Bundle-funded runs consume one prepaid run. The creator earns 80% of their margin.

## Waiting in line

When Edgaze is at capacity, your run may wait in line before it starts. The run panel shows your place in line, and you can leave the page: the run still starts when a slot frees up, and signed-in runs get an email when it is done. Plus runs get priority in the line.

Your funding stays reserved while the run waits. If you cancel a waiting run, or it cannot start within its wait limit, it ends without a charge, the reservation is released, and a bundle run is not consumed.

## Special cases

**Demo run.** No charge, no creator earnings. A demo badge appears on the run surface.

**Builder test run.** No charge to your wallet while your weekly Workflow Studio allowance lasts (see [Pricing Limits](/docs/pricing-limits)). Once it is used up and you turn on **Use wallet funds**, a test run pays its compute price from your wallet with no margin. Nobody earns from your own test runs.

**Legacy unlock listing.** Some older listings use a one-time purchase model instead of per-run pricing. See [Legacy Unlock](/docs/billing/legacy-unlock).

## What you see in Edgaze

- Product page: one displayed per-run price and input limit
- Run panel: price quote, funding hint (bundle runs remaining or wallet), run progress, and completion or failure message
- Wallet page: balance, available after active runs, and transaction history after successful runs
- Demo flows: verification step and demo badge; no price debit on completion

## Related policies

- [What You Pay For](/docs/billing/what-you-pay-for)
- [Funding Runs](/docs/billing/funding-runs)
- [When Runs Fail](/docs/billing/when-runs-fail)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [Refund Policy](/docs/refund-policy)


---

---
title: What You Pay For
description: How the per-run price is built, what the creator earns, and what Edgaze keeps.
source: https://www.edgaze.ai/docs/billing/what-you-pay-for
section: billing
---
# What You Pay For

> How the per-run price is built, what the creator earns, and what Edgaze keeps.

**Audience: Buyers and creators using Edgaze.**

## Overview

Every per-run listing charges one displayed price. That price is the sum of the creator's margin and the estimated compute at the workflow's maximum allowed input. Within that input envelope, the price is fixed. Edgaze handles small compute variance inside the envelope.

```docprice
{"margin":0.05,"compute":0.012,"label":"Example at max input"}
```

Example: a $0.05 margin plus $0.012 compute yields a $0.062 per-run price. The creator earns $0.04 on that run (80% of the margin, rounded down to the nearest microdollar, $0.000001).

## The two parts of your price

**Creator margin** is set at publish, from $0.05 to $50.00 per workflow run. **Hosted compute** is Edgaze's estimate at the largest accepted input. Buyers see the total before running.

Compute covers platform cost. It is not creator revenue. The creator never earns a share of compute.

## What the creator earns

On a successful run, the creator receives 80% of their margin, rounded down to the nearest microdollar ($0.000001). Edgaze retains 20% of the margin as the platform fee.

This applies per workflow in composed runs. Each called workflow earns on its own margin when it executes.

## Fixed price within the envelope

The displayed price does not change with smaller inputs inside the envelope. Inputs above the envelope are rejected before any charge.

## BYOK and failover

**Non-hosted provider modes (Plus).** Hosted compute is replaced by $0.002 for Edgaze orchestration. The provider bills the owner of the connected key. See [BYOK](/docs/billing/byok).

**Failover.** If a run continues with an eligible alternative model, your displayed price stays the same. Creators on Plus can disable failover so the run fails instead. See [Failover](/docs/billing/failover).

## Special cases

- **Remix workflow:** The displayed price includes the permitted parent workflow and the new workflow. Each creator earns on their own margin.
- **Version pin:** You pay the margin and compute for the version you run, not necessarily the latest published price.
- **Failed run:** No charge. See [When Runs Fail](/docs/billing/when-runs-fail).
- **Completed with issues:** A step the creator allowed to fail failed, but the run finished with outputs. You pay only the compute of the steps that finished, with no creator price. See [When Runs Fail](/docs/billing/when-runs-fail).
- **Stopped at the compute limit:** Already-consumed compute may be retained. The creator's margin is released. This is separate from an ordinary failed run.

## What you see in Edgaze

- Product and run UI: a single dollar amount per run
- Publish preview (creators): margin input, hosted compute estimate, displayed buyer price, and creator-earnings preview
- Wallet history after a successful run: charge lines for the run, not raw token counts

## Related policies

- [Publish and Price](/docs/billing/publish-and-price)
- [Creator Earnings Guide](/docs/billing/creator-earnings-guide)
- [Marketplace Fees](/docs/marketplace-fees)
- [Pricing Limits](/docs/pricing-limits)
- [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation)


---

---
title: Funding Runs
description: How your wallet and workflow bundles fund runs started in the app or through the API.
source: https://www.edgaze.ai/docs/billing/funding-runs
section: billing
---
# Funding Runs

> How your wallet and workflow bundles fund runs started in the app or through the API.

**Audience: Buyers and creators using Edgaze.**

## Overview

You fund runs from your wallet or a prepaid workflow bundle. The app and API are ways to start a run; both use the same funding order: matching bundle first, then wallet.

```docfunding
{"doors":["bundle","wallet"]}
```

Bundles are locked to one workflow version. They contain 5 or 10 runs, have a $5.00 minimum total, and expire after 2 years.

## Wallet

Top up at least $10.00 through checkout. Wallet balance works across current per-run workflows. The app shows the amount currently available to spend.

Wallet is the most flexible option if you run many different workflows.

## Prepaid bundles

A bundle prepays 5 or 10 runs for one workflow version. The total equals the displayed per-run price times the pack size and must be at least $5.00.

Bundle runs draw before wallet on every trigger. A run on your own API keys is the exception: it pays the own-keys price from your wallet and leaves your bundle runs untouched. Failed runs do not consume a bundle run. When your bundle is empty or expired, funding falls through to your wallet.

## At trigger

When you start a run, Edgaze checks for an eligible bundle matching you, the workflow, and the exact version that runs. If one exists with runs remaining and has not expired, that run uses the bundle. When you do not choose a version and you hold a bundle, the run uses the version the bundle was bought for.

Otherwise the run is funded from your wallet. A wallet-funded run temporarily reserves a little more than the displayed price to cover compute variance. Only the displayed price is charged, and the unused reservation is released when the run finishes. If your wallet cannot cover that reservation and no bundle run is available, execution does not start and no charge is made. A REST API request may first return `202` and later report the run as `failed`.

API-triggered runs follow the same order. API keys can also set a spend cap that rejects the request immediately. See the [API funding table](/docs/api/create-run#funding-and-acceptance-behavior).

## After the run

A successful bundle-funded run consumes one prepaid run. A successful wallet-funded run charges your balance for the displayed price.

A failed or cancelled run is not ordinarily charged. Bundle runs are not consumed on failure.

## Special cases

- **Bundle depleted:** Funding falls through to wallet. If wallet is insufficient, the run will not start.
- **New version published:** A bundle keeps running the version it was bought for. A run without a chosen version uses that version and draws from the bundle. If you pick a different version, that run uses wallet at its own price. See [Version Pinning](/docs/billing/version-pinning).
- **Expired bundle:** Excluded from funding. You must use wallet or the run will not start.
- **Insufficient wallet:** If your available balance cannot cover the run's reservation, no execution starts and no charge is made. An accepted API request later reports `failed`.

## What you see in Edgaze

- Checkout: wallet top-up, 5-run bundle, and 10-run bundle options with per-run and total prices
- Workflow page: "runs left" counter when you hold a prepaid bundle
- Wallet page: top-ups, bundle purchases, and charges
- Insufficient funds or spend cap messages when a run cannot start

## Related policies

- [Run a Workflow](/docs/billing/run-a-workflow)
- [API Runs](/docs/billing/api-runs)
- [Bundles Expiry and Refunds](/docs/billing/bundles-expiry-refunds)
- [Payments Overview](/docs/payments-overview)
- [Refund Policy](/docs/refund-policy)


---

---
title: Publish and Price
description: How creators set margin, how compute is estimated, and what buyers see at checkout.
source: https://www.edgaze.ai/docs/billing/publish-and-price
section: billing
---
# Publish and Price

> How creators set margin, how compute is estimated, and what buyers see at checkout.

**Audience: Creators pricing and selling workflows.**

## Overview

Creators publish a workflow margin between $0.05 and $50.00 per run. Edgaze derives the hosted compute estimate from the workflow graph and maximum allowed input. Buyers see one displayed price: margin plus applicable compute.

Creators preview earnings as 80% of margin, not a share of the displayed price.

```docchargeflow
{"path":"success"}
```

On a successful run, the buyer is charged the displayed price and the creator earns 80% of their margin.

## Setting your margin

In the publish flow, set the per-run workflow margin from $0.05 to $50.00. Prompt products use their own legacy listing rules.

## Input envelope and compute

Set the maximum input spec (size, pages, tokens) for the version. Compute is priced at this maximum so the buyer price is honest for the largest allowed input.

The publish UI shows an estimated compute figure at envelope max ("~$X/run compute at max input"). This feeds the buyer displayed price. It is not a per-token invoice.

## What buyers and creators see

The live preview shows:

- **Buyers pay:** displayed price (margin + compute)
- **You earn:** 80% of margin, rounded down to the nearest microdollar ($0.000001)

Example: $10 margin and $0.50 compute yields a $10.50 buyer price and $8.00 creator earn per successful run.

## Version pricing

Each published version stores its own margin, compute estimate, and displayed price. Price changes on new versions do not retroactively change what existing buyers pay on older versions.

## Failover setting

Creators on Plus may disable model failover on the workflow. When off, a degraded primary model causes the run to fail instead of routing to a more expensive fallback. The buyer is not charged for that failure.

## Special cases

- **Non-hosted listing:** Hosted compute is replaced by the $0.002 Edgaze orchestration price. The provider bills the owner of the connected key. See [BYOK](/docs/billing/byok).
- **Remix workflow:** The preview includes the price of the one permitted sealed parent workflow.
- **Legacy unlock:** Supported older web listings use their purchase-time terms. See [Legacy](/docs/legacy).

## What you see in Edgaze

- Publish modal: margin input, envelope fields, compute estimate, buyer price, creator earn preview
- Product page: single displayed per-run price and envelope copy ("handles up to X")
- Version history: each version keeps its own price. Buyers with a bundle for an older version keep running that version and see per-version prices in the version selector

## Related policies

- [What You Pay For](/docs/billing/what-you-pay-for)
- [Creator Earnings Guide](/docs/billing/creator-earnings-guide)
- [Version Pinning](/docs/billing/version-pinning)
- [Failover](/docs/billing/failover)
- [Pricing Limits](/docs/pricing-limits)


---

---
title: Creator Earnings Guide
description: How creator earnings from paid runs accrue, clear from pending to available, and pay out to your connected Stripe account, step by step.
source: https://www.edgaze.ai/docs/billing/creator-earnings-guide
section: billing
---
# Creator Earnings Guide

> How creator earnings from paid runs accrue, clear from pending to available, and pay out to your connected Stripe account, step by step.

## Overview

**Audience: Creators earning from paid workflow runs.**

Creators receive 80% of their margin on each successful run, rounded down to the nearest microdollar ($0.000001). Hosted compute does not contribute to creator earnings. Failed runs produce no earnings.

Earnings move through three stages: pending, available, and paid.

## When you earn

On each successful buyer run, your share of the margin is credited immediately to your pending balance. This applies whether the buyer funded from wallet or bundle.

Creators do not earn on unused bundle runs that expire after 2 years.

## Pending balance

New earnings land in pending and are not yet available for payout. A reversal applies only to the matching earning while it remains in the 7-day pending window. It never reduces cleared or paid earnings, affects unrelated sales, or creates a negative balance.

## Clearing to available

After 7 calendar days, cleared earnings move from pending to available for an automatic payout.

## Payouts

Automatic weekly payout runs when your available balance reaches at least $25. Smaller balances remain available until the floor is met. Completed transfers appear in payout history with Stripe identifiers.

See [Payout System](/docs/payout-system) for Connect onboarding and transfer details.

**Finish payout setup.** If you hold at least $25 in earnings and have not finished payout setup 90 days after your first held earning, your paid listings are paused and new paid runs are refused. Finishing payout setup reopens your listings.

## Special cases

- **Failed or cancelled run:** No earnings for that run.
- **Stopped at the compute limit:** No margin earnings. Already-consumed compute may still be retained.
- **Composed child run:** Each child workflow creator earns on their own margin independently.
- **Demo or builder test runs:** No earnings.

## What you see in Edgaze

- Creator dashboard: pending, available, and paid totals
- Payout settings: Connect onboarding status and payout history
- Publish preview: "you earn" at 80% of margin per run

## Related policies

- [Publish and Price](/docs/billing/publish-and-price)
- [Payout System](/docs/payout-system)
- [Creator Earnings](/docs/creator-earnings)
- [Marketplace Fees](/docs/marketplace-fees)
- [Refund Policy](/docs/refund-policy)
- [Sell to Humans and Agents](/docs/sell-everywhere)

## Start building

Open [Workflow Studio](/builder), publish a priced workflow, and earn 80% of margin on every successful paid run.


---

---
title: BYOK (Bring Your Own Key)
description: Run on your own API keys with Edgaze Plus: which steps use your keys, what you pay Edgaze, and what your provider bills.
source: https://www.edgaze.ai/docs/billing/byok
section: billing
---
# BYOK (Bring Your Own Key)

> Run on your own API keys with Edgaze Plus: which steps use your keys, what you pay Edgaze, and what your provider bills.

## Overview

**Audience: Buyers using their own provider keys and creators choosing a listing credential mode.**

With Edgaze Plus and a key saved in [API Vault](/docs/builder/api-vault), you can run model steps on your own OpenAI, Anthropic or Google key. Your provider bills those steps to your key, and Edgaze takes their model cost off the run price. The creator's margin and the rest of the run's compute still apply.

## The "Use my API keys" switch

On an Edgaze-hosted listing, the run panel shows a **Use my API keys** row when you have active Plus and a saved key for a provider the workflow uses. Turn it on and the row shows the new price and how the run splits, for example "$0.08 → $0.03 · 3 steps on your keys · 1 on Edgaze (DeepSeek V4 Pro)".

- A step runs on your key only when its provider (OpenAI, Anthropic or Google) has a key in your Vault.
- Every other step stays on Edgaze's keys and stays in the price. That includes models Edgaze serves itself (Kimi-K2.6, DeepSeek-V4-Pro), which have no key you can bring, and providers you have no key for.
- Edgaze remembers your choice for your account. REST API and MCP runs follow the same remembered choice, since they have no switch.
- Without Plus, or without a key for any provider the workflow uses, the row is a quiet link to add keys or upgrade instead.

Keys only ever come from API Vault. No run panel asks you to paste a key, and steps have no per-step key setting.

## What you pay

The price is worked out per step from the same plan the run executes:

- Steps on your key cost Edgaze infrastructure only.
- Steps on Edgaze's keys keep their full model cost.
- The compute part of the price is the larger of $0.002 and those costs with Edgaze's usual compute markup, rounded to a stable amount.

You pay the creator's margin plus that compute price, exactly the BYOK price you were shown. The creator earns 80% of margin, the same as on a hosted run.

## Listing credential modes

Each listing declares one credential mode:

- **Edgaze-hosted:** Edgaze's keys by default, and the switch above for Plus members.
- **Buyer brings keys (buyer-BYOK):** the switch is locked on. You need active Plus and a Vault key for every provider the listing lists. A missing key stops the run before anything is reserved; it never falls back to Edgaze's keys.
- **Creator-connected:** the creator's Vault keys run the listing and the creator pays the provider. There is no switch for buyers.

## If a key is refused

If your provider rejects your key (invalid, revoked or out of credit), that step fails with a clear message such as "Your OpenAI key was rejected". It never switches silently to Edgaze's key. Failover from a step on your key only tries other models from the same provider, on the same key.

Failure releases the margin charge. Compute follows the standard [failure policy](/docs/billing/when-runs-fail).

## Special cases

- **Multiple providers:** Mixed workflows are fine. Only the steps whose provider has your key move to it.
- **Plus lapses:** Your saved keys are no longer used; runs go back to Edgaze's keys and the hosted price.
- **Bundle funding:** A bundle run is a prepaid run on Edgaze's keys. A run with any step on your own keys (the switch, or a buyer-BYOK listing) pays the own-keys price from your wallet and never uses a bundle run, so your bundle runs are kept.

## Related policies

- [What You Pay For](/docs/billing/what-you-pay-for)
- [When Runs Fail](/docs/billing/when-runs-fail)
- [API Vault](/docs/builder/api-vault)
- [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation)


---

---
title: When Runs Fail
description: What you pay when a run fails, is cancelled, or is stopped for exceeding its compute limit.
source: https://www.edgaze.ai/docs/billing/when-runs-fail
section: billing
---
# When Runs Fail

> What you pay when a run fails, is cancelled, or is stopped for exceeding its compute limit.

**Audience: Buyers and creators using Edgaze.**

## Overview

Ordinary failed and cancelled runs are not charged, and bundle runs are not consumed.

There is one separately labeled outcome: a run **stopped at the compute limit**, where already-consumed compute may be retained.

```docrunstate
{"cases":["failure","killed"]}
```

## Failed runs

When a workflow fails during execution, you are not charged for an ordinary failed run. The creator earns nothing. If you were using a bundle, that run is not consumed.

## Cancelled runs

**Before start.** If you cancel before the run fully starts, there is no charge and no bundle consumption.

**Mid-run.** Cancelling during execution follows the same billing as failure. There is no ordinary run charge, and a bundle run is not consumed.

## Waiting in line

When Edgaze is at capacity, a run may wait in line before it starts. Your funding stays reserved while it waits. If you cancel a waiting run, or it cannot start within its wait limit, it ends with "We couldn't start this run". You are not charged, the reservation is released, and a bundle run is not consumed.

## Completed with issues

Creators can let some steps fail without stopping the run. If such a step fails and the run still finishes, it is shown as **Completed with issues**: you get the outputs that were produced, and the steps that didn't finish are listed.

You pay only for the compute of the steps that finished, at the usual compute rate, and never more than the compute shown before the run. You don't pay the creator's price, and the creator earns nothing for that run. A bundle run is not consumed. A free demo that completes with issues does not use up your demo.

## Stopped at the compute limit

When a run exceeds its compute limit, it is stopped. Charges for work already completed may remain on your wallet, as shown before the run and in wallet history.

This is shown separately from an ordinary failed run so you can identify the charge in wallet history.

## Blocked before start

**Oversized input.** Input above the workflow envelope is rejected before any charge or reservation. Same outcome as insufficient funds: no run, no charge.

**Insufficient funds.** If no bundle run is available and your wallet cannot cover the run's reservation (a little more than the displayed price, to cover compute variance), the run never starts.

**Paused creator listings.** If a creator has held earnings of at least $25 and has not finished payout setup within 90 days, their paid listings are paused. A paid run on a paused listing is refused before any charge or reservation.

**Failover disabled.** If the creator turned off model failover (a Plus setting) and the primary model fails, the run fails with no charge. See [Failover](/docs/billing/failover).

## Special cases

- **Demo or builder test:** No charges regardless of outcome.
- **API path:** Same rules as the product UI.
- **Nested remix child failure:** Child margin is not charged. Root billing follows the same composed-run rules.

## What you see in Edgaze

- Failure: error reason and no ordinary run charge
- Completed with issues: the outputs, the steps that didn't finish, and a compute-only charge
- Cancel: cancelled state with before-start or mid-run copy
- Waiting in line: your place in line; if the run never starts, a "We couldn't start this run" message saying you weren't charged
- Compute limit: explicit stop message and any applicable charge in wallet history
- Run history: final status and reason

## Related policies

- [Run a Workflow](/docs/billing/run-a-workflow)
- [Run Outcomes Reference](/docs/billing/run-outcomes-reference)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [Refunds](/docs/billing/refunds)


---

---
title: Refunds
description: How to ask Edgaze support to review a refund, what support checks, and what you get back for a wallet top-up, purchase, or run.
source: https://www.edgaze.ai/docs/billing/refunds
section: billing
---
# Refunds

> How to ask Edgaze support to review a refund, what support checks, and what you get back for a wallet top-up, purchase, or run.

**Audience: Buyers and creators using Edgaze.**

## Overview

Refund requests are reviewed case by case. Email `support@edgaze.ai` from the email address associated with your Edgaze account and include the relevant transaction or run details. Submitting a request does not guarantee approval.

## Wallet top-up refunds

If you want Edgaze to review a wallet top-up, email `support@edgaze.ai` with the top-up date, amount, and reason for the request. There is no customer refund API or automatic approval process.

Support reviews the original payment, wallet usage, account history, and the circumstances you describe. If a refund is approved, support will confirm the amount and method.

## Marketplace purchase refunds

Marketplace and bundle purchases follow the same case-by-case support review. If a refund is approved, associated product access may be revoked.

## Successful runs

There is no self-service refund for a completed run. Requests involving completed runs are evaluated case by case through support.

If support approves a refund of a run, you get back what the run took: the wallet charge, or the bundle run if it was paid with a bundle. A run that used remixed workflows is refunded in full, and a run started with an API key stops counting against that key's spend limit.

## Chargebacks

Card network chargebacks follow the [Chargeback Policy](/docs/chargeback-policy).

## Special cases

- **Partial wallet use:** Support considers prior wallet usage when reviewing the request.
- **Unused bundle runs:** There is no automatic bundle refund. See [Bundles Expiry and Refunds](/docs/billing/bundles-expiry-refunds).

## What you see in Edgaze

- A response from support after review
- Support contact at `support@edgaze.ai`
- Access revoked message when a marketplace purchase is refunded

## Related policies

- [Refund Policy](/docs/refund-policy)
- [Chargeback Policy](/docs/chargeback-policy)
- [Funding Runs](/docs/billing/funding-runs)
- [When Runs Fail](/docs/billing/when-runs-fail)


---

---
title: API Runs
description: Billing for workflow runs triggered through the REST API, including spend caps.
source: https://www.edgaze.ai/docs/billing/api-runs
section: billing
---
# API Runs

> Billing for workflow runs triggered through the REST API, including spend caps.

**Audience: Developers running workflows through the API.**

## Overview

API-triggered runs use the same billing as runs started from the product UI. Funding is wallet-based, with bundle draw first if the API caller has an eligible bundle for that workflow version.

API keys can set an optional spend cap. Before a run starts, its creator margin plus its estimated compute hold is reserved against the cap. If that would take the key past its cap, the endpoint returns `spend_cap_reached` and does not start a run.

## Authentication and spend caps

Requests require a valid API key with run scope. The reservation against a key's spend cap covers the creator margin plus the estimated compute hold, so a run whose price would take the key past its cap does not start. When the run finishes, the cap counts what the run was actually charged and the rest of the reservation is released. A run that is not charged releases its whole reservation.

The public endpoint has no separate account-level spend cap. Keys without an API-key cap are limited by wallet balance, bundle availability, input limits, and rate limits.

## Funding and execution

Funding order matches the UI: eligible locked bundle first, then wallet. Insufficient wallet after bundle exhaustion blocks the run.

The API enforces the same input envelope limits as the product UI. Oversized input is rejected before any charge.

On success, billing is identical to UI runs: the wallet is charged or one eligible bundle run is consumed. Ordinary failed and cancelled runs are not charged. If a run is separately labeled as stopped at the compute limit, already-consumed compute may be retained.

## Response behavior

`POST /runs` may return `202 Accepted` before funding checks finish. An insufficient wallet can therefore appear later as a failed run rather than as an immediate payment error. An API-key spend-cap failure is returned immediately.

See [Create Run](/docs/api/create-run#funding-and-acceptance-behavior) for response, charge, and retry outcomes.

## Special cases

- **Bundle via API:** Works the same as the product UI when the bundle matches the workflow version.
- **BYOK via API:** The same displayed pricing terms apply as for UI BYOK runs.
- **Composed workflow:** The displayed price covers the complete run.

## What you see in Edgaze

- API Vault: key creation with optional spend cap and window
- API responses: clear messages when funds or spend cap block a run
- Wallet history: the same charge lines as UI runs for the same account

## Related policies

- [API Reference](/docs/api): REST endpoints, authentication, playground, and webhooks
- [Funding Runs](/docs/billing/funding-runs)
- [Run a Workflow](/docs/billing/run-a-workflow)
- [API Vault](/docs/builder/api-vault): BYOK provider keys (not REST API keys)
- [When Runs Fail](/docs/billing/when-runs-fail)


---

---
title: Failover
description: When Edgaze switches to a backup model, your price stays the same.
source: https://www.edgaze.ai/docs/billing/failover
section: billing
---
# Failover

> When Edgaze switches to a backup model, your price stays the same.

## Overview

**Audience: Buyers running workflows and creators configuring failover.**

When a primary model degrades, Edgaze may continue the run with an eligible alternative. Your displayed price does not increase because of failover.

Creators on Plus can disable failover. When it is off, a provider problem may cause the run to fail instead of continuing with an alternative. Ordinary failed runs are not charged.

## Failover enabled

If a provider problem is detected, the run may continue with an eligible alternative. Your displayed price does not change.

On success after failover, you pay the same displayed price as a run that did not fail over.

## Failover disabled

If the creator opted out in publish settings (a Plus feature), a provider problem may cause the run to fail. The standard failure policy applies.

## Special cases

- **Failover then failure:** The standard failure policy applies.
- **BYOK graphs:** Your provider may bill your account separately. The displayed Edgaze pricing terms still apply.
- **API and bundle paths:** Same failover billing rules as UI wallet runs.

## What you see in Edgaze

- Publish settings: failover toggle for creators (turning failover off requires Plus)
- Buyer UI: no visible price change when failover occurs
- Failure with failover off: standard failure message

## Related policies

- [Publish and Price](/docs/billing/publish-and-price)
- [When Runs Fail](/docs/billing/when-runs-fail)
- [What You Pay For](/docs/billing/what-you-pay-for)
- [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation)


---

---
title: Version Pinning
description: How prices lock to a workflow version and what happens when creators publish new versions.
source: https://www.edgaze.ai/docs/billing/version-pinning
section: billing
---
# Version Pinning

> How prices lock to a workflow version and what happens when creators publish new versions.

**Audience: Developers running workflows through the API.**

## Overview

Each workflow version has its own margin, hosted compute estimate, and displayed price. When a creator publishes a new version, the older versions keep their prices.

A bundle runs the version it was bought for. It keeps working after the creator publishes a new version: your runs stay on the version you bought until the bundle is used up or expires.

Some legacy purchases are pinned to a workflow version. Without a bundle or a pin, runs follow the current active version.

## Bundles after a new version

When you start a run without choosing a version and you hold a bundle with runs left, Edgaze runs the version that bundle was bought for and uses one of its runs. Its recorded terms apply; no wallet charge is made.

If you hold bundles for more than one version, the bundle that expires soonest is used first.

To run the newer version instead, pick it in the version selector. That run is paid from your wallet at the newer version's displayed price, or from a bundle bought for that version.

When the bundle is used up or expires, runs go back to the current active version and are funded normally.

A bundle only covers its own version. It never gives access to other versions.

## How pinning works

When a creator publishes, that version keeps its own displayed price.

A bundle applies to the version shown at purchase. Supported legacy access may also remain tied to its purchase version. Ordinary wallet-funded runs use the version selected for that run.

When you trigger a run, the price comes from the version that runs. A wallet charge uses that version's displayed price; a bundle run uses the bundle's recorded terms.

## Choosing a version

When you can run more than one version (a bundle for an older version, a pinned purchase, or your own workflow), the run screen shows a version selector. Each version shows its own displayed price when prices differ.

The bundle's version is selected by default and marked "your bundle". A line under the selector says which version your bundle runs and how many runs are left. If you pick a version your bundle does not cover, the line says that run is paid from your wallet.

## API version resolution

POST /runs pins every API-triggered run to one immutable workflow version. Two API callers can hit the same `workflow` id and end up on different graphs, in this order:

1. Explicit `version` in the request body. The run executes that exact immutable graph. Owners can select any version. Buyers can select the version their purchase pin covers (or the current version when not pinned) and any version they hold a bundle with runs left for. An unknown or forbidden `version` returns 403 forbidden.
2. Bundle. When `version` is omitted and the caller holds a bundle with runs left, the run executes that bundle's version, soonest-expiring bundle first, and draws from it.
3. Pinned access. When `version` is omitted and the caller's access is pinned, the run executes that version. A newer active version does not silently upgrade the caller.
4. Current version. Otherwise the run executes the current active version.

MCP runs resolve the version the same way, without the explicit `version` option.

GET /workflows/{id} surfaces `pinnedVersionId`, `activeVersionId`, and `updateAvailable` so API integrators can detect drift without polling every run. `updateAvailable` is true when a run without `version` would not execute the active version, including while a bundle for an older version has runs left. Buyers who want to re-pin a purchase to the newest version can call POST /workflows/{id}/accept-update (requires `workflow:write`). Accepting an update does not move a bundle to the new version.

## When creators change prices

If a creator changes the price on a new version, existing bundles and supported legacy purchases keep their recorded version terms.

Wallet-funded buyers can choose the newer available version and pay its displayed price.

## Unpublished versions

An older version may remain available to customers whose bundle or purchase covers it. If it is unavailable, the UI shows an error and no run charge starts.

## Special cases

- **Remix:** A remixed workflow uses the version selected when the remix is published.
- **Takedown:** Access to an older version remains subject to product availability and platform policy.

## What you see in Edgaze

- Version selector with per-version displayed prices
- "Your bundle runs Version N, the version you bought" with the runs left
- A note when the selected version is paid from your wallet instead of your bundle
- Error if an unpublished version's graph is missing

## Related policies

- [Publish and Price](/docs/billing/publish-and-price)
- [Funding Runs](/docs/billing/funding-runs)
- [Remix and Nested Workflows](/docs/billing/remix-and-nested-workflows)
- [Legacy Unlock](/docs/billing/legacy-unlock)


---

---
title: Remix Workflows
description: How a workflow can use one published parent workflow, how pricing works, and how each creator earns.
source: https://www.edgaze.ai/docs/billing/remix-and-nested-workflows
section: billing
---
# Remix Workflows

> How a workflow can use one published parent workflow, how pricing works, and how each creator earns.

## Overview

**Audience: Buyers and creators using remixed workflows.**

One workflow can be remixed into another at a single level. The buyer sees the complete price before running. Each creator earns 80% of the margin belonging to their workflow when the run succeeds.

A remix cannot itself be remixed. The builder rejects multiple parent workflows, remix-of-remix composition, unavailable parents, disallowed remixing, trivial copies, and cycles before publication.

## How composed pricing works

When you add a Remixed Workflow block, it references one published workflow version. Its price is included in the complete preview for the new workflow.

The product page and publish preview show the complete per-run total. There are no additional remix charges after the run starts.

## At run time

On success, you are charged the displayed price. The parent workflow creator earns 80% of the parent margin, and the remix creator earns 80% of the new workflow's margin.

The remix creator does not receive a share of the parent's margin.

## Special cases

- **Parent price changes:** The published remix keeps the parent version and price included at publish.
- **Parent failure:** The full run fails and ordinary failure settlement applies.
- **Bundle:** A matching bundle applies to the published remix version and its complete displayed price.

## What you see in Edgaze

- Builder: Remixed Workflow block with the parent workflow and included price
- Product page: full composed total before run
- Publish error when the parent is already a remix

## Related policies

- [What You Pay For](/docs/billing/what-you-pay-for)
- [Version Pinning](/docs/billing/version-pinning)
- [Publish and Price](/docs/billing/publish-and-price)
- [When Runs Fail](/docs/billing/when-runs-fail)


---

---
title: Bundles Expiry and Refunds
description: When prepaid bundles expire, what happens to unused runs, and refund options.
source: https://www.edgaze.ai/docs/billing/bundles-expiry-refunds
section: billing
---
# Bundles Expiry and Refunds

> When prepaid bundles expire, what happens to unused runs, and refund options.

**Audience: Buyers and creators using Edgaze.**

## Overview

Prepaid bundles expire 2 years after purchase. After expiry, they cannot be used. Further runs use an eligible newer bundle or wallet funding.

## While your bundle is valid

Bundle runs draw first on every trigger, except a run on your own API keys, which pays the own-keys price from your wallet and keeps your bundle runs (see [Use my API keys](/docs/billing/byok)). Failed runs do not consume a bundle run. The runs remaining counter updates only on successful runs.

## After expiry

Once a bundle expires, it is excluded from funding. The UI shows expired bundle messaging. You need wallet balance to run that workflow version.

Partially used bundles at expiry: only unused runs are affected. Runs you already consumed are not reversed.

## Creator earnings

Unused runs do not become creator earnings. Creators earn only when a buyer successfully runs the workflow and the margin settles.

## Refunds

Bundle refunds are not automatic. Email `support@edgaze.ai` to request a case-by-case review. See [Refunds](/docs/billing/refunds).

## Special cases

- **New version published:** A valid bundle keeps running the version it was bought for, even after the creator publishes a newer one. See [Version Pinning](/docs/billing/version-pinning).
- **Version lock after expiry:** An expired bundle never draws, even if you select the matching version. Runs then use the current version, and wallet is required.

## What you see in Edgaze

- Bundle purchase confirmation with expiry date where shown
- Runs remaining counter until expiry or depletion
- Expired bundle message when draw is attempted after expiry
- Wallet page history includes bundle purchase and consumption

## Related policies

- [Funding Runs](/docs/billing/funding-runs)
- [Refunds](/docs/billing/refunds)
- [Version Pinning](/docs/billing/version-pinning)
- [Creator Earnings Guide](/docs/billing/creator-earnings-guide)


---

---
title: Run Outcomes Reference
description: Quick reference for customer charges and creator earnings across common run scenarios.
source: https://www.edgaze.ai/docs/billing/run-outcomes-reference
section: billing
---
# Run Outcomes Reference

> Quick reference for customer charges and creator earnings across common run scenarios.

**Audience: Buyers and creators using Edgaze.**

## Overview

This table summarizes customer-visible billing outcomes for hosted runs, API runs, bundles, BYOK, failover, and payouts.

For narrative detail, follow the doc link in each row.

## Reference table

| Scenario                            | You pay                                      | Creator earns                  | What you see                        | Learn more                                                             |
| ----------------------------------- | -------------------------------------------- | ------------------------------ | ----------------------------------- | ---------------------------------------------------------------------- |
| Hosted run success (wallet)         | Full displayed price                         | Under the creator fee schedule | Run completes; wallet balance drops | [Run a Workflow](/docs/billing/run-a-workflow)                         |
| Hosted run success (bundle)         | One prepaid run consumed                     | Under the creator fee schedule | Runs remaining count updates        | [Funding Runs](/docs/billing/funding-runs)                             |
| Hosted run failure                  | No ordinary run charge                       | No                             | Failure reason; no ordinary charge  | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Cancel before start                 | No                                           | No                             | Cancelled before start              | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Cancel mid-run                      | No ordinary run charge                       | No                             | Run cancelled                       | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Waiting in line                     | Funding reserved, not yet charged            | No                             | Place in line                       | [Run a Workflow](/docs/billing/run-a-workflow)                         |
| Cancelled or expired while waiting  | No; reservation released                     | No                             | We couldn't start this run          | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Completed with issues               | Compute for the finished steps only          | No                             | Completed with issues; failed steps | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Insufficient wallet                 | No                                           | No                             | Insufficient funds message          | [Funding Runs](/docs/billing/funding-runs)                             |
| Creator listings paused             | No                                           | No                             | Paid listing paused message         | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Bundle available                    | Bundle used first                            | On success only                | Bundle draw indicator               | [Funding Runs](/docs/billing/funding-runs)                             |
| Bundle depleted                     | Wallet or no run                             | On success only                | Prompt to top up wallet             | [Funding Runs](/docs/billing/funding-runs)                             |
| Wallet after bundle                 | Wallet on success                            | On success only                | Same as wallet success              | [Funding Runs](/docs/billing/funding-runs)                             |
| API wallet run                      | Same as wallet success                       | On success only                | API run status and charge           | [API Runs](/docs/billing/api-runs)                                     |
| API spend cap reached               | No                                           | No                             | Spend cap error                     | [API Runs](/docs/billing/api-runs)                                     |
| BYOK run success                    | Displayed Edgaze price; provider bills you   | Under the creator fee schedule | BYOK pricing note                   | [BYOK](/docs/billing/byok)                                             |
| BYOK failure                        | Per the displayed BYOK terms                 | No                             | BYOK note plus error                | [BYOK](/docs/billing/byok)                                             |
| Failover enabled, success           | Displayed price                              | On success                     | No visible price change             | [Failover](/docs/billing/failover)                                     |
| Failover disabled (Plus), failure   | No ordinary run charge                       | No                             | Standard failure message            | [Failover](/docs/billing/failover)                                     |
| Creator changes price (new version) | Price of the version that runs               | On successful runs             | Per-version prices in selector      | [Version Pinning](/docs/billing/version-pinning)                       |
| Bundle bought for an older version  | One bundle run at the bought version's terms | On success only                | "Your bundle runs Version N" line   | [Version Pinning](/docs/billing/version-pinning)                       |
| Buyer owns pinned version           | Pinned price per run                         | On successful runs             | Version dropdown                    | [Version Pinning](/docs/billing/version-pinning)                       |
| Version unavailable                 | No run charge                                | No                             | Availability error                  | [Version Pinning](/docs/billing/version-pinning)                       |
| Nested or remixed workflow          | Displayed combined price                     | Each creator earns separately  | One price before the run            | [Remix and Nested Workflows](/docs/billing/remix-and-nested-workflows) |
| Refund request                      | Decided after case-by-case review            | May be adjusted                | Response from support               | [Refunds](/docs/billing/refunds)                                       |
| Bundle expiry (2 years)             | Expired runs cannot be used                  | No                             | Expired bundle message              | [Bundles Expiry and Refunds](/docs/billing/bundles-expiry-refunds)     |
| Creator payout pending              | None                                         | Earnings waiting in pending    | Pending on dashboard                | [Creator Earnings Guide](/docs/billing/creator-earnings-guide)         |
| Creator payout available            | N/A                                          | Cleared after 7 days           | Available balance                   | [Creator Earnings Guide](/docs/billing/creator-earnings-guide)         |
| Creator payout paid                 | N/A                                          | Transferred via Stripe Connect | Payout history                      | [Payout System](/docs/payout-system)                                   |
| Demo or builder test                | No                                           | No                             | Demo or preview label               | [Run a Workflow](/docs/billing/run-a-workflow)                         |
| Stopped at the compute limit        | Consumed compute may be retained             | No                             | Compute-limit stop message          | [When Runs Fail](/docs/billing/when-runs-fail)                         |
| Legacy unlock listing               | Legacy unlock purchase                       | Under purchase-time terms      | Unlock versus per-run copy          | [Legacy Unlock](/docs/billing/legacy-unlock)                           |

## Notable exceptions

- **Stopped at the compute limit:** Already-consumed compute may be retained. Margin is released. This is separate from an ordinary failure.
- **Completed with issues:** A step the creator allowed to fail failed, but the run finished with outputs. You pay the compute of the finished steps only (never more than the compute shown), no creator price; a bundle run is not consumed.
- **Waiting in line:** Funding is reserved while the run waits. A run that is cancelled or never starts is not charged.
- **Demo and builder test:** Never billed.
- **Bundle expiry:** Unused prepaid runs expire after two years. Creators do not earn on runs that were never used.

## Related policies

- [When Runs Fail](/docs/billing/when-runs-fail)
- [Funding Runs](/docs/billing/funding-runs)
- [Run a Workflow](/docs/billing/run-a-workflow)
- [Workflow Run Policy](/docs/workflow-run-policy)


---

---
title: Legacy Unlock
description: One-time purchase listings from before per-run pricing existed.
source: https://www.edgaze.ai/docs/billing/legacy-unlock
section: billing
---
# Legacy Unlock

> One-time purchase listings from before per-run pricing existed.

**Audience: Buyers and creators using Edgaze.**

## Overview

Some older listings sold a one-time unlock before per-run pricing existed. Buyers paid once for access. These listings do not use per-run pricing.

New listings use a displayed per-run price and are not classified as legacy unlock.

This page is the only billing doc that describes the one-time unlock model.

## How legacy unlock works

Legacy products show a one-time purchase price instead of a per-run quote. You complete Stripe checkout once. Edgaze grants platform access recorded in your purchase history.

After unlock, you may run within the access rules for that legacy product. There is no per-run Edgaze charge on the legacy model.

## Creator payment

Creator share on a legacy purchase follows the split recorded at checkout time through Stripe Connect. It is not the 80% of margin per-run model used by new listings.

## Moving to per-run pricing

Creators who move to per-run pricing create listings separate from legacy unlock purchases. Existing unlock purchasers retain their purchase terms unless Edgaze communicates a change.

## Refunds

Marketplace purchase refunds for unlock checkout are handled through support review. An approved refund revokes access. See [Refunds](/docs/billing/refunds).

## Special cases

- **Per-run listing:** Uses the displayed per-run price rather than legacy unlock terms.
- **Free listings:** Zero price with no margin is not unlock. Treated as free access.
- **API on legacy product:** Legacy unlock workflows cannot be run through the REST API; they run only in the web app. The API lists and runs only free and per-run workflows.

## What you see in Edgaze

- Product page: unlock versus per-run copy distinction
- Buy access: one-time checkout button for legacy listings
- No per-run price badge on legacy unlock products
- Per-run listings show one displayed run price instead

## Related policies

- [Run a Workflow](/docs/billing/run-a-workflow)
- [Payments Overview](/docs/payments-overview)
- [Refunds](/docs/billing/refunds)
- [Marketplace Fees](/docs/marketplace-fees)


---

---
title: Edgaze MCP
description: Let your agent call a marketplace workflow directly as a tool.
source: https://www.edgaze.ai/docs/mcp
section: mcp
---
# Edgaze MCP

> Let your agent call a marketplace workflow directly as a tool.

**Audience: Anyone who wants their AI app to run Edgaze workflows.**

**Outcome: Paste one prompt, or write the config yourself, then sign in and run.**

Edgaze MCP is how an AI app talks to the Edgaze marketplace. After you connect, the agent can search published workflows, read the input form and the price, start a run, and bring the result back into the chat.

It runs the same published product a human runs on the marketplace. There is no second graph and no rebuild.

## Works with

These clients can connect to Edgaze MCP. Open one for the exact setup. Other clients use the same remote server.

```mcpclients

```

## For your agent

The box at the top of this page is the prompt to paste. It tells the agent to fetch [Connect Edgaze MCP](/docs/mcp/connect) at `https://www.edgaze.ai/docs/mcp/connect.md` and write the config for this client. That page is the playbook. Humans can follow the same steps by hand.

## What to use, exactly

| Use this                              | Do not substitute                                    |
| ------------------------------------- | ---------------------------------------------------- |
| Server `https://mcp.edgaze.ai`        | `www.edgaze.ai`, `api.edgaze.ai`, or a localhost URL |
| Consent host `https://www.edgaze.ai`  | Opening `/oauth/consent` yourself, or the apex host  |
| Wallet `https://www.edgaze.ai/wallet` | A different billing page                             |

A www mismatch on consent looks like a broken login. The client starts OAuth. Do not open `/oauth/consent` yourself. The agent must not invent a different server URL.

## What you approve

The app opens the Edgaze consent page. Sign in with your Edgaze account and allow:

- **Find workflows**: see published names, prices, and input forms
- **Run workflows**: start paid runs from your wallet and watch the output come back in chat. Free demo runs need this permission too

That is the whole grant. You can disconnect later from Settings → Connected apps.

## What the agent can do

Five tools, in this order:

1. `edgaze_catalog`: browse published categories when the goal is still vague
2. `edgaze_search`: find workflows for a job. If nothing matches, it stops
3. `edgaze_inspect`: read one slug: inputs, example values, price, whether a demo is available
4. `edgaze_run`: start the run. `demo: true` only when inspect said a demo is available
5. `edgaze_watch`: read output until the run finishes

The agent should inspect before it runs, show you the price, and use your words for the inputs. It should not invent values the form rejects. Text and external actions come back in the chat. Images, files, and other media come back as a link to the hosted run page on Edgaze.

## After you connect

A zero wallet is normal the first time. That is not a failed install. Open [Wallet](/wallet), add money when you want a paid run, and ask the agent to try again. See [Wallet](/docs/mcp/wallet) and [Your first run](/docs/mcp/first-run).

If you publish workflows, agents run the same version marketplace buyers run. See [For creators](/docs/mcp/for-creators).

## Next

- [Connect Edgaze MCP](/docs/mcp/connect): client setup and the agent playbook
- [Your first run](/docs/mcp/first-run)
- [Wallet](/docs/mcp/wallet)
- [For creators](/docs/mcp/for-creators)


---

---
title: Connect Edgaze MCP
description: Manual setup and agent installation for Cursor, Claude, ChatGPT, Codex, VS Code, Devin Desktop, OpenCode, and other MCP clients.
source: https://www.edgaze.ai/docs/mcp/connect
section: mcp
---
# Connect Edgaze MCP

> Manual setup and agent installation for Cursor, Claude, ChatGPT, Codex, VS Code, Devin Desktop, OpenCode, and other MCP clients.

**Audience: An agent installing Edgaze MCP, or a person doing the same by hand.**

**Outcome: The client has a remote server at https://mcp.edgaze.ai, the human has approved access, and the five Edgaze tools are listed.**

Edgaze MCP is a remote HTTP server at [https://mcp.edgaze.ai](https://mcp.edgaze.ai). Do not add it as a local command, `npx` package, or stdio wrapper. After you connect, the client starts OAuth, you approve access, and the client should list five tools: `edgaze_catalog`, `edgaze_search`, `edgaze_inspect`, `edgaze_run`, and `edgaze_watch`.

| Use                 | Value                                                                                  |
| ------------------- | -------------------------------------------------------------------------------------- |
| Server              | [https://mcp.edgaze.ai](https://mcp.edgaze.ai)                                         |
| Consent host        | [https://www.edgaze.ai](https://www.edgaze.ai)                                         |
| Wallet              | [https://www.edgaze.ai/wallet](https://www.edgaze.ai/wallet)                           |
| Markdown for agents | [https://www.edgaze.ai/docs/mcp/connect.md](https://www.edgaze.ai/docs/mcp/connect.md) |

Do not open [https://www.edgaze.ai/oauth/consent](https://www.edgaze.ai/oauth/consent) yourself. A bare consent link has no sign-in request. The client starts OAuth after it reaches the server, then opens that page.

A zero wallet is normal after install. Do not start a paid workflow from this page. When you want a run, go to [Your first run](/docs/mcp/first-run).

## For agents

Identify the MCP client first. Cursor, Claude Code, Codex, VS Code, Devin Desktop, and OpenCode each use a different file and format. ChatGPT, Claude, and Claude Desktop have no config file for remote servers: they connect from their own settings. If this is another client, use Other clients. If you cannot tell which client this is, ask.

Then:

1. Follow the matching section below.
2. Add Edgaze in that client's format. Keep any servers already in the file.
3. Name the server `edgaze`.
4. Do not add an API key, bearer token, or `Authorization` header. Sign-in is the Edgaze browser OAuth flow the client starts.
5. Reload or restart the client if it requires that. Use that app's Connect or Sign in control. Do not open `/oauth/consent` in a normal browser tab.
6. When the client opens consent, approve **Find workflows** and **Run workflows**.
7. Confirm the five `edgaze_*` tools are listed.

## Cursor

Project file: `.cursor/mcp.json`. Personal file: `~/.cursor/mcp.json`. If both define `edgaze`, the project file wins.

```json
{
  "mcpServers": {
    "edgaze": {
      "url": "https://mcp.edgaze.ai"
    }
  }
}
```

A `url` is remote, so do not add a `command`. `type` is optional. Do not add `headers` or an `auth` block: Edgaze signs you in with OAuth.

Then open **Customize** in the Cursor sidebar and make sure Edgaze is turned on. Disabled servers do not load. When Cursor asks you to sign in to Edgaze, do. Do not open `/oauth/consent` in a browser tab.

## Claude Code

Claude Code treats a server that has a `url` and no `type` as a local command, and it fails. The fastest user-scope add is:

```bash
claude mcp add --transport http --scope user edgaze https://mcp.edgaze.ai
```

For a shared project file, add `.mcp.json` at the repository root:

```json
{
  "mcpServers": {
    "edgaze": {
      "type": "http",
      "url": "https://mcp.edgaze.ai"
    }
  }
}
```

`"type": "streamable-http"` is accepted as an alias for `"http"`. User-scope servers are stored in `~/.claude.json`.

Then sign in: run `/mcp` inside Claude Code and follow the browser steps, or run `claude mcp login edgaze` from your shell.

## Claude

This is claude.ai, Claude Desktop, Cowork, and the mobile apps. It is not Claude Code. Claude reaches Edgaze from Anthropic's servers, so localhost will not work. There is no config file to edit.

Open **Customize → Connectors**, click **+ Add**, then **Add custom connector**. Enter the name `Edgaze` and the URL [https://mcp.edgaze.ai](https://mcp.edgaze.ai), then continue. Keep the sign-in Claude detects. Do not add request headers or an API key.

Click **Add**. Claude opens consent on [www.edgaze.ai](https://www.edgaze.ai). Approve **Find workflows** and **Run workflows**. Free accounts can add one custom connector.

On Team and Enterprise, an Owner adds Edgaze first from **Organization settings → Connectors**, with the same URL. Members then open **Customize → Connectors**, find Edgaze under **Custom**, and click **Connect**.

Adding the connector does not enable it in every chat. In the conversation, open **+ → Connectors** and turn Edgaze on.

## Claude Desktop

Claude Desktop connects to Edgaze the same way as claude.ai: add it from **Customize → Connectors** as in the Claude section above.

Do not add Edgaze to `claude_desktop_config.json`. That file only starts local command servers on your machine; an entry with a `url` is ignored or stops Claude Desktop from loading its servers.

## ChatGPT

This is ChatGPT on the web. It is not Codex, and `~/.codex/config.toml` does not apply. There is no local config file to create. Workspace permissions apply: a managed workspace may need an admin to allow custom MCP servers.

Open [ChatGPT Plugins](https://chatgpt.com/plugins), select the plus button, and choose **Add custom MCP server**:

- **Name:** `Edgaze`
- **Description:** `Find and run Edgaze marketplace workflows.`
- **Server URL:** [https://mcp.edgaze.ai](https://mcp.edgaze.ai)

Do not append `/mcp` or use a tunnel. For authentication choose **OAuth**. Do not paste an API key. Review the warning, select **I understand and want to continue**, then **Create as a plugin**. Install the plugin from your personal plugins, and approve **Find workflows** and **Run workflows** when Edgaze asks.

To use it, type `@` in the message box and choose Edgaze. Confirmation before write-capable tools is expected.

## Codex

Codex uses TOML. Personal file: `~/.codex/config.toml`. Trusted project file: `.codex/config.toml`.

```toml
[mcp_servers.edgaze]
url = "https://mcp.edgaze.ai"
```

Do not set a bearer token or headers. Or run:

```bash
codex mcp add edgaze --url https://mcp.edgaze.ai
```

Then sign in:

```bash
codex mcp login edgaze
```

In the ChatGPT desktop app or the Codex IDE extension, you can select **Authenticate** in the server list instead. The desktop app, Codex CLI, and IDE extension share this file. ChatGPT on the web does not read it.

## VS Code

VS Code uses a top-level `servers` object, not `mcpServers`, and remote servers need `"type": "http"`. Workspace file: `.vscode/mcp.json`. Personal file: Command Palette → **MCP: Open User Configuration**.

```json
{
  "servers": {
    "edgaze": {
      "type": "http",
      "url": "https://mcp.edgaze.ai"
    }
  }
}
```

You can also run **MCP: Add Server**, choose **HTTP**, and enter [https://mcp.edgaze.ai](https://mcp.edgaze.ai). When VS Code asks, confirm that you trust the server so it can start, then sign in to Edgaze. In the chat, **Configure Tools** shows the Edgaze tools.

## Devin Desktop

Windsurf is now Devin Desktop. Its servers live in `mcp_config.json` in the Devin config folder:

- macOS and Linux: `~/.config/devin/mcp_config.json`
- Windows: `%APPDATA%\devin\mcp_config.json`

Open it from the Cascade panel: click the **…** menu at the top right, then **Open MCP config file** in the MCPs section. Add Edgaze under `mcpServers` and save:

```json
{
  "mcpServers": {
    "edgaze": {
      "serverUrl": "https://mcp.edgaze.ai"
    }
  }
}
```

`url` is accepted in place of `serverUrl`. Then turn Edgaze on with its toggle in the MCPs section, and sign in when it asks. Do not add headers or an API key.

## OpenCode

OpenCode uses `opencode.json` or `opencode.jsonc` at the repo root, or `~/.config/opencode/opencode.json` for a personal config. The project file wins if both define `edgaze`. It does not read `.cursor/mcp.json` or a top-level `mcpServers` object.

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "edgaze": {
      "type": "remote",
      "url": "https://mcp.edgaze.ai"
    }
  }
}
```

`"type": "remote"` is required. Do not add headers, an API key, or `"oauth": false`. OpenCode starts OAuth when `oauth` is left unset.

You can also add it from the CLI. Choose a remote server, name it `edgaze`, and enter [https://mcp.edgaze.ai](https://mcp.edgaze.ai):

```bash
opencode mcp add
```

Then authenticate:

```bash
opencode mcp auth edgaze
```

If the browser does not open, run that auth command again. Confirm the connection with:

```bash
opencode mcp list
```

If the server connects but the five tools do not appear, add `"timeout": 30000` to the `edgaze` object and try again.

## Other clients

Any MCP client that can add a remote streamable HTTP server can use Edgaze. Do not choose stdio or SSE: Edgaze serves streamable HTTP only, so a client that offers only SSE cannot connect. If a client can only launch a local command, it cannot connect.

Add a server named `edgaze`. Point it at [https://mcp.edgaze.ai](https://mcp.edgaze.ai). Do not add an API key, bearer token, `Authorization` header, or extra path.

If the client asks for a transport type, choose HTTP. Some files want `"type": "http"`. Some want `url`. Some want `serverUrl`. Use the field that client already uses for remote servers.

```json
{
  "url": "https://mcp.edgaze.ai"
}
```

Reload or restart if the client requires that. When the client starts OAuth, the browser should open consent on [https://www.edgaze.ai](https://www.edgaze.ai) with a sign-in request. Sign in and press **Authorize**. Opening `/oauth/consent` yourself will say the link is missing a request. A redirect to the Edgaze domain without `www` can look like a failed login even when the password is correct. You can create an account during this flow. You do not need to own or publish a workflow.

Approve **Find workflows** and **Run workflows**. The install is done when the five `edgaze_*` tools are listed. If tools are missing, check that Edgaze is enabled, the config was reloaded, and you are in the right client. Then ask the agent to find a workflow. See [Your first run](/docs/mcp/first-run). An empty wallet is not a failed install. Add funds from [Wallet](/wallet) when you want a paid run.

## Troubleshooting

```docfaq
**Consent says it is missing a sign-in request.** You opened the page by hand. Reload Edgaze in the client and use that app's Connect or Sign in control.

**Consent page looks wrong.** The host must be [https://www.edgaze.ai](https://www.edgaze.ai). The URL must include a request from the client. A bare `/oauth/consent` link is not a sign-in.

**Claude Code ignores the server.** The config needs `"type": "http"`. Without it, Claude Code treats the entry as a local command and it fails.

**VS Code ignores the server.** The top-level key must be `"servers"`, not `mcpServers`, and the server needs `"type": "http"`.

**Codex ignores the server.** Codex reads TOML under `[mcp_servers.edgaze]`, not JSON.

**Cursor opens the Edgaze marketing site.** The server URL must be exactly [https://mcp.edgaze.ai](https://mcp.edgaze.ai), with no extra path.

**Claude has no Edgaze tools.** The connector may be installed but off for this chat. Open **+ → Connectors** and enable it. `claude_desktop_config.json` does not configure remote connectors anywhere, including Claude Desktop.

**ChatGPT has no Edgaze tools.** Install the Edgaze plugin from your personal plugins, then type `@` in the chat and choose Edgaze. Codex `config.toml` does not apply here.

**OpenCode ignores the server.** It needs a top-level `mcp` object with `"type": "remote"`. Do not set `"oauth": false`.

**A run asks for money.** The MCP install worked. Add funds from [Wallet](/wallet) and run again.
```


---

---
title: Your first run
description: How the agent should search, inspect, demo, pay, and watch a workflow after Edgaze MCP is connected.
source: https://www.edgaze.ai/docs/mcp/first-run
section: mcp
---
# Your first run

> How the agent should search, inspect, demo, pay, and watch a workflow after Edgaze MCP is connected.

**Audience: People who just connected Edgaze MCP, and the agent running the session.**

**Outcome: Finish a first demo or paid run without guessing inputs, price, or what a demo is.**

## Before you run

Setup must already be done. If the five `edgaze_*` tools are missing, stop and follow [Connect Edgaze MCP](/docs/mcp/connect).

The agent should not invent a slug or an input the form does not accept. It should not start a paid run before it has shown the price.

## Sign in

If a tool call asks you to sign in, finish the consent window the client opened and press Authorize. That page is on [www.edgaze.ai](https://www.edgaze.ai). Do not open `/oauth/consent` yourself. Then retry the same ask. Do not create a second MCP server.

## The loop

Use the tools in this order. Skip catalog when the human already named the job.

1. `edgaze_catalog` when you still need a category map.
2. `edgaze_search` with the human's goal in their words.
3. If search returns `no_match`, stop searching Edgaze. Say so. Use your own tools for the rest of the job.
4. `edgaze_inspect` on one slug. Read the input names, required fields, example values, the price, and `demo_available`. If it returns `required_integrations`, the workflow acts on the human's own accounts (for example Slack or GitHub).
5. If `integrations_ready` is false, do not run yet: `edgaze_run` would be refused with a `connect_url`. Give the human that link, let them connect the accounts and approve the listed actions, then retry the same run.
6. Show the human the price and the fields you still need. Fill inputs from what they said. Ask for anything the schema still requires.
7. `edgaze_run` with those named inputs and a `max_cost_usd` at or above the inspected price. Set `demo: true` only when inspect said a demo is available and they want the free run. It returns `status: "queued"`: the run may wait for capacity before it starts.
8. `edgaze_watch` with `run_id` and `cursor`. Wait `poll_after_ms` after an empty read. Repeat until `terminal` is true. `status` reads `queued` while the run waits in line (with `queue` and a status message), then `running`. Then follow `present` and `how_to_show`.

Do not poll faster than the server asks. Empty watches are cheap. Do not start a second run for the same ask unless the first one failed or they requested it.

## Demo

A demo is a real run of the published workflow with the human's inputs. It is not a video and not a mock.

Inspect reports when a demo is available. One signed-in person gets one demo on a workflow that qualifies. A demo differs from the paid run in three ways: it uses the free-tier model, it adds an Edgaze watermark where the product supports it, and it does not run remixed child workflows. It does not pay the creator and it does not take wallet funds.

If a demo is not available, say that and offer the paid run. Do not set `demo: true` to bypass a missing demo.

## Paid run

Ask the agent to run the same slug with `demo` off. It will quote the price first. That price is creator margin plus compute. `max_cost_usd` is a ceiling so the run cannot cost more than you accepted.

If the wallet cannot cover it, the agent should send you to [Wallet](/wallet), wait until you have added money, and retry. See [Wallet](/docs/mcp/wallet).

A failed or cancelled run does not keep the charge.

## How to show the result

`edgaze_run` and a finished `edgaze_watch` include `url`: `https://www.edgaze.ai/run/{id}`. That is the hosted run page. The owner can open it while signed in.

When `present` is `chat`, deliver the result in this conversation. Paste text and markdown the person can use. If the workflow did something outside the chat (sent an email, published a post, opened a ticket, scraped a page), say what happened and include any confirmation ids or links from the output. Do not dump raw JSON when a readable answer exists. Offer `url` if they want the full run page.

When `present` is `edgaze_page`, this chat cannot show the result well. That is images, video, files, and other media. Give them `url` as the place to view and download it. A short caption is fine. Do not paste base64, data URIs, or binary.

## What good looks like

You: Find something that turns a messy meeting note into action items.

The agent searches, inspects one slug, shows the price, asks for the note if you have not pasted it, runs a demo when one exists, watches until the run finishes, and pastes the action items. If the wallet is empty and you want the paid path, it sends you to the wallet and retries after you return.

You: Make a cinematic product shot of this bottle.

The agent runs the workflow, then sends `https://www.edgaze.ai/run/{id}` so you can open the image on Edgaze. It does not paste the JPEG into chat.

## Next

- [Wallet](/docs/mcp/wallet) if the paid run is waiting on balance
- [For creators](/docs/mcp/for-creators) if this is your workflow


---

---
title: MCP wallet
description: Zero balance is normal on first connect. Add money when you want a paid run. Failed runs do not keep the charge.
source: https://www.edgaze.ai/docs/mcp/wallet
section: mcp
---
# MCP wallet

> Zero balance is normal on first connect. Add money when you want a paid run. Failed runs do not keep the charge.

**Audience: People who just connected Edgaze and the agent handling a paid run.**

**Outcome: Know where to add money, what a run costs, and that an empty wallet is not a broken install.**

## Zero is normal

The first time you connect, the wallet is often empty. That is the start of the path. The install already worked if the five Edgaze tools are listed.

The agent should send you here, then retry the paid run after the balance updates. It should not delete the MCP server or invent a new URL.

## Add money

Open [Wallet](/wallet). Choose an amount and pay. That balance is what paid MCP runs spend.

Use `https://www.edgaze.ai/wallet`. Do not send people to a different host.

After the payment lands, ask the agent to run the same slug again. You do not reconnect.

## What a run costs

Each workflow has one displayed price. The agent reads it from `edgaze_inspect` before it runs. That price is creator margin plus compute.

`max_cost_usd` is the ceiling you accept. The run cannot charge more than that ceiling. If the inspected price is above the ceiling, the agent should raise the ceiling with you or pick another workflow.

Demos never bill. See [Your first run](/docs/mcp/first-run).

## Failed runs

If a run fails or you cancel it, Edgaze does not keep the charge. A hold is released. Ask the agent to try again only after you know why it failed. That is usually a missing input, not a missing connection.

## What the agent should say

When a paid run is blocked on balance, send the human to `https://www.edgaze.ai/wallet`, say the amount that was needed if the tool returned it, and wait. After they return, call `edgaze_run` again with the same slug and the same inputs. Do not start a demo unless they asked for one and inspect still says a demo is available.


---

---
title: MCP for creators
description: Publish once. Agents run the same product marketplace buyers run, at the same price.
source: https://www.edgaze.ai/docs/mcp/for-creators
section: mcp
---
# MCP for creators

> Publish once. Agents run the same product marketplace buyers run, at the same price.

**Audience: Creators who already publish workflows.**

**Outcome: Know that MCP does not need a second graph, and what an agent is allowed to see.**

## Publish once

When you publish in Workflow Studio, that version is what marketplace buyers run, what the REST API runs, and what agents run through MCP. There is no second product and no extra graph.

Keep publishing the way you do today. Agents pick it up from the live catalog. See [Sell to Humans and Agents](/docs/sell-everywhere).

## What agents see

Agents see your title, description, category, displayed price, and the input form with human field names. They also see example values you published. They do not see internal block ids.

A buyer who wants the human path still lands on your product page.

Write the title and the input labels as if a stranger will fill them from chat. Vague names make the agent ask more questions or guess wrong.

If the workflow uses integration blocks (for example Slack or GitHub), inspect tells the agent which accounts it needs and whether the person has connected them. Until they have, a run is refused with a link to connect the accounts and approve the actions; they connect, then the agent retries. Nothing runs or charges before that.

## Demos

If a workflow is cheap enough, hosted by Edgaze, and not remixed, an agent may run one free demo per signed-in user. Some workflows never qualify: you cannot demo your own workflow, a workflow that needs a provider without a sandbox for demos is not eligible, and neither is one whose demo failed in the last 7 days. Each user also has a limited demo budget and an hourly limit on demo starts. A demo is a real execution with that user's inputs. It does not create earnings.

Paid agent runs use the same displayed price and the same creator share as marketplace runs.

## You do not need a second setup

You do not register an MCP server. You do not paste a tool schema. Publishing the workflow is the whole creator step.

If you want agents to find the workflow, keep the listing public, keep the description specific, and set a category when you publish. The classifier will not overwrite a category you chose.


---

---
title: Terms of Service
description: The core terms for using Edgaze: product use, publishing, marketplace transactions, hosted AI runs, platform limits, and legal responsibilities.
source: https://www.edgaze.ai/docs/terms-of-service
last_updated: 2026-10-14
section: legal
---
# Terms of Service

> The core terms for using Edgaze: product use, publishing, marketplace transactions, hosted AI runs, platform limits, and legal responsibilities.

## Overview

> **Plain-English summary (non-binding):** Use Edgaze lawfully, protect your account and provider keys, review AI outputs before relying on them, and only publish material you have the right to use. Creators remain responsible for their listings. Buyers receive access under the listing and payment rules, not ownership of the creator's underlying work. The full Terms below control.

These Terms of Service govern access to and use of Edgaze, a platform operated by **Edge Platforms, Inc.**, a Delaware C-Corp. Edgaze allows users to build, publish, discover, run, sell, and buy hosted AI workflows and prompt products.

By accessing Edgaze, creating an account, publishing a product, purchasing access, or running a workflow, you agree to these Terms and the policies linked from the [Legal & Trust Center](/docs/legal).

> Edgaze provides hosted product experiences and marketplace infrastructure. Customers buy access to products on the platform; they do not buy ownership of creator software, prompts, workflow logic, or intellectual property unless a separate written agreement expressly says so.

## Definitions

**Platform** means Edgaze, including the website, workflow builder, Composer, marketplace, hosted runtime, dashboards, APIs, docs, and related services operated by Edge Platforms, Inc.

**User** means any visitor, account holder, creator, customer, publisher, buyer, or other person who accesses or uses the Platform.

**Creator** means a User who builds, uploads, lists, publishes, sells, or otherwise makes a Product available through Edgaze.

**Customer** means a User who views, buys, runs, or otherwise accesses a Product through Edgaze.

**Product** means a workflow, prompt product, template, listing, hosted experience, or other AI product made available through Edgaze.

**Workflow** means an executable AI workflow, graph, sequence, or runtime experience configured through Edgaze.

**Prompt Product** means a prompt, prompt package, or related prompt-based product made available through Edgaze, including supported products created before Prompt Studio creation was retired.

**Hosted Run** means an execution of a Product through Edgaze infrastructure or runtime orchestration.

**Creator Content** means Product logic, prompts, workflow definitions, listings, descriptions, examples, images, assets, metadata, branding, and other materials submitted or published by a Creator.

**Customer Input** means text, files, prompts, API parameters, or other information submitted by a Customer to run or use a Product.

**Output** means responses, generated content, files, images, text, data, or other results produced by a Product, AI model, API, or workflow execution.

**Third-Party Services** means services not controlled by Edge Platforms, Inc., including payment processors, hosting providers, databases, analytics tools, AI model providers, external APIs, and security tools.

**Marketplace** means Edgaze surfaces that allow Products to be listed, discovered, purchased, run, reviewed, or otherwise distributed.

## Eligibility

You must be at least 13 years old to use Edgaze, or older if your jurisdiction requires a higher age for online services. If you use Edgaze on behalf of an organization, you represent that you have authority to bind that organization.

You may not use Edgaze if you are prohibited from doing so under applicable law, sanctions rules, export controls, or a prior platform suspension.

## Accounts and Security

You are responsible for the accuracy of account information and for activity under your account. You must protect login credentials, API keys, payment credentials, and connected third-party accounts.

You must promptly notify Edgaze if you suspect unauthorized access, credential compromise, or misuse of your account. Edgaze may restrict access when needed to protect users, the Platform, payment integrity, or legal compliance.

## Platform License to Users

Subject to these Terms, Edgaze grants you a limited, revocable, non-exclusive, non-transferable right to access and use the Platform for lawful purposes and in accordance with published policies.

You may not copy, resell, reverse engineer, interfere with, scrape, overload, or misuse the Platform except as permitted by law or a separate written agreement.

## User Content and Ownership

As between you and Edgaze, you retain ownership of content you submit, upload, or publish, subject to the rights you grant to Edgaze and the rights of other users or third parties.

You represent that you have the rights needed to submit, publish, run, sell, and license your content through Edgaze, including rights to prompts, assets, examples, datasets, screenshots, branding, workflow logic, and third-party materials included in your Product.

## License to Operate Products

When you submit, upload, publish, list, sell, or otherwise make Creator Content available through Edgaze, you grant Edge Platforms, Inc. a worldwide, non-exclusive, royalty-free license to host, store, reproduce, process, execute, display, distribute, promote, make available, transmit, modify for technical formatting, analyze for safety and operations, and otherwise use that Creator Content as needed to operate, improve, secure, market, and provide the Platform and Marketplace.

This license includes the right to run Products, generate previews, show listings, process Customer Inputs, return Outputs, operate dashboards, respond to support and safety issues, and maintain records needed for payments, accounting, disputes, fraud prevention, security, and legal compliance.

## Marketplace Role

Edgaze provides infrastructure, hosting, runtime orchestration, discovery, marketplace tools, payment coordination, and creator/customer surfaces. Creators are responsible for their Products, claims, assets, pricing, support expectations, rights, quality, and compliance.

Edgaze is not a Creator's employer, agent, legal representative, financial advisor, broker, fiduciary, professional services provider, or guaranteed distributor. Marketplace ranking, visibility, featuring, traffic, sales, income, and payout timing are not guaranteed.

## Purchases and Access

Customers buy access to hosted product experiences through Edgaze, not ownership of underlying software, source code, prompts, workflow logic, model weights, creator intellectual property, or Edgaze infrastructure.

Access may be limited by account status, payment status, product availability, run limits, BYOK configuration, third-party provider availability, refund or dispute status, safety review, or policy enforcement. Edgaze may revoke or change access where required for payment reversal, fraud, abuse, legal compliance, security, or platform operations.

## AI Outputs and User Verification

Products may rely on AI models, creator-authored prompts, workflow logic, Customer Inputs, APIs, and Third-Party Services. Outputs may be inaccurate, incomplete, unsafe, biased, offensive, outdated, or unsuitable for your purpose.

You are responsible for independently reviewing and verifying Outputs before relying on them. Edgaze does not provide legal, medical, financial, investment, tax, hiring, safety, engineering, or other regulated professional advice through Product Outputs.

## Third-Party Services

Edgaze uses and integrates with Third-Party Services, including Stripe for payments and Stripe Connect for creator onboarding and payout rails, Supabase for data infrastructure, Vercel for hosting and platform analytics/performance tools, Microsoft Azure for the workflow runtime and hosted AI models, Cloudflare Turnstile where enabled for bot prevention, Mixpanel where enabled for product analytics and session replay, PostHog where enabled for mirrored product analytics events, Google Ads for advertising measurement where you accept marketing cookies, Resend for email, AI/model providers such as OpenAI, Anthropic, Google, and Microsoft Azure where configured, and integrations you choose to connect, such as GitHub, Slack, and Google. The [Privacy Policy](/docs/privacy-policy) lists these services in more detail.

Products may also call third-party APIs selected by Creators or Users. You must comply with applicable third-party terms, usage policies, and provider requirements. Third-party outages, policy changes, pricing changes, rate limits, safety systems, or API behavior may affect Products.

## Prohibited Uses

You must comply with the [Acceptable Use Policy](/docs/acceptable-use-policy), [Fraud and Abuse Policy](/docs/fraud-abuse-policy), [Community Guidelines](/docs/community-guidelines), and applicable law.

You may not use Edgaze to create malware, phishing, credential theft, spam automation, abusive scraping, platform manipulation, unlawful surveillance, IP infringement, deepfake abuse, evasion tooling, illegal activity, or workflows primarily designed to abuse other platforms or violate third-party provider terms.

## Creator Terms and Payment Policies

Creators are also bound by the [Creator Terms](/docs/creator-terms), [Creator Guidelines](/docs/creator-guidelines), [Marketplace Fees](/docs/marketplace-fees), [Creator Earnings](/docs/creator-earnings), [Payout System](/docs/payout-system), [Refund Policy](/docs/refund-policy), and [Chargeback Policy](/docs/chargeback-policy).

Payment records, creator earnings, refunds, chargebacks, payout eligibility, reserves, holds, reversals, and pricing limits are governed by those specific policies and by Stripe's applicable terms.

## Suspension and Termination

Edgaze may suspend, restrict, remove, unlist, demonetize, disable, or terminate accounts, Products, listings, runs, access, payouts, or features when reasonably needed to protect the Platform, users, payment integrity, legal compliance, security, marketplace trust, or third-party provider relationships.

Examples include fraud, chargeback abuse, rights infringement, misleading listings, prohibited content, unsafe workflow behavior, sanctions or export issues, security risk, payment processor restrictions, or repeated policy violations.

## Beta Status and Platform Changes

Edgaze is under active development. Features may be experimental, unavailable, changed, limited, deprecated, or removed. The Platform may experience downtime, bugs, data loss, degraded performance, migrations, or unexpected behavior.

The [Platform Status and Beta Disclaimer](/docs/platform-status-beta-disclaimer) applies to all use of Edgaze unless a separate signed agreement states otherwise.

## Disclaimers

To the maximum extent permitted by law, Edgaze is provided on an "as is" and "as available" basis. Edge Platforms, Inc. disclaims warranties of merchantability, fitness for a particular purpose, title, non-infringement, accuracy, availability, security, uninterrupted operation, and error-free performance.

Edgaze does not guarantee Product quality, Creator accuracy, Customer results, AI Output correctness, third-party availability, marketplace sales, ranking, payouts, or continued access to any Product or feature.

## Limitation of Liability

To the maximum extent permitted by law, Edge Platforms, Inc. and its officers, directors, employees, contractors, service providers, and affiliates will not be liable for indirect, incidental, special, consequential, exemplary, or punitive damages, or for lost profits, lost revenue, lost data, loss of goodwill, business interruption, or reliance on AI Outputs.

For any claim relating to the Platform, Products, purchases, runs, content, or these Terms, Edge Platforms, Inc.'s total aggregate liability will not exceed the greater of **$100** or the amounts you paid directly to Edgaze for the Platform in the **three months** before the event giving rise to the claim. This cap does not limit liability that cannot be limited by law.

## Indemnification

You agree to defend, indemnify, and hold harmless Edge Platforms, Inc. from claims, losses, liabilities, damages, costs, and expenses, including reasonable attorneys' fees, arising from your content, Products, Customer Inputs, Outputs you use or distribute, violation of law, breach of these Terms, infringement or misappropriation of rights, misuse of the Platform, payment disputes, or Creator obligations.

Creators also indemnify Edgaze for claims relating to their Products, listings, claims, assets, pricing, support representations, workflow behavior, third-party API usage, and customer-facing statements.

## Export Controls and Sanctions

You may not use, export, re-export, transfer, or make available the Platform or Products in violation of export control, sanctions, anti-terrorism, or anti-money-laundering laws. You represent that you are not located in, organized under the laws of, or ordinarily resident in a sanctioned jurisdiction, and are not on a restricted party list.

## Governing Law and Disputes

These Terms are governed by the laws of the State of Delaware, without regard to conflict-of-law rules.

Unless a separate written agreement states otherwise, disputes will be brought in the state or federal courts located in Delaware, and each party consents to personal jurisdiction and venue there.

## Policy Hierarchy

If policies conflict, the following order applies unless a signed written agreement says otherwise:

1. A signed written agreement between you and Edge Platforms, Inc.
2. These Terms of Service.
3. Creator Terms, payment policies, and product-specific policies.
4. Guidelines, help docs, UI text, and operational notices.

More specific payment, creator, safety, privacy, or IP policies may control their subject matter unless they conflict with these Terms.

## Changes to These Terms

Edgaze may update these Terms as the Platform evolves. Changes become effective when posted unless a later effective date is stated. Continued use of Edgaze after changes take effect means you accept the updated Terms.

## Contact

For legal or platform policy questions, contact `support@edgaze.ai`.


---

---
title: Privacy Policy
description: How Edge Platforms, Inc. collects, uses, shares, stores, and protects information across Edgaze.
source: https://www.edgaze.ai/docs/privacy-policy
last_updated: 2026-10-15
section: legal
---
# Privacy Policy

> How Edge Platforms, Inc. collects, uses, shares, stores, and protects information across Edgaze.

## Introduction

This Privacy Policy explains how **Edge Platforms, Inc.** ("Edgaze," "we," "us," or "our") collects, uses, shares, stores, and protects information when you access or use Edgaze.

Edgaze is a platform for building, publishing, discovering, running, selling, and buying executable AI workflows and prompt products. Privacy on Edgaze includes ordinary account data, marketplace records, AI workflow inputs and outputs, execution logs, creator information, payment-related records, security data, and analytics data where enabled.

## Scope

This Policy applies to visitors, account holders, creators, customers, workflow publishers, prompt publishers, buyers, applicants, and other users of Edgaze.

It applies to the website, builder, templates, marketplace, legacy prompt products, hosted workflow runs, creator dashboards, checkout flows, payout onboarding surfaces, support channels, and related services.

## Information We Collect

We collect information depending on how you use Edgaze.

### Account and Profile Data

We may collect your name, email address, username or handle, profile information, avatar, bio, preferences, authentication identifiers, account status, and related settings.

### Creator and Payout-Related Information

If you publish or monetize Products, we may collect creator profile information, listing details, payout onboarding status, Stripe Connect account identifiers, payout eligibility signals, creator earnings records, pending-claim records, payout display records, refund records, dispute records, country information used for onboarding, and related compliance or accounting information.

Stripe may collect additional identity, tax, bank, verification, and compliance information directly under its own terms and privacy policy.

### Workflow, Prompt, Listing, and Product Content

We collect Creator Content, including workflow definitions, prompt text, product titles, descriptions, images, thumbnails, examples, demos, pricing, metadata, Edgaze codes, configuration, and related publishing materials.

Published listings, creator profiles, workflow pages, prompt pages, public templates, and marketplace metadata may be public.

### Run Inputs, Outputs, and Execution Logs

When a Product is run, Edgaze may collect and store Customer Inputs, runtime configuration, API key routing metadata, run status, timestamps, errors, run outputs, generated files, node state, trace data, execution events, duration, and related logs.

Run records may be used for access control, run limits, debugging, fraud prevention, abuse detection, support, creator analytics where available, marketplace integrity, and operational reliability.

### Purchase and Payment Records

We collect transaction, payment, refund, dispute, payout, and receipt information needed to provide the service, prevent fraud, support users, meet legal obligations, and maintain accounting records. Payment processors may provide transaction and account identifiers associated with these activities.

We do not intentionally store full card numbers. Payment processing is handled by Stripe.

### Support, Reports, and Communications

We collect information you send through support, bug reports, security reports, creator claims, takedown notices, refund requests, chargeback communications, application forms, and other messages.

### Device, Browser, IP, and Log Data

We may collect IP address, user agent, browser, device type, operating system, timestamps, URLs, referrers, request metadata, security events, rate-limit signals, bot-detection signals, approximate location derived from technical data, and diagnostic logs.

### Cookies, Local Storage, and Session Data

Edgaze uses cookies, local storage, session storage, and similar technologies for authentication, session management, routing, security, impersonation controls for admins where applicable, demo run limits, preferences, product analytics, and payment or checkout flows.

### Analytics Data

Where enabled, Edgaze uses product analytics and performance tools, including Mixpanel, PostHog, Vercel Analytics, and Vercel Speed Insights. These tools may collect page views, events, interaction data, device and browser data, approximate location, session identifiers, session recordings where configured, and performance data.

Your cookie preferences have four categories: necessary, analytics, functional, and marketing. Vercel Analytics and Vercel Speed Insights are cookieless. PostHog receives mirrored events, runs cookieless, and does not record sessions. Mixpanel, which is the session replay tool, and session replay itself run only after you accept analytics, and may then use first-party cookies and browser storage. Product events recorded on our servers are linked to your account only when you have accepted analytics; otherwise they are sent without account or persistent identifiers.

### Advertising Measurement

Edgaze advertises through Google Ads. The Google Ads tag loads only after you accept marketing cookies. When it loads, Google and Edgaze may use cookies and the ad click identifiers in the link you arrived from (`gclid`, `gbraid`, or `wbraid`, stored for up to 90 days) to measure whether an ad led to a conversion, such as signing up or completing a run. See the [Cookie Policy](/docs/cookie-policy) for details and to change your choices.

Edgaze also records **first-party product-page events** (pseudonymous session identifiers, listing identifiers, funnel steps, run outcome signals, and aggregate selection metadata) to operate the marketplace, measure conversion, and provide creator analytics. Persistent anonymous identifiers are used only when analytics preferences are accepted. We do not sell this data, do not use it for third-party advertising (ad conversion measurement is limited to what is described above), and do not store message content, uploaded file contents, or emails entered into product forms as analytics properties.

## Sources of Information

We collect information from:

- You directly, when you create an account, publish, buy, run, message, upload, or configure a Product.
- Automatic collection, through logs, cookies, local storage, analytics, security tooling, and runtime systems.
- Stripe and Stripe Connect, for payment, checkout, dispute, payout, onboarding, and account status events.
- Supabase authentication and database services, for account, session, storage, and platform data infrastructure.
- Third-party auth or integration providers, where you choose to use them or where they are part of a workflow.
- AI model and API providers, where needed to execute workflows or return outputs.

## How We Use Information

We use information to operate Edgaze, including to:

- Provide accounts, profiles, marketplace listings, builder features, legacy prompt-product access, dashboards, and hosted workflow runs.
- Execute workflows and prompt products.
- Process Customer Inputs and return Outputs.
- Maintain purchase access and ownership records.
- Process payments through Stripe and attribute creator earnings.
- Support Stripe Connect onboarding, payout eligibility, reserves, holds, refunds, disputes, and accounting records.
- Enforce run limits, BYOK requirements, account limits, and abuse controls.
- Prevent fraud, chargeback abuse, spam, scraping, credential theft, malware, and other misuse.
- Provide support, debug errors, investigate reports, and improve reliability.
- Analyze product usage, conversion, performance, and feature health.
- Maintain security, audit logs, legal records, tax/accounting records, and compliance evidence.
- Enforce Edgaze policies and comply with law.

## AI and Model Provider Processing

To execute workflows, Edgaze may send Customer Inputs, Creator Content, workflow configuration, node instructions, files, metadata, and related context to third-party AI model providers or API providers. Current model providers include OpenAI, Anthropic, Google, and Microsoft Azure (Azure AI Foundry, which hosts models such as Kimi and DeepSeek and powers the Composer assistant), where configured. Workflows may also call external APIs selected by creators or users, and Edgaze-managed data services such as Aviato, which returns person and company information for identifiers (for example a LinkedIn URL or email address) submitted in a run.

Those providers may process submitted information under their own terms, privacy policies, retention rules, abuse monitoring systems, and security practices. You should not submit sensitive data unless it is necessary for the Product and lawful for you to provide.

Outputs may be returned to Edgaze, displayed to users, stored in run records or logs, used for debugging and support, and retained as described in this Policy.

## Google User Data

When you connect your Google account to Edgaze, Edgaze may access Google user data that you explicitly authorize for use in workflows. Depending on the integrations you enable, this may include Google Calendar events, Google Docs documents, Google Sheets spreadsheets, Google Drive files, and permission to send email through Gmail. Google Drive access uses the limited `drive.file` permission: Edgaze can reach only files you pick or files the app creates, not the rest of your Drive.

Edgaze uses this data only to perform workflow actions that you configure or authorize. For example, a workflow may create or modify a calendar event, read or update a document or spreadsheet, save or read a Drive file, or send an email on your behalf.

Google user data may be processed and temporarily stored as necessary to execute workflows, maintain execution state, provide logs, troubleshoot failures, and operate the service. Access credentials and OAuth tokens are stored securely and are not exposed to workflow creators or other users.

Edgaze does not sell Google user data or use Google user data for advertising. Google user data is not used to train general-purpose AI models. Data is shared with service providers only where necessary to provide the requested workflow functionality and subject to applicable privacy and security safeguards.

You may revoke Edgaze's access to your Google account at any time through your Google Account permissions or by disconnecting the integration from Edgaze.

## Creator Visibility and Dashboards

Certain product, sales, usage, payout, and execution information may be visible to creators through creator dashboards, product analytics, purchase surfaces, support flows, or future reporting tools where the Platform makes that information available.

Edgaze also provides admin and operational tools that may allow authorized personnel to inspect transactions, runs, traces, logs, payout records, refund records, disputes, and Product data for support, security, accounting, and platform operations.

Do not assume that Customer Inputs, Outputs, or run logs are confidential from all operational review. Use Products accordingly.

## Public Content

Published workflows, prompt products, listings, creator profiles, public handles, Edgaze codes, descriptions, thumbnails, examples, templates, pricing, and public marketplace pages may be visible to anyone and may be indexed, cached, linked, or shared.

You should not publish confidential information, trade secrets, private credentials, regulated data, or third-party materials unless you have the rights and authority to do so.

## Third-Party Services and Sharing

We may share information with service providers and third parties that help operate Edgaze, including:

- Stripe and Stripe Connect for payments, checkout, disputes, refunds, creator onboarding, payout rails, accounting, and compliance.
- Supabase for authentication, database, storage, and backend infrastructure.
- Vercel for hosting, analytics, performance monitoring, and deployment infrastructure.
- Microsoft Azure for the workflow runtime, run-stream cache, and hosted AI models.
- Cloudflare Turnstile where enabled for bot prevention and abuse protection.
- Mixpanel where enabled for product analytics and session replay.
- PostHog where enabled for mirrored product analytics events (no session replay).
- Google Ads, after marketing consent, for advertising conversion measurement.
- Resend for transactional email.
- Calendly where you book a call through an embedded scheduler.
- AI/model providers such as OpenAI, Anthropic, Google, and Microsoft Azure where needed for workflow execution.
- Integrations you choose to connect, such as GitHub, Slack, and Google (Gmail, Calendar, Docs, Sheets, and Drive), to perform the workflow actions you authorize.
- Edgaze-managed data services used by workflow steps, such as Aviato for person and company enrichment from identifiers submitted in a run.
- Webshare, a proxy provider, which relays the request when a workflow step fetches a YouTube transcript, or reads a web page that blocked Edgaze's own servers. It sees the address being fetched and the response, not your account details.
- External APIs selected by Creators or Users in workflow configurations.
- Support, security, logging, storage, and infrastructure providers where used.
- Professional advisors, auditors, insurers, payment partners, banks, processors, regulators, law enforcement, or courts where required or appropriate.
- Successors or counterparties in a merger, acquisition, financing, restructuring, asset sale, bankruptcy, or similar corporate transaction.

We may also share information to enforce terms, protect rights and safety, prevent fraud or abuse, respond to lawful requests, investigate disputes, or protect marketplace integrity.

## Cookies and Similar Technologies

Edgaze uses necessary cookies and similar technologies for authentication, session security, admin controls, checkout flows, bot prevention, and essential platform operation.

Edgaze may use analytics cookies or browser storage after you accept analytics, and advertising cookies after you accept marketing. Browser storage may also support return paths, demo run tracking, device-based demo limits, preferences, and recovery from outdated app versions.

You may control cookies through browser settings, but disabling cookies or storage may break authentication, checkout, security checks, or platform features.

## Data Retention

We retain information as long as reasonably needed for the Platform, marketplace access, hosted runs, creator dashboards, support, accounting, tax, legal, fraud prevention, security, dispute handling, audit, backup, and compliance purposes.

Some records, such as payment records, purchase history, payout records, refund and dispute records, audit logs, security records, and evidence needed for legal or accounting purposes, may be retained after account deletion or product removal.

We do not promise permanent retention or immediate deletion of every copy, backup, log, or derived record.

## Security

We use reasonable administrative, technical, and organizational safeguards designed to protect information. No system is perfectly secure. Unauthorized access, provider failure, software bugs, user error, credential compromise, or other incidents may occur.

You are responsible for protecting your account, devices, browser sessions, API keys, credentials, and third-party accounts.

## International Transfers

Edgaze primarily operates and processes data in Singapore and Southeast Asia: our database, application hosting, and workflow runtime run in Singapore, and our run-stream cache runs in Malaysia. Our service providers may also process, store, or transfer information in other countries, including the United States. Those jurisdictions may have data protection laws different from those where you live.

## User Rights

Depending on your jurisdiction, you may have rights to request access, correction, deletion, portability, objection, restriction, or withdrawal of consent for certain personal data.

These rights may be limited by law, security needs, payment and accounting records, fraud prevention, dispute records, backup systems, technical feasibility, legal claims, or legitimate business needs. To make a request, contact `support@edgaze.ai`.

## Children

Edgaze is not intended for children under 13, or a higher age where required by law. We do not knowingly collect personal information from children in violation of applicable law. If you believe a child has provided information to Edgaze, contact us.

## Sensitive Data

You should not submit sensitive personal data, protected health information, financial account credentials, government identifiers, secrets, private keys, passwords, regulated data, or confidential third-party information unless it is necessary, lawful, and appropriate for the Product you are using.

## Changes to This Policy

We may update this Privacy Policy as Edgaze evolves. Changes become effective when posted unless a later effective date is stated. Continued use of Edgaze after the effective date means you acknowledge the updated Policy.

## Contact

For privacy requests or questions, contact `support@edgaze.ai`.


---

---
title: Cookie Policy
description: How Edgaze uses cookies, local and session storage, analytics, ad measurement, embeds, security tools, and payment technologies.
source: https://www.edgaze.ai/docs/cookie-policy
last_updated: 2026-10-14
section: legal
---
# Cookie Policy

> How Edgaze uses cookies, local and session storage, analytics, ad measurement, embeds, security tools, and payment technologies.

## Overview

This Cookie Policy explains how **Edge Platforms, Inc.** uses cookies, local storage, session storage, pixels, SDK storage, embedded third-party technologies, and similar browser technologies on Edgaze.

It should be read with the [Privacy Policy](/docs/privacy-policy). The Privacy Policy explains broader data handling; this policy focuses on what may be stored in or read from your browser.

## What We Mean by Cookies and Similar Technologies

**Cookies** are small files placed on your browser or device. **Local storage** and **session storage** are browser storage mechanisms that can keep information on your device. **SDK storage, pixels, scripts, iframes, and embeds** may also collect or store identifiers, preferences, event data, or security signals.

Edgaze uses these technologies directly and through service providers.

## Categories We Use

### Strictly Necessary Technologies

These support core platform operation, authentication, security, routing, checkout, fraud prevention, and reliability.

Examples include:

- Supabase authentication and session behavior.
- Return-path storage used after sign-in or checkout flows.
- Admin impersonation security cookies where applicable.
- Cloudflare Turnstile proof cookies or related bot-prevention signals where Turnstile is used.
- Stripe checkout, embedded checkout, Connect, and payment-related browser technologies.
- Storage used to recover from outdated app versions or route transitions.

Disabling these technologies may break sign-in, checkout, demo runs, anti-abuse checks, or other platform features.

### Analytics and Performance Technologies

Edgaze uses analytics and performance tools to understand product usage, page performance, conversion, reliability, and feature health.

Current code uses:

- Mixpanel for product analytics, page-view events, user identification after you accept, and session replay after you accept.
- PostHog for mirrored product analytics events. PostHog does not record sessions.
- Vercel Analytics for site analytics.
- Vercel Speed Insights for performance measurement.
- Web vitals and internal performance signals.

**Mixpanel analytics preferences.** Mixpanel is our product analytics and session replay tool. Rejecting non-essential cookies disables Mixpanel analytics cookies, local storage persistence, identity tracking, person profiles, and session replay.

If you reject (or have not yet chosen), Edgaze may still collect **basic cookieless product analytics** to understand aggregate usage and keep the platform reliable. Cookieless analytics does not store Mixpanel cookies or local storage identifiers, does not identify you as a person, and does not record sessions. PostHog may receive the same cookieless events.

Edgaze also runs **first-party product-page telemetry** (session storage for same-visit funnel stitching; optional persistent anon id in local storage only when you accept analytics). This powers marketplace operation, creator analytics, and conversion reliability. It does not sell data and does not store free-text form contents, file contents, or emails typed into product forms. Google Ads measurement is separate and covered under [Marketing Technologies](#marketing-technologies).

If you accept analytics, Mixpanel may use first-party cookies and browser storage, identify your signed-in account for session continuity, and record sessions (with inputs masked), including for logged-out visitors. Known bots and crawlers are excluded. PostHog may receive mirrored events and does not record sessions.

Your choice in the cookie preference center is the canonical browser record for optional analytics.

Older browser flags `edgaze:disable_mixpanel` and `edgaze:disable_posthog` are still treated as a reject decision.

**Server-side events.** Some product events (for example a workflow run starting or finishing, a workflow being created or published, a checkout starting, or a purchase completing) are sent to Mixpanel and PostHog from Edgaze's servers rather than your browser. They are tied to your account only when your browser's `edgaze_consent` cookie records that you allowed analytics in the current version of the preference center. Otherwise, including when you have not chosen yet, they are sent anonymously: with no account ID, device identifier, or person profile, and a new random ID for each event. Events that do not come from your browser, such as payment confirmations from Stripe, scheduled jobs, the workflow runtime, and calls through the Edgaze MCP server, are always sent anonymously. This does not change the records Edgaze keeps in its own database to operate the platform, such as run history and creator dashboards.

**Vercel Analytics and Vercel Speed Insights are cookieless.** They measure aggregate traffic and page performance without setting cookies or storing identifiers on your device, so we treat them as strictly necessary and they run without a separate consent step.

### Security, Abuse Prevention, and Demo-Limit Technologies

Edgaze may use browser signals and storage to prevent abuse, enforce demo limits, verify bot challenges, detect stale sessions, reduce duplicate actions, and protect hosted workflow infrastructure.

Examples include:

- Cloudflare Turnstile scripts and proof cookies for verification where enabled.
- Device or browser signals for demo run limits.
- Local storage used for one-time or limited demo-run checks.
- Logs and request metadata used with server-side abuse controls.

### Platform Preference and Workflow Technologies

Edgaze may use local storage or session storage for product experience details such as:

- Returning users to the page they intended to visit after authentication.
- Remembering user-initiated purchase or run intent during redirects.
- Draft support for feedback or bug forms.
- Builder, demo, marketplace, or workflow runtime UI state.
- Temporary client-side caches that improve responsiveness.

These storage items are not a substitute for server-side records and may be cleared by your browser.

### Payment and Payout Technologies

Stripe and Stripe Connect may use cookies, scripts, frames, redirects, device signals, and browser storage to process payments, prevent fraud, support embedded checkout, operate Connect onboarding, comply with legal obligations, and secure payment flows.

Stripe controls its own payment technologies under Stripe's terms and privacy policy.

### Scheduling and Calendly Embeds

Edgaze uses Calendly scheduling in some places, including an inline widget on the contact page and a popup scheduling widget on the invest page.

Calendly embeds load scripts and assets from Calendly domains and may set or read cookies, local storage, or similar technologies for scheduling, availability, routing, analytics, fraud prevention, preference, and session purposes. Calendly may collect information such as scheduling details, browser data, IP address, referral data, and interaction data under Calendly's own terms and privacy policy.

Because Calendly is a third party that can set its own cookies, these embeds fall under the **Functional & embeds** consent category. Calendly's scripts and stylesheets do not load until you allow that category; until then you'll see a short notice with a one-click option to enable scheduling. Some Edgaze embeds may hide Calendly's own GDPR banner for a cleaner in-product experience. Hiding that banner does not mean Calendly sets no cookies or uses no similar technologies.

### Marketing Technologies

Edgaze uses **Google Ads** to measure which ads bring people to Edgaze. This falls under the **Marketing** consent category, which is off until you allow it.

- **Before you allow marketing**, Edgaze does not load Google's tag (gtag.js), sends nothing to Google Ads, and stores no ad click identifiers. If you arrive from an ad, the click identifier in the page address (`gclid`, `gbraid`, or `wbraid`) is only held in memory for that page and is stored only if you allow marketing before leaving it.
- **After you allow marketing**, Edgaze loads Google's tag from `googletagmanager.com` with Google Consent Mode set to grant ad storage and ad user data. Ad personalization stays denied, and Edgaze does not use Google Analytics. Google may set its own first-party conversion cookies, such as `_gcl_aw` and `_gcl_au`.
- **Conversions.** With marketing allowed, Edgaze tells Google Ads when an account is created and when a workflow run completes, using the account ID or run ID only as a de-duplication key. A session-storage flag (`edgaze:ads-conv:…`) stops the same conversion being sent twice.
- **Click identifiers.** With marketing allowed, ad click identifiers are stored in the `edgaze:ads-click-ids` local-storage key and the `edgaze_ads_click` cookie for up to 90 days, and copied to your account when you sign up so a later sign-up can be attributed to the ad click.
- **If you withdraw marketing**, Edgaze updates Consent Mode to denied, deletes the `edgaze:ads-click-ids` key and the `edgaze_ads_click` cookie, and expires Google's `_gcl_` cookies. A tag already loaded on the open page stays loaded until you leave or reload it, but with consent denied it no longer sets ad cookies.

Google processes this information under its own terms and privacy policy.

## Third-Party Providers

Depending on the page or feature, browser technologies may be provided by:

- Supabase for authentication and platform data infrastructure.
- Stripe for checkout, payments, Connect onboarding, fraud prevention, and payout-related flows.
- Vercel for analytics, performance insights, and hosting infrastructure.
- Mixpanel for product analytics and session replay where configured.
- PostHog for mirrored product analytics events (no session replay).
- Cloudflare Turnstile for bot prevention and challenge verification.
- Calendly for scheduling embeds and booking flows.
- Google Ads for ad conversion measurement, only after you allow marketing.
- AI/model or external API providers indirectly, when a workflow opens or calls third-party services.

Third-party providers may process information under their own policies. Edgaze does not control all cookies or storage used by third-party scripts, embedded widgets, or payment flows.

## Your Choices

### Cookie Preference Center

Edgaze provides a built-in cookie preference center. When you first arrive, a small banner lets you **Allow** all optional categories, keep **Essentials only**, or open **Preferences** for category-by-category control. You can reopen it anytime from the **Cookie preferences** link in the site footer or by visiting [/cookie-preferences](/cookie-preferences).

You can choose per category:

- **Strictly necessary**, always on; cannot be disabled. Includes cookieless performance measurement (Vercel Analytics and Speed Insights).
- **Analytics & performance**, Mixpanel product analytics and session replay after you allow it. Off until you allow it. Rejecting this category keeps cookieless events only.
- **Functional & embeds**, third-party embedded tools such as Calendly scheduling. Off until you allow it.
- **Marketing**, Google Ads conversion measurement and ad click identifiers. Off until you allow it.

Allowing everything turns on every optional category; **Essentials only** (or **Reject all** in the preference center) turns them all off.

Your decision is recorded in your browser under the `edgaze:cookie-consent` local-storage key and mirrored to the `edgaze_consent` cookie for up to 180 days so it can be remembered across visits and so Edgaze's servers can respect it. The decision is versioned; if our categories change in a way that requires fresh consent, the banner reappears. Adding the Marketing category was such a change, so earlier decisions are asked again and never count as consent to marketing. Clearing your browser storage resets your choice and shows the banner again.

### Browser controls

You can also control cookies through your browser settings, and clear local storage and session storage through browser developer tools or privacy settings.

Blocking cookies, JavaScript, third-party scripts, local storage, iframes, or embedded widgets may prevent Edgaze features from working. For example, sign-in, checkout, Stripe Connect onboarding, Calendly scheduling, Turnstile verification, demo run limits, or route recovery may fail or behave unexpectedly.

## Changes

We may update this Cookie Policy as Edgaze adds or changes analytics, advertising measurement, scheduling, payment, security, marketplace, or workflow technologies.

## Contact

For questions about cookies or privacy, contact `support@edgaze.ai`.


---

---
title: Acceptable Use Policy
description: Rules governing permitted and prohibited use of Edgaze accounts, listings, workflows, prompts, automation, and hosted runs.
source: https://www.edgaze.ai/docs/acceptable-use-policy
last_updated: 2026-10-14
section: legal
---
# Acceptable Use Policy

> Rules governing permitted and prohibited use of Edgaze accounts, listings, workflows, prompts, automation, and hosted runs.

## Purpose

This Acceptable Use Policy applies to all use of Edgaze, including accounts, profiles, listings, workflows, prompt products, templates, hosted runs, marketplace activity, APIs, comments, reviews, uploads, and automation.

It supplements the [Terms of Service](/docs/terms-of-service). If you publish Products, the [Creator Terms](/docs/creator-terms) and [Creator Guidelines](/docs/creator-guidelines) also apply.

## General Standard

You may use Edgaze only for lawful, safe, honest, authorized, and rights-compliant purposes. You are responsible for Customer Inputs you submit, Creator Content you publish, Outputs you use or distribute, third-party APIs you call, and workflow behavior you design.

You must not use Edgaze to abuse other users, other platforms, third-party providers, payment systems, model providers, or public infrastructure.

## Security Abuse

You may not create, publish, run, sell, or promote Products that:

- Deliver, generate, disguise, or coordinate malware, ransomware, credential stealers, botnets, or malicious payloads.
- Facilitate phishing, credential theft, session hijacking, token theft, or social engineering.
- Generate exploit chains, evasion methods, intrusion instructions, vulnerability exploitation, or unauthorized persistence.
- Bypass authentication, rate limits, paywalls, CAPTCHAs, safety systems, robots.txt, access controls, or platform restrictions.
- Probe, scan, scrape, overload, reverse engineer, disrupt, or degrade Edgaze or third-party systems without authorization.

## Fraud, Spam, and Platform Manipulation

You may not use Edgaze for fraud, scams, spam automation, fake engagement, fake reviews, payment abuse, refund abuse, chargeback abuse, affiliate abuse, marketplace manipulation, deceptive funnels, impersonation, or misrepresentation.

Products designed primarily to abuse another platform, violate another platform's terms, or automate prohibited behavior are not allowed.

## Privacy and Data Misuse

You may not use Edgaze for unauthorized surveillance, stalking, doxxing, scraping personal data, collecting credentials, enriching personal profiles without lawful basis, deanonymization, or disclosure of private, confidential, or regulated data without authority.

Some workflow steps look up information about people or companies from identifiers you submit, such as an email address, a LinkedIn URL, or a company website. You must have a lawful basis for any personal data you submit to these enrichment steps and for how you use the results.

You may not upload or process sensitive data unless you have a lawful basis, necessary rights, and a Product design appropriate for that data.

## Deceptive AI, Deepfakes, and Impersonation

You may not create or distribute deceptive synthetic media, voice clones, deepfakes, impersonation workflows, fake identity documents, fake endorsements, fraudulent reviews, fabricated testimonials, or systems designed to mislead people about who said or did something.

Clear parody, commentary, or non-deceptive creative use may be allowed when lawful and not harmful, but Edgaze may restrict content that creates marketplace, safety, or legal risk.

## Regulated and High-Risk Claims

You may not present AI Outputs as definitive professional advice in legal, medical, financial, tax, insurance, employment, housing, credit, education, safety, or similarly regulated contexts.

Products may help organize information, draft text, or assist analysis, but they must not mislead users into treating Outputs as a substitute for qualified professional judgment where professional review is required.

## Harmful Content

You may not create, publish, run, sell, or promote content involving:

- Child sexual abuse material, sexual exploitation, grooming, or sexualized minors.
- Non-consensual sexual content or intimate imagery.
- Terrorist or extremist recruitment, praise, operational support, or instructional content.
- Threats, harassment, hate, dehumanization, or incitement to violence.
- Self-harm encouragement, suicide instructions, or content that intensifies acute self-harm risk.
- Illegal weapons procurement, violent wrongdoing, or instructions for causing physical harm.

## Intellectual Property and Third-Party Terms

You may not publish or run Products that infringe copyrights, trademarks, trade secrets, publicity rights, licenses, platform terms, model provider terms, API terms, or contractual restrictions.

Creators must have rights to prompts, workflow logic, assets, examples, screenshots, branding, demos, and Product claims.

## AI and Provider Safety Systems

You may not attempt to bypass model provider safety systems, jailbreak restrictions, obscure prohibited requests, launder content through multiple models, or design workflows that intentionally defeat safety filters or usage policies.

You must comply with applicable terms and policies of OpenAI, Anthropic, Google, Microsoft Azure, Stripe, Supabase, Vercel, Cloudflare, connected integrations such as GitHub and Slack, and other services used in connection with Edgaze or your Products.

## Enforcement

Edgaze may remove content, disable runs, restrict listings, suspend accounts, withhold or delay payouts, reverse earnings, block purchases, preserve evidence, notify providers, or cooperate with legal requests when necessary to protect users, creators, payment integrity, or the Platform.

Enforcement may be immediate for severe abuse and may occur without prior notice.

## Reporting

Report suspected violations to `support@edgaze.ai`. Security issues should be reported under the [Security and Responsible Disclosure](/docs/security-responsible-disclosure) policy.


---

---
title: Platform Status and Beta Disclaimer
description: Operational disclosures for Edgaze beta status, experimental features, availability, data loss risk, and no-SLA usage.
source: https://www.edgaze.ai/docs/platform-status-beta-disclaimer
last_updated: 2026-10-14
section: legal
---
# Platform Status and Beta Disclaimer

> Operational disclosures for Edgaze beta status, experimental features, availability, data loss risk, and no-SLA usage.

## Overview

Edgaze is under active development. Features may be experimental, incomplete, changing, limited, unavailable, or removed.

Unless a separate written agreement says otherwise, Edgaze does not provide a service level agreement, uptime commitment, or guaranteed recovery timeline.

Current platform status and incident updates are posted at [status.edgaze.ai](https://status.edgaze.ai).

## Beta and Experimental Status

Edgaze is under active development. Features may be experimental, incomplete, changing, limited, unavailable, or removed.

This includes the builder, Composer, templates, marketplace, creator monetization, workflow runs, dashboards, provider-key modes, and analytics.

## Operational Risks

### Platform interruptions

Edgaze may experience bugs, downtime, degraded performance, data loss, migration issues, failed runs, incorrect outputs, checkout issues, dashboard inaccuracies, broken integrations, provider outages, or other interruptions.

### High-risk use cases

You should not rely on Edgaze for production, mission-critical, regulated, emergency, safety-critical, or high-risk use cases unless a separate written agreement expressly provides appropriate commitments.

## No SLA

Unless a separate written agreement says otherwise, Edgaze does not provide a service level agreement, uptime commitment, support response time, recovery time objective, or maintenance schedule.

## User Backups

Users and creators should maintain independent copies of important prompts, workflow logic, assets, listings, records, and outputs. Edgaze may not be able to recover deleted, corrupted, or migrated data.

## Platform Changes

Edgaze may change pricing, run limits, feature availability, model routing, provider support, publishing requirements, safety controls, payout requirements, or policy enforcement for future use.

## Related Policies

- [Terms of Service](/docs/terms-of-service)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [Content Disclaimer](/docs/content-disclaimer)
- [Privacy Policy](/docs/privacy-policy)


---

---
title: Content Disclaimer
description: Disclosures for creator content, user-generated content, AI outputs, third-party dependencies, and professional reliance.
source: https://www.edgaze.ai/docs/content-disclaimer
last_updated: 2026-10-14
section: legal
---
# Content Disclaimer

> Disclosures for creator content, user-generated content, AI outputs, third-party dependencies, and professional reliance.

## Overview

Edgaze hosts creator-published workflows, supported prompt products, templates, listings, profiles, examples, and comments. Much of this material is user-generated. Creators are responsible for what they publish, and users must evaluate products and outputs before relying on them.

Publication on Edgaze does not mean Edgaze endorses a Product, Creator, claim, Output, or result.

## Creator and User Content

### Creator responsibility

Creators are responsible for the content they publish, the claims they make, and the rights they use.

### Customer and user inputs

Customers and users are responsible for Customer Inputs they submit and Outputs they use or distribute.

### No endorsement through placement

Listings, examples, demos, rankings, metrics, reviews, or marketplace placement should not be treated as independent verification by Edgaze.

## AI Outputs and Product Results

### Output limitations

AI Outputs may be inaccurate, incomplete, biased, unsafe, outdated, offensive, or unsuitable for your purpose. Workflows may depend on prompts, model behavior, third-party APIs, user inputs, external context, and provider availability.

### Independent review

You must independently review and verify Outputs before relying on them.

## No Professional Advice

Edgaze Products and Outputs are not legal, medical, financial, investment, tax, employment, safety, engineering, or other regulated professional advice. Do not rely on Products as a substitute for qualified professionals where professional review is required.

## No Guaranteed Results

Edgaze does not guarantee sales, income, rankings, workflow performance, model accuracy, business outcomes, compliance outcomes, or Product suitability.

## Third-Party Dependencies

Products may depend on model providers (including OpenAI, Anthropic, Google, and Microsoft Azure), APIs, connected integrations, hosting, Stripe, Supabase, Vercel, analytics tools, security tools, and other services. Those services may change, fail, rate-limit, reject requests, alter pricing, or enforce their own policies.

## User Responsibility

You are responsible for evaluating Products, reading listings, understanding limitations, choosing what information to submit, complying with law, and deciding whether Outputs are safe and appropriate for your use.

## Related Policies

- [Terms of Service](/docs/terms-of-service)
- [Acceptable Use Policy](/docs/acceptable-use-policy)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [AI Demo Inputs](/docs/ai-demo-inputs)
- [Composer & Generative AI](/docs/builder/composer-ai)


---

---
title: Payments Overview
description: How customers fund runs with a wallet or bundles, how Stripe and Stripe Connect handle checkout and creator payouts, and where legacy unlocks fit.
source: https://www.edgaze.ai/docs/payments-overview
last_updated: 2026-09-02
section: legal
---
# Payments Overview

> How customers fund runs with a wallet or bundles, how Stripe and Stripe Connect handle checkout and creator payouts, and where legacy unlocks fit.

## Overview

Edgaze uses **Stripe** for buyer checkout (wallet top-ups, locked bundles, and legacy unlock purchases) and **Stripe Connect** for creator payout onboarding and payout rails. Per-run workflow listings charge a single displayed price per successful run. Buyers fund runs through a **wallet**, a **locked bundle** (5 or 10 prepaid runs for one workflow version), or the **API** path, which draws from wallet balance.

Customers buy access to hosted Edgaze product experiences. They do not buy ownership of creator prompts, workflow logic, source code, model access, or Edgaze infrastructure. Read the [Billing guides](/docs/billing) for step-by-step funding and charge detail.

## Funding Doors

### Wallet

Buyers may top up a platform wallet (minimum top-up rules apply). Wallet balance works across workflows. At run trigger, if no eligible bundle applies, Edgaze debits wallet balance for the displayed per-run price.

### Locked bundles

Buyers may purchase a **5-run** or **10-run** bundle for a specific workflow version at the per-run displayed price times bundle size. Bundles require a minimum total charge. Draw order at trigger is **bundle first, then wallet**. Failed runs do not consume a bundle run.

### API runs

API-authenticated runs use the same billing path as wallet runs after API key auth and spend-cap checks.

## Per-Run vs Legacy Unlock

Edgaze supports two marketplace purchase models:

| Model                 | How it works                                                                                                                                                                 |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Per-run** (current) | Creator sets margin; buyer sees one price and funds successful runs through wallet or bundle. The API uses the same funding. Creator earns 80% of margin. |
| **Legacy unlock**     | Older listings used a one-time checkout price before per-run pricing existed. Access follows unlock terms; earnings follow the split recorded at purchase.                   |

New paid workflow listings use the per-run model. Read [Legacy Unlock](/docs/billing/legacy-unlock) for identification rules and buyer behavior.

## What Customers Buy

### Workflow products

For per-run workflow products, buyers pay per successful hosted run (or prepay runs via bundle). Displayed price is fixed within the input envelope.

### Prompt products

For prompt products, a purchase provides access to the prompt product experience packaged and delivered through Edgaze at the listed unlock price.

### Access limitations

Access can be affected by payment status, refund status, dispute status, account status, wallet or bundle balance, BYOK requirements, product availability, safety review, version pinning, or policy enforcement.

## Money Flow (Per-Run)

| Step        | What Happens                                                              |
| ----------- | ------------------------------------------------------------------------- |
| Funding     | Buyer tops up wallet or buys a bundle via Stripe checkout.                |
| Trigger     | Edgaze confirms available wallet or bundle funding.                       |
| Success     | You are charged the displayed price; the creator earns 80% of margin.     |
| Failure     | Ordinary failed runs are not charged, and a bundle run is not used.       |
| Payout path | Stripe Connect onboarding and eligibility control creator payout release. |

## Creator Share

Unless a separate written agreement applies, the default split is **80% of creator margin** to the creator and **20% of creator margin** to Edgaze on each successful run. Compute is not part of creator earnings.

The creator dashboard shows the earnings amount that applies to each successful sale.

## Stripe's Role

Stripe handles card processing, checkout sessions, payment intents, refunds, disputes, and parts of tax or payment compliance where configured. Stripe Connect handles creator onboarding, verification, and payout rails.

Stripe's availability, terms, fees, verification decisions, dispute process, account restrictions, and payout timing may affect transactions.

## Taxes

Taxes, VAT, GST, sales tax, and similar obligations may be calculated, collected, or displayed by Stripe where configured. Edgaze does not guarantee that every tax obligation is automatically handled for every transaction, creator, or jurisdiction.

Creators and customers remain responsible for their own tax obligations unless applicable law states otherwise.

## Refunds and Chargebacks

Refunds and disputes may affect purchase access and related balances. Refund requests follow the [Refund Policy](/docs/refund-policy). Chargebacks are handled through Stripe and card networks.

Read [Refund Policy](/docs/refund-policy) and [Chargeback Policy](/docs/chargeback-policy) before buying or selling.

## Related Policies

- [Funding Runs](/docs/billing/funding-runs)
- [Marketplace Fees](/docs/marketplace-fees)
- [Creator Earnings](/docs/creator-earnings)
- [Payout System](/docs/payout-system)
- [Pricing Limits](/docs/pricing-limits)


---

---
title: Marketplace Fees
description: How Edgaze platform fees apply to creator margin on successful per-run sales, separate from compute recovery.
source: https://www.edgaze.ai/docs/marketplace-fees
last_updated: 2026-10-14
section: legal
---
# Marketplace Fees

> How Edgaze platform fees apply to creator margin on successful per-run sales, separate from compute recovery.

## Overview

Edgaze charges a **20% platform fee on creator margin** for each successful per-run marketplace sale. The creator keeps **80% of the margin** they set at publish. Hosted compute is priced separately and is not included in the margin split.

Unless a separate written agreement or active creator-specific override applies, this margin split is the default for per-run workflow listings. Read the [Billing guides](/docs/billing) for the full charge sequence.

## Fee Calculation

The buyer sees one price containing creator margin plus applicable hosted compute. Only the margin portion is split between creator and Edgaze.

| Item                         | Example                                                       |
| ---------------------------- | ------------------------------------------------------------- |
| Creator margin per run       | $5.00                                                         |
| Hosted compute estimate      | $0.50                                                         |
| Buyer pays (displayed price) | $5.50                                                         |
| Creator earns                | $4.00                                                         |
| Edgaze margin fee            | $1.00                                                         |
| Compute portion              | Included in what the buyer pays, not part of creator earnings |

Edgaze records gross margin, platform fee, and your net earnings for each successful run. The creator's share is rounded down to the nearest microdollar ($0.000001).

## Compute and Margin Are Separate

Hosted compute is Edgaze's cost to serve the run. It is included in what the buyer pays as part of the displayed price and is **not** part of your margin earnings. Creators never earn a share of compute.

Infrastructure estimates shown during publishing help creators set margin responsibly. They are pricing guidance, not an additional fee deducted from creator earnings. Read [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation).

## Payment Processing

Your creator dashboard shows the earnings amount that applies to each successful sale. Payment-processing arrangements do not change the displayed creator share unless a separate written agreement says otherwise.

If a separate written agreement or future platform change modifies fee treatment, that agreement or updated policy controls prospectively.

## Legacy Unlock Purchases

Older listings sold through **legacy checkout** follow the purchase-time split recorded at checkout, not the per-run margin model used by new listings. Read [Legacy Unlock](/docs/billing/legacy-unlock) for the dual-model distinction.

## Separate Agreements

A separate written agreement may set different commercial terms. Where one applies, the dashboard reflects those terms.

## Changes

Edgaze may update marketplace fees for future transactions. Past sales remain subject to the fee split recorded for those transactions unless corrected for refunds, disputes, fraud, or platform error.

## Related Policies

- [What You Pay For](/docs/billing/what-you-pay-for)
- [Creator Earnings](/docs/creator-earnings)
- [Payments Overview](/docs/payments-overview)
- [Pricing Limits](/docs/pricing-limits)


---

---
title: Creator Earnings
description: How creator earnings accrue at 80% of margin per successful run, clear over 7 days, pay out weekly above $25, and are clawed back on refund.
source: https://www.edgaze.ai/docs/creator-earnings
last_updated: 2026-10-14
section: legal
---
# Creator Earnings

> How creator earnings accrue at 80% of margin per successful run, clear over 7 days, pay out weekly above $25, and are clawed back on refund.

## Overview

Creator earnings are Edgaze accounting records for marketplace sales. They are not a bank account, deposit account, stored value balance, or guarantee that funds are immediately payable.

On each **successful per-run sale**, Edgaze records **80% of the creator margin** for you, rounded down to the nearest microdollar ($0.000001). Compute charges are separate and do not count toward your earnings. Read [Creator Earnings Guide](/docs/billing/creator-earnings-guide) and the [Billing guides](/docs/billing) for the full path from sale to payout.

## What Earnings Mean

Creator earnings are your share of margin on successful runs, not the buyer's full displayed price. A buyer may pay margin plus compute; only the margin portion counts toward what you earn.

For legacy purchases completed before per-run pricing existed, earnings follow the split recorded at checkout, not the per-run margin model. Read [Legacy Unlock](/docs/billing/legacy-unlock).

## Gross, Fee, and Net (Per-Run)

| Record       | Meaning                                                             |
| ------------ | ------------------------------------------------------------------- |
| Run margin   | The per-run margin you set for that workflow.                       |
| Platform fee | Edgaze's 20% share of margin, unless a separate agreement applies.  |
| Creator net  | 80% of margin, rounded down to the nearest microdollar ($0.000001). |

Your net amount is what counts toward payout eligibility before any holds, reversals, disputes, or adjustments.

## Earnings Status

Each successful run follows: **pending, then 7-day clearing, then available, then payout**.

- **Pending**: recorded immediately when a run completes successfully; clears automatically after a **7-day** window covering refund and dispute risk.
- **Available**: cleared earnings, eligible for the next weekly payout once they reach the **$25** minimum (smaller balances carry forward).
- **Paid**: transferred to your connected Stripe account on the weekly payout run.

### Held until onboarding

If you have not completed payout onboarding, earnings still accrue and still clear from pending to available on the normal 7-day schedule, but they are **held** and cannot be paid out until you connect a payout-ready Stripe account. Held balances are durable, are never lost, and are released for payout on the next weekly run after onboarding completes.

## Payout Eligibility

Visible earnings do not mean immediate payout release. Payout eligibility depends on Stripe Connect onboarding, verification, sanctions and compliance checks, fraud review, refund and chargeback risk, reserves, holds, account status, and platform controls.

Stripe handles payout rails. Edgaze records payout-related events for dashboard and accounting purposes. Read [Payout System](/docs/payout-system).

## Refunds and Partial Refunds

### Refunds are handled by support

Refunds of runs are handled by Edgaze support. Buyers ask support, and each request is reviewed case by case under the [Refund Policy](/docs/refund-policy). A run is never refunded automatically.

### Per-run sales

When support approves a refund for a run, your still-pending earnings from that sale are reversed. Earnings from that sale that have already cleared or been paid out are not reduced, and the reversal never touches other sales or takes your balance below zero.

### Legacy unlock purchases

A full refund of a legacy unlock payment deducts your net amount for that purchase from your balance. A partial refund deducts your share of the refunded amount. For a purchase still awaiting your claim, the pending earning is reduced or cancelled instead.

## Chargebacks and Disputes

Per-run sales are paid from the buyer's wallet or a run bundle, so there is no card payment for a single run. A refund or dispute of a wallet top-up or bundle payment takes back the buyer's credit or unused bundle runs and does not change your earnings from runs already made.

When a legacy unlock payment is disputed, the purchase is marked disputed. If the dispute is lost, your net amount for that purchase is deducted from your balance, which can go below zero if it was already paid out. If the dispute is won, the purchase returns to paid. Broader reserved legal rights are described only in the [Creator Terms](/docs/creator-terms) and [Chargeback Policy](/docs/chargeback-policy).

Chargebacks may also trigger fraud review, payout delay, account restriction, or future balance adjustments.

## Platform Errors and Reconciliation

Edgaze may correct records to address duplicate payments, delayed payment notifications, Stripe reconciliation issues, calculation errors, missing account information, fraud, abuse, or legal requirements.

## Creator Responsibilities

Creators should monitor sales, refunds, dispute rates, payout onboarding status, and pricing. High refund or dispute rates may lead to review, holds, reduced visibility, or suspension.

## Related Policies

- [Marketplace Fees](/docs/marketplace-fees)
- [Payout System](/docs/payout-system)
- [Refund Policy](/docs/refund-policy)
- [Chargeback Policy](/docs/chargeback-policy)


---

---
title: Payout System
description: How Stripe Connect onboarding, the 7-day clearing, held-until-onboard balances, weekly payouts above $25, and refund clawbacks work.
source: https://www.edgaze.ai/docs/payout-system
last_updated: 2026-10-14
section: legal
---
# Payout System

> How Stripe Connect onboarding, the 7-day clearing, held-until-onboard balances, weekly payouts above $25, and refund clawbacks work.

## Overview

Edgaze supports a "sell now, onboard later" model where creators may publish and sell before completing payout onboarding. Earnings from successful per-run sales accrue at **80% of creator margin**. Payout release still requires Stripe Connect onboarding, verification, and eligibility.

Read [Creator Earnings Guide](/docs/billing/creator-earnings-guide) and [Creator Earnings](/docs/creator-earnings) for how earnings are recorded and paid out.

## Stripe Connect

Stripe Connect is used for creator onboarding, verification, connected account status, and payout rails. Stripe may require identity, tax, bank, country, sanctions, and compliance information.

Edgaze may use Stripe account status, payout readiness, details submitted, restrictions, and live account verification to determine whether creator funds can be routed or released.

## Earnings Lifecycle

Each successful run sale moves through:

**pending, then 7-day clearing, then available, then payout**

### Pending (clearing)

When a buyer's run settles successfully, your margin share is recorded immediately as **pending**. Pending earnings clear automatically after a **7-day clearing period**, which covers the window in which a payment can still be refunded or disputed.

### Available

Once a sale has cleared the 7-day window, its amount becomes **available**, eligible to be paid out on the next weekly payout run, subject to onboarding and the minimum payout threshold below.

### Payout

Available balances are paid out on a **weekly payout run**. A payout is sent when your available balance is at least the **$25 minimum**. If your available balance is below $25, it carries forward and is paid on a later run once it reaches the threshold.

## Held Until Onboarding

You can earn before connecting a Stripe account. Earnings still accrue and still clear from pending to available on the normal 7-day schedule, but they are **held** and cannot be paid out until you complete Stripe Connect onboarding.

Held balances are durable: they stay on your account, are never lost, and are never forfeited. When you finish onboarding and your connected account is payout-ready, your accumulated available balance is released and paid on the next weekly payout run.

After 90 days from your first sale, if payouts are not ready and your held balance is at least the $25 floor, unpaid listings pause until onboarding is complete. The pause stops new paid sales. It does not cancel earnings.

In short, "no connected account" means "hold reliably, release on onboard," not "forfeit earnings."

## Refunds and Clawback

Refunds of runs are handled by Edgaze support. Buyers ask support, and each request is reviewed case by case under the [Refund Policy](/docs/refund-policy). A run is never refunded automatically.

- **Per-run sales:** when support approves a refund for a run, your still-pending earnings from that sale are reversed. Earnings from that sale that have already cleared or been paid out are not reduced.
- **Legacy unlock purchases:** a full refund or a lost dispute of the Stripe payment deducts your net amount for that purchase from your balance. A partial refund deducts your share of the refunded amount. For a purchase still awaiting your claim, the pending earning is reduced or cancelled instead.

The [Creator Terms](/docs/creator-terms) and [Chargeback Policy](/docs/chargeback-policy) govern any other adjustment.

## Available and Paid Status

When payout setup is complete and a sale has cleared, Edgaze marks the amount available. It is then paid out on the next weekly run via a Stripe Connect transfer to your connected account.

Edgaze protects payout processing against duplicate transfers.

Edgaze records payout events for display and accounting, but Stripe performs the actual movement of funds to your bank.

## Holds and Reviews

Ordinary refund adjustments are applied to matching pending earnings. The [Creator Terms](/docs/creator-terms) and [Chargeback Policy](/docs/chargeback-policy) explain the rights that may apply in exceptional cases.

## No Stored Value Account

Creator balances shown in Edgaze are dashboard and accounting records. They are not a deposit account, bank account, stored value facility, wallet, or money transmission account provided by Edgaze.

## Creator Responsibilities

Creators should complete payout onboarding promptly, keep Stripe information accurate, monitor disputes, avoid misleading products, and maintain compliance with Edgaze and Stripe policies.

## Related Policies

- [Creator Terms](/docs/creator-terms)
- [Creator Earnings](/docs/creator-earnings)
- [Marketplace Fees](/docs/marketplace-fees)
- [Billing guides](/docs/billing)
- [Chargeback Policy](/docs/chargeback-policy)


---

---
title: Refund Policy
description: How Edgaze reviews refund requests case by case and how to contact support.
source: https://www.edgaze.ai/docs/refund-policy
last_updated: 2026-10-14
section: legal
---
# Refund Policy

> How Edgaze reviews refund requests case by case and how to contact support.

## Overview

Edgaze provides hosted digital product experiences funded by wallet top-ups, bundles, marketplace purchases, and per-run charges. All refund requests are reviewed case by case. No purchase type is automatically eligible for a refund.

To request a review, email `support@edgaze.ai` from the email address associated with your Edgaze account. Include the relevant transaction or run details and a brief explanation of the issue.

## General Rule

Because digital access and run execution may be delivered immediately, submitting a request does not guarantee a refund. Edgaze determines eligibility and the refund amount after reviewing the individual circumstances and applicable law.

Reviews may consider the product listing, payment and account history, whether access or execution was delivered, information supplied by the customer or creator, and Edgaze's records.

## Wallet Refund Requests

### How to request a review

Email `support@edgaze.ai` from the email address associated with your account. Include the top-up date, amount, and reason for the request. There is no customer refund API or automatic approval process.

### Wallet refund terms

Support reviews wallet usage and the original payment before deciding whether a refund is appropriate. If a refund is approved, support will confirm the amount and method.

## Per-Run and Bundle Refunds

### Completed runs

There is no self-service refund for a completed run. Requests involving completed runs are reviewed case by case through support. Run refunds are issued by Edgaze support, not automatically. When support refunds a run, the creator's earnings from that sale are reversed if they are still pending.

### Failed runs

Ordinary failed runs are not charged and do not consume bundle runs, so a refund request is normally unnecessary. Read [When Runs Fail](/docs/billing/when-runs-fail).

### Unused bundle runs

Locked bundles expire after 2 years. Unused bundle runs are not automatically refunded, but you may ask support to review your circumstances. Read [Bundles Expiry and Refunds](/docs/billing/bundles-expiry-refunds).

## When Refunds May Be Considered

Edgaze may consider refunds when:

- The product materially does not match the listing.
- Access was not delivered after successful payment.
- A hosted workflow cannot execute because of a platform or product defect.
- Duplicate payment or platform error occurred.
- A refund is required by law, processor rules, or Edgaze policy.

Customer dissatisfaction alone does not guarantee a refund if the product was accurately described and access or the run was delivered as described.

## Marketplace Unlock Refunds

Marketplace purchases are reviewed through the same support process. If a refund is approved, access associated with the purchase may be revoked. For legacy unlock purchases, a full refund marks the purchase refunded and reverses the creator's earnings from that sale; if the creator's net amount had already been added to their available balance, it is deducted.

## Effect of Refunds

If a refund is approved, Edgaze may return funds through the original payment method, adjust account balances, revoke or change product access, and adjust related creator earnings as permitted by the applicable terms.

### Refunded top-ups and bundles

When a wallet top-up is refunded, the refunded amount is removed from your wallet. If you already spent that credit, your wallet balance can go negative, and new runs are blocked until a later top-up covers the difference. When a bundle is refunded, its unused runs are revoked (for a partial refund, a matching number of unused runs). Runs you already used, and runs in progress, are not affected.

## Creator Responsibilities

Creators must describe products accurately, avoid misleading claims, and maintain reasonable quality. Excessive refunds may trigger product review, payout holds, visibility restrictions, or account enforcement.

## Chargebacks

Customers should contact Edgaze before filing a chargeback. Chargebacks are handled under the [Chargeback Policy](/docs/chargeback-policy) and may result in account review.

## Related Policies

- [Refunds](/docs/billing/refunds)
- [Chargeback Policy](/docs/chargeback-policy)
- [Creator Earnings](/docs/creator-earnings)
- [Payments Overview](/docs/payments-overview)


---

---
title: Chargeback Policy
description: How Edgaze handles card disputes, Stripe dispute records, purchase status changes, and creator earning reversals.
source: https://www.edgaze.ai/docs/chargeback-policy
last_updated: 2026-10-14
section: legal
---
# Chargeback Policy

> How Edgaze handles card disputes, Stripe dispute records, purchase status changes, and creator earning reversals.

## Overview

A chargeback or dispute occurs when a customer challenges a payment through a bank, card issuer, or payment network. Stripe coordinates the dispute process for Edgaze payments.

## What a Chargeback Is

A chargeback or dispute occurs when a customer challenges a payment through a bank, card issuer, or payment network. Stripe coordinates the dispute process for Edgaze payments.

## Contact Support First

Customers should contact `support@edgaze.ai` before filing a chargeback. Many access, quality, duplicate payment, or technical issues can be resolved through support or refund review.

### Abusive chargebacks

Abusive or repeated chargebacks may result in account suspension, purchase restrictions, or fraud review.

## Stripe Dispute Process

### How Edgaze handles disputes

When Stripe notifies Edgaze of a dispute, Edgaze may mark the purchase disputed, preserve access and execution records, collect evidence, communicate with the Creator or Customer, and submit evidence through Stripe where appropriate.

### Evidence Edgaze may use

Evidence may include purchase records, product listing text, access records, execution logs, run timestamps, support messages, refund history, and account activity.

## Effect on Customers

### Disputed top-ups and bundles

When a wallet top-up is disputed, the disputed amount is removed from your wallet. If you already spent that credit, your wallet balance can go negative, and new runs are blocked until a later top-up covers the difference. When a bundle is disputed, its unused runs are revoked. If Edgaze wins the dispute and the original payment stands, the reversed wallet amount or bundle runs are restored.

## Effect on Creators

### Earnings reversals

Disputes can delay or reverse Creator earnings. If a dispute is lost, Edgaze may mark the purchase refunded and mark related Creator earnings refunded or cancelled. If the Creator net amount was previously added to available balance, Edgaze may deduct it or apply a future adjustment. For legacy unlock purchases, a lost dispute reverses the Creator's earnings from that sale and deducts the net amount if it was already in the Creator's available balance.

### Elevated dispute rates

Creators with elevated dispute rates may face payout holds, product review, delisting, account restrictions, or termination.

## Fraudulent or Abusive Disputes

Edgaze may contest disputes that appear fraudulent, abusive, duplicative, or inconsistent with access records. Edgaze may also restrict accounts involved in suspicious purchasing, refund, or dispute patterns.

## Relationship to Refunds

Refund requests are handled under the [Refund Policy](/docs/refund-policy). A chargeback is not a faster support path and may create additional payment processor consequences.

## Related Policies

- [Refund Policy](/docs/refund-policy)
- [Creator Earnings](/docs/creator-earnings)
- [Fraud and Abuse Policy](/docs/fraud-abuse-policy)


---

---
title: Pricing Limits
description: Minimum and maximum per-run workflow margin on Edgaze, and the weekly Workflow Studio usage allowance.
source: https://www.edgaze.ai/docs/pricing-limits
last_updated: 2026-10-15
section: legal
---
# Pricing Limits

> Minimum and maximum per-run workflow margin on Edgaze, and the weekly Workflow Studio usage allowance.

## Overview

**Audience: Creators publishing a paid workflow.**

Creators set product prices within platform-enforced limits. Pricing limits reduce spam listings, avoid extreme marketplace pricing, improve customer trust, and keep the hosted AI product marketplace legible.

Workflow per-run listings use a **creator margin** range; buyer displayed price adds compute estimated at the input envelope maximum. Read [Publish and Price](/docs/billing/publish-and-price) and the [Billing guides](/docs/billing).

## Current Price Ranges

| Product Type      | What is limited        |                          Minimum |                          Maximum |
| ----------------- | ---------------------- | -------------------------------: | -------------------------------: |
| Workflow products | Per-run creator margin | $0.05 | $50.00 |

Prices are currently set in USD.

## Workflow Products

Workflow **creator margin** must be between **$0.05** and **$50.00** per run. The buyer's displayed per-run price equals margin plus applicable hosted compute estimated at the input-envelope maximum. Only the creator-set margin is subject to this range.

Prompt Studio creation is retired. Existing prompt listings and purchases remain supported under [Legacy and retired features](/docs/legacy).

Edgaze may show infrastructure cost estimates as pricing guidance during publish. Estimates do not automatically raise the enforced margin minimum and are not deducted from creator earnings.

## Workflow Studio Test Runs

**Audience: Anyone building in Workflow Studio.**

Test runs in Workflow Studio draw on one usage allowance per account per week. It is measured by what each run actually costs to run (models and compute), shown as a percentage, and it is the same for Free and Plus accounts for now.

- **Weekly, no rollover.** The allowance resets every Monday at 00:00 UTC. Unused usage does not carry over, and a run that crosses the reset counts toward the week it started in.
- **Set aside before the run starts.** Each run sets aside its estimate with headroom, never more than 30% of the week, so the rest of the week stays usable. When the run finishes, only what it actually used is counted and the rest comes back.
- **Each run has an execution budget.** The amount set aside is the run's budget. A run that needs more stops with "Stopped: execution budget reached", keeps what it finished, and counts only that. Run it again to give it a fresh budget.
- **Partly failed runs** count the steps that completed. Steps on your own keys (Edgaze Plus, **Use my API keys**) count their compute only.
- **When the allowance runs out**, test runs stop unless you turn on **Use wallet funds** in Settings → Usage. A wallet-paid test run pays its compute price with no margin, the money is set aside before it starts, and you confirm the first one each week.
- Up to 6 test runs can be in progress on one account at a time.

Settings → Usage shows the week's usage, when it resets and about how many more runs of a typical workflow fit. Workflow Studio shows the same as a small ring next to **Run**.

## Why Limits Exist

Pricing limits reduce spam listings, avoid extreme marketplace pricing, improve customer trust, and keep the hosted AI product marketplace legible.

## Changes

Edgaze may change pricing limits for future listings, future purchases, categories, creator tiers, or special programs. Existing products may be grandfathered, required to update, or restricted depending on the change.

## Related Policies

- [Marketplace Fees](/docs/marketplace-fees)
- [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation)
- [What You Pay For](/docs/billing/what-you-pay-for)
- [Creator Terms](/docs/creator-terms)


---

---
title: Creator Terms
description: The terms that apply to creators who publish or monetize workflows, prompt products, templates, listings, and hosted product experiences on Edgaze.
source: https://www.edgaze.ai/docs/creator-terms
last_updated: 2026-10-14
section: legal
---
# Creator Terms

> The terms that apply to creators who publish or monetize workflows, prompt products, templates, listings, and hosted product experiences on Edgaze.

## Scope

### When these terms apply

These Creator Terms apply when you build, upload, list, publish, sell, or monetize Products on Edgaze. They supplement the [Terms of Service](/docs/terms-of-service).

### Independent creator relationship

Creators are independent publishers and sellers of their Products. Edgaze provides platform infrastructure, hosted runtime, marketplace discovery, checkout coordination, creator dashboards, and payout tooling.

## Creator Responsibilities

You are responsible for your Product claims, pricing, descriptions, category choices, assets, support expectations, workflow behavior, prompt content, examples, demos, screenshots, legality, and quality.

You must not mislead customers about what a Product does, what results it can produce, what credentials it requires, what third-party services it uses, what limitations apply, or whether outcomes are guaranteed.

## Rights and Ownership

You must own or have sufficient rights to all prompts, workflow logic, examples, templates, text, screenshots, thumbnails, branding, code, files, data, and other assets you publish.

You must not upload confidential information, third-party trade secrets, copyrighted works, trademarks, likenesses, datasets, or proprietary materials unless you have authorization.

## Product Claims and Quality

### Accurate listings

Listings must be materially accurate. Do not claim guaranteed income, guaranteed legal outcomes, guaranteed medical results, guaranteed compliance, guaranteed model performance, or guaranteed business results.

### Dependency disclosure

If a Product depends on external APIs, paid providers, user-supplied keys, model availability, file formats, manual setup, or limitations, you should disclose those dependencies clearly.

## Marketplace Relationship

### No guaranteed outcomes

Publication on Edgaze does not guarantee distribution, ranking, featuring, sales, traffic, reviews, customer demand, income, payout timing, or continued listing.

### No agency relationship

Edgaze is not your employer, agent, partner, broker, legal representative, tax advisor, financial advisor, fiduciary, or professional services provider.

## Fees and Creator Share

### Default split

Unless a separate written agreement applies, a successful current per-run workflow earns the Creator 80% of the creator margin, rounded down to the nearest microdollar ($0.000001). The Edgaze platform share is the remainder of that margin. Hosted compute is included separately in the buyer's displayed price and is not part of the Creator share. Legacy one-time purchases retain the split recorded at checkout.

### Earnings display

The creator dashboard shows the earnings amount associated with each eligible sale. A separate written agreement may set different commercial terms.

### Infrastructure estimates

Infrastructure cost estimates shown at publish time are pricing guidance. They are not a separate automatic deduction from Creator earnings.

## Stripe Connect and Payout Eligibility

### Onboarding and payout release

Stripe and Stripe Connect provide payment processing, onboarding, verification, and payout rails. You may be able to publish and sell before completing payout onboarding, but payout release depends on Stripe Connect onboarding, verification, eligibility, sanctions checks, fraud review, and platform controls.

### Pending-claim earnings

If a buyer purchases before you have completed payout onboarding, Edgaze may record the Creator share as pending-claim earnings. Edgaze holds eligible proceeds until you complete setup and transfers them after onboarding is complete. Held earnings are never forfeited because of time.

### Listing pause after 90 days

You may sell before completing payout onboarding. After 90 days from your first sale, if your Stripe Connect account is not payout-ready and your held balance is at least the payout floor, Edgaze may pause your paid listings so new paid sales stop. Demos, free listings, and already-purchased access remain available. Completing payout onboarding releases the hold and resumes paid listings. The pause applies to listings only. It does not cancel, expire, or forfeit accrued Creator earnings.

### Balances are not bank accounts

Payout eligibility is not the same as visible earnings. Creator balances are records used for platform accounting and dashboard display; they are not a bank account, deposit account, stored value account, or money transmission account provided by Edgaze.

## Holds, Reversals, and Adjustments

### When Edgaze may adjust earnings

Edgaze may hold, reverse, delay, cancel, or adjust Creator earnings for refunds, partial refunds, chargebacks, disputes, fraud, abuse, policy violations, duplicate payments, processor restrictions, legal requests, sanctions issues, platform errors, reconciliation issues, or suspected manipulation.

### Post-payout reversals

If a sale is refunded or a dispute is lost, related Creator earnings may be marked refunded, cancelled, reduced, or deducted from available balance. If a reversal occurs after payout, Edgaze may record an offset, debt, reserve, or future balance adjustment where permitted.

## Taxes

You are responsible for your own tax obligations arising from Creator activity. Stripe may collect tax or identity information where configured, and Stripe may provide tax reporting where applicable. Edgaze does not provide tax advice.

## Third-Party Services

Creators must comply with third-party provider terms, including AI model providers, external APIs, Stripe, and any services used by a workflow. You are responsible for costs, permissions, rate limits, safety rules, and user disclosures for third-party dependencies you choose.

## Enforcement and Termination

### Enforcement actions

Edgaze may unlist, restrict, demonetize, remove, suspend, or terminate Products or Creator accounts for policy violations, poor marketplace conduct, deceptive listings, IP issues, security risk, payment abuse, abnormal refund or dispute rates, illegal content, unsafe workflows, or legal compliance.

### Effects of termination

Termination may result in loss of publishing access, removal of Products, loss of dashboard access, cancellation or reversal of pending earnings, continued retention of records for accounting/legal/security purposes, and continued customer access or revocation decisions as Edgaze determines appropriate.

## Indemnification

You agree to indemnify Edge Platforms, Inc. for claims arising from your Products, Creator Content, listings, claims, assets, workflow behavior, customer promises, third-party API usage, rights violations, tax obligations, payment disputes, or breach of these Creator Terms.

## Related Policies

Read these together:

- [Marketplace Fees](/docs/marketplace-fees)
- [Creator Earnings](/docs/creator-earnings)
- [Payout System](/docs/payout-system)
- [Refund Policy](/docs/refund-policy)
- [Chargeback Policy](/docs/chargeback-policy)
- [Creator Guidelines](/docs/creator-guidelines)

## Contact

For creator policy questions, contact `support@edgaze.ai`.


---

---
title: Creator Guidelines
description: A concise checklist for honest, safe, useful Edgaze marketplace listings.
source: https://www.edgaze.ai/docs/creator-guidelines
last_updated: 2026-07-19
section: legal
---
# Creator Guidelines

**Audience: Creators publishing or maintaining marketplace listings.**

Use this checklist before publishing and whenever you update a listing. The [Creator Terms](/docs/creator-terms), [Terms of Service](/docs/terms-of-service), and [Acceptable Use Policy](/docs/acceptable-use-policy) remain binding.

## Describe the product honestly

- Make the title, description, thumbnail, examples, price, and claims match the product's actual behavior.
- Disclose required provider keys, Plus requirements, third-party accounts, supported file types, limits, and meaningful failure modes before the buyer runs it.
- Do not promise guaranteed results, income, compliance, or model accuracy.

## Publish something usable

- Test the complete buyer path and keep required integrations working.
- Do not publish empty wrappers, misleading prompt fragments, copied listings, spam, or products whose main purpose is redirecting buyers elsewhere.
- Use demos and examples that represent normal output, not exceptional results presented as typical.

## Protect rights, privacy, and safety

- Publish only content, branding, data, prompts, workflow logic, and assets you own or may use.
- Do not impersonate a person or organization or imply an affiliation you do not have.
- Do not collect credentials, facilitate phishing or malware, expose personal data, evade safeguards, enable unlawful surveillance, or violate third-party terms.
- Follow the [DMCA and IP Takedown Policy](/docs/dmca) and [Community Guidelines](/docs/community-guidelines).

## Maintain and support the listing

- Monitor broken provider integrations, buyer reports, refund signals, and misleading or outdated claims.
- Repair or unpublish a listing that can no longer deliver its stated outcome.
- Send support and appeal questions to [support@edgaze.ai](mailto:support@edgaze.ai).

## Enforcement

Edgaze may reject, unlist, restrict, demonetize, or remove listings and accounts that violate platform rules or undermine marketplace trust. Serious issues may be acted on without a warning. Available reporting and appeal paths are described in the applicable safety or legal policy.


---

---
title: Workflow Run Policy
description: Per-run hosted workflow execution, BYOK behavior, funding sources, and abnormal usage controls.
source: https://www.edgaze.ai/docs/workflow-run-policy
last_updated: 2026-10-14
section: legal
---
# Workflow Run Policy

> Per-run hosted workflow execution, BYOK behavior, funding sources, and abnormal usage controls.

## Overview

Workflow runs use Edgaze orchestration. Each successful run settles at its displayed price. Buyers fund current runs from a wallet or a matching workflow bundle; the app and API are trigger channels, not separate funding sources.

This policy covers execution rules, BYOK behavior, and abuse controls. For funding, pricing, failure billing, and refunds, read the [Billing guides](/docs/billing).

## Hosted Runs

### What counts as a run

A hosted run is a workflow execution through Edgaze runtime infrastructure or orchestration. A run may include multiple nodes, prompts, model calls, tool calls, file operations, API calls, retries, validations, and output generation steps.

### Per-run charging

Each successful hosted run charges the buyer's chosen funding source at the **pinned displayed price** for the workflow version being run. There is no included-run quota bundled with per-run purchases. Demo and builder test runs are always free.

### Input envelope

Workflows define a maximum input spec (size, pages, tokens, or equivalent). Inputs above the envelope are rejected at trigger before any charge or reservation. Within the envelope, the displayed price is fixed.

## When a Run Counts for Billing

### Successful runs

A run counts as a billable success when it completes successfully. You are charged the displayed price; the creator earns 80% of margin.

### Failed, cancelled, or compute-limit-stopped runs

Ordinary failed and cancelled runs are not charged and do not pay creator earnings. A run stopped at the compute limit may retain already-consumed compute while the margin charge is released. Read [When Runs Fail](/docs/billing/when-runs-fail).

### Validation or access failures

Validation or access failures that prevent execution from starting do not produce successful hosted runs. Edgaze may still record attempted, failed, or diagnostic events for security, debugging, or abuse prevention.

## BYOK Mode

### When BYOK applies

Plus subscribers may save provider keys in API Vault. Non-hosted runs charge creator margin plus $0.002 for Edgaze orchestration. The external provider bills the owner of the connected key.

### Provider responsibility

Edgaze handles orchestration but does not control third-party provider charges, availability, or policy decisions in BYOK mode. Read [BYOK](/docs/billing/byok).

## Queueing

When Edgaze is at capacity, a run may wait in line before it starts. Plus runs get priority in the line. A waiting run that cannot start within its wait limit, or that you cancel while it waits, ends without a charge, and any funds or bundle runs reserved for it are released.

## Provider Dependencies

Hosted runs and BYOK runs may depend on model providers such as OpenAI, Anthropic, Google, and Microsoft Azure where configured, on integrations and data services used by workflow steps, as well as external APIs selected by creators or users. Provider errors, rate limits, safety systems, policy changes, or outages may affect execution.

## Abnormal Usage

Edgaze may limit, block, rate-limit, suspend, or require BYOK for abnormal, abusive, high-cost, fraudulent, automated, or security-sensitive usage patterns.

## Changes to Run Policy

Edgaze may change run policy, funding rules, accepted input limits, or abuse controls prospectively. Existing bundle balances and wallet entries remain subject to the terms in effect at purchase unless policy enforcement, fraud, abuse, or legal requirements require otherwise.

## Related Policies

- [Run a Workflow](/docs/billing/run-a-workflow)
- [Funding Runs](/docs/billing/funding-runs)
- [What You Pay For](/docs/billing/what-you-pay-for)
- [Terms of Service](/docs/terms-of-service)
- [Platform Status and Beta Disclaimer](/docs/platform-status-beta-disclaimer)


---

---
title: Infrastructure Cost Estimation
description: How the hosted compute estimate affects the price buyers see, without reducing creator margin earnings.
source: https://www.edgaze.ai/docs/infrastructure-cost-estimation
last_updated: 2026-07-19
section: legal
---
# Infrastructure Cost Estimation

> How the hosted compute estimate affects the price buyers see, without reducing creator margin earnings.

## Overview

During publishing, Edgaze estimates hosted compute for the largest input the workflow accepts. That amount contributes to the fixed price shown to a buyer before a run. It is not deducted from creator margin earnings.

Read [Publish and Price](/docs/billing/publish-and-price) for how the estimate combines with creator margin.

## What the Estimate Is

### Estimate for the largest accepted input

During publishing, Edgaze analyzes the workflow graph and the creator's maximum input spec (file size, pages, tokens, or equivalent). The estimate reflects likely model, API, compute, and orchestration cost at that **maximum allowed input**, not at every possible smaller input.

### Buyer price

**Displayed price = creator margin + applicable hosted compute.** Within the accepted input limit, the buyer sees one fixed price.

### BYOK adjustment

For a non-hosted provider-key mode, hosted compute is replaced by $0.002 for Edgaze orchestration. The external provider bills the connected key owner. Read [BYOK](/docs/billing/byok).

## What the Estimate Is Not

The infrastructure estimate is not:

- A second platform fee on creator margin.
- An automatic deduction from creator earnings (creators earn 80% of margin only).
- A Stripe fee.
- A guarantee of actual runtime cost on every input size within the envelope.
- A guarantee that a workflow will remain profitable at a selected margin.

## Relationship to Marketplace Fees

The standard marketplace fee is 20% of creator margin, not a share of hosted compute. The estimate explains the buyer price; it does not reduce creator earnings.

## Why Estimates Matter

### Hosted workflow economics

AI workflows can involve multiple model calls, image generation, embeddings, tool calls, and third-party APIs. The estimate makes the buyer price visible before publication.

### Pricing decisions

Creators should set margin based on product value, likely demand, refund risk, and support burden. Hosted compute is priced separately.

## Changes and Accuracy

Estimates may change when provider pricing, model routing, retry behavior, workflow structure, failover policy, usage patterns, or platform infrastructure change. Edgaze may update estimation logic without changing what you were charged for past runs.

## Related Policies

- [Marketplace Fees](/docs/marketplace-fees)
- [Pricing Limits](/docs/pricing-limits)
- [Publish and Price](/docs/billing/publish-and-price)
- [Creator Terms](/docs/creator-terms)


---

---
title: Model Catalog & Pricing
description: The AI models Edgaze workflows can call, current hosted pricing, and how model availability changes are handled.
source: https://www.edgaze.ai/docs/model-catalog-pricing
last_updated: 2026-09-02
section: legal
---
# Model Catalog & Pricing

> The AI models Edgaze workflows can call, current hosted pricing, and how model availability changes are handled.

## Overview

Every LLM block in an Edgaze workflow (LLM Chat, LLM Image, Embeddings, AI Conditions) runs against a curated model catalog. This page lists the current catalog, the hosted platform rate for each model, and explains what happens to workflows that reference older models.

Provider prices and capabilities can change. Confirm the current publish preview before relying on an estimate.

For how per-run estimates are produced, read [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation). For how estimates combine with creator margin, read [Marketplace Fees](/docs/marketplace-fees).

## Chat Models

```docmodels
{"modality":"chat"}
```

## Image Models

```docmodels
{"modality":"image"}
```

OpenAI image rates vary with size and quality settings; the estimator prices the configured variant.

## Embedding Models

```docmodels
{"modality":"embedding"}
```

## Bring Your Own Key (BYOK)

BYOK runs call the provider directly on **your** API key. OpenAI-brand, Anthropic, and Google models support this, and the token cost lands on your provider account instead of the rates above (a flat orchestration fee applies; see [BYOK](/docs/billing/byok)). Kimi K2.6 and DeepSeek V4 Pro run exclusively on Edgaze's managed capacity and do not support BYOK.

## Automatic Model Migration

Providers retire models on their own schedules, and the Edgaze catalog evolves with them. You never need to hand-edit old workflows:

- **Selectable models** appear in the builder dropdown and are fully supported.
- **Deprecated models** disappear from the dropdown but keep running and billing at their listed rate. Existing workflows are unaffected.
- **Retired models** may be replaced with a supported successor. The current model and price are shown in Workflow Studio before publication.

## Reliability

When failover is enabled, Edgaze may use an eligible alternative after a transient provider problem. Failover does not raise the displayed price shown before the run.

## Questions

Contact [support@edgaze.ai](mailto:support@edgaze.ai) for pricing questions, or see [Pricing & Limits](/docs/pricing-limits) for account-level limits.


---

---
title: Creator Subscription Policy
description: The live Edgaze Plus price, entitlements, billing, cancellation, and relationship to marketplace rules.
source: https://www.edgaze.ai/docs/creator-subscription-policy
last_updated: 2026-07-19
section: legal
---
# Creator Subscription Policy

> The live Edgaze Plus price, entitlements, billing, cancellation, and relationship to marketplace rules.

## Overview

**Audience: Buyers and creators considering or using Edgaze Plus.**

Edgaze Plus costs **$20/month**. An active subscription unlocks the same features enforced by the product: Composer usage, Bring your own API keys, Private workflows, Unlisted sharing, Remix controls, Priority queue, Model failover control.

Creator subscriptions do not change per-run margin split rules, wallet or bundle funding, or payout eligibility requirements.

## Billing

Billing is handled through Stripe. Renewal timing, cancellation, taxes, receipts, and payment failures are governed by the checkout terms and applicable Edgaze policies.

## Benefits

The live Plus entitlements are: Composer usage, Bring your own API keys, Private workflows, Unlisted sharing, Remix controls, Priority queue, Model failover control. Features stop being available when the subscription is no longer active; existing purchase and payout records are not rewritten.

### BYOK (code-backed)

Plus subscribers may configure provider API keys in API Vault. BYOK runs charge creator margin plus a **$0.002 orchestration fee** per run instead of hosted provider compute. The provider bills the credential owner. Read [BYOK](/docs/billing/byok).

### What subscriptions do not include

Creator subscriptions do **not** grant included hosted run quotas, alternate marketplace fee splits, or exemption from per-run billing on paid workflow listings. Workflow runs are funded per run via wallet, bundle, or API under the standard billing model.

## Cancellation and Changes

Edgaze may add, remove, change, or discontinue subscription benefits. Cancellation may affect future access to subscription-only features, but does not automatically rewrite past purchase records unless the product terms say so.

## Relationship to Creator Terms

Creator subscriptions do not override the [Creator Terms](/docs/creator-terms), [Marketplace Fees](/docs/marketplace-fees), [Workflow Run Policy](/docs/workflow-run-policy), or payout eligibility requirements.

## Refunds

Subscription refund requests are reviewed under the [Refund Policy](/docs/refund-policy) and the checkout terms shown at purchase.

## Related Policies

- [BYOK](/docs/billing/byok)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [Billing guides](/docs/billing)


---

---
title: Community Guidelines
description: User-facing standards for profiles, marketplace listings, comments, and buyer-creator interactions on Edgaze.
source: https://www.edgaze.ai/docs/community-guidelines
last_updated: 2026-10-14
section: legal
---
# Community Guidelines

> User-facing standards for profiles, marketplace listings, comments, and buyer-creator interactions on Edgaze.

## Overview

These Guidelines cover the interaction surfaces currently available on Edgaze: public profiles, marketplace listings, listing comments, reviews and creator replies, likes, reports, and buyer-creator support interactions. The [Acceptable Use Policy](/docs/acceptable-use-policy) contains the broader prohibited-use rules.

## Marketplace Trust

Users must act honestly. Do not impersonate people or brands, manipulate engagement, fabricate testimonials, mislead buyers, spam comments, or attack competitors.

## Profiles and Public Identity

Handles, names, bios, avatars, and creator profiles must not mislead users about identity, affiliation, credentials, ownership, endorsements, or professional status.

## Comments, Reviews, and Likes

### Genuine experience

Comments and reviews about a listing should be based on genuine experience and stay relevant to the product. Likes should reflect genuine interest, not coordinated or automated engagement.

### Prohibited conduct

Do not post harassment, threats, hate, spam, off-topic promotion, doxxing, false accusations, extortion, or review manipulation.

Constructive criticism is allowed. Abuse is not.

## Buyer and Creator Conduct

### Customers

Customers should read listings carefully, use Products responsibly, contact support for payment issues, and avoid abusive refund or chargeback behavior.

### Creators

Creators should describe Products accurately, disclose limitations, avoid guaranteed outcome claims, and respond to legitimate marketplace issues in good faith.

## Safety and Respect

Do not use Edgaze interactions to harass, threaten, intimidate, shame, exploit, discriminate, sexually exploit, or target other people.

## Enforcement

Edgaze may remove content, restrict comments, reviews, or likes, suspend accounts, hide profiles, unlist Products, or take payment-related action when community conduct threatens users or marketplace trust.

## Reporting

Report community issues to `support@edgaze.ai`.

## Related Policies

- [Acceptable Use Policy](/docs/acceptable-use-policy)
- [Fraud and Abuse Policy](/docs/fraud-abuse-policy)
- [Creator Guidelines](/docs/creator-guidelines)


---

---
title: Fraud and Abuse Policy
description: How Edgaze detects, reviews, and responds to payment abuse, marketplace manipulation, unsafe workflows, and platform misuse.
source: https://www.edgaze.ai/docs/fraud-abuse-policy
last_updated: 2026-10-14
section: legal
---
# Fraud and Abuse Policy

> How Edgaze detects, reviews, and responds to payment abuse, marketplace manipulation, unsafe workflows, and platform misuse.

## Overview

Edgaze protects customers, creators, payment integrity, and hosted workflow infrastructure from fraud and abuse.

This policy works with the [Acceptable Use Policy](/docs/acceptable-use-policy), [Chargeback Policy](/docs/chargeback-policy), and [Creator Terms](/docs/creator-terms).

## Review Signals

Edgaze may review activity involving unusual purchase patterns, excessive refunds, excessive chargebacks, misleading listings, fake accounts, suspicious payout behavior, identity issues, suspicious API usage, abnormal hosted run usage, marketplace manipulation, credential abuse, or policy reports.

## Actions Edgaze May Take

Edgaze may block purchases, delay checkout, restrict runs, require BYOK, hold or reverse earnings, delay payouts, unlist Products, suspend accounts, preserve records, request information, report activity to providers, or cooperate with Stripe, law enforcement, regulators, or affected third parties.

## Payment Abuse

Refund abuse, chargeback abuse, card testing, stolen payment credentials, self-purchasing schemes, payout manipulation, fake sales, collusive purchases, and attempts to route illicit funds are prohibited.

## Creator Abuse

Creators must not publish deceptive Products, manipulate reviews, copy or repackage others' work, promise guaranteed outcomes, hide material limitations, misrepresent provider costs, or sell Products designed to violate law or third-party terms.

## Customer Abuse

Customers must not buy Products for misuse, scrape or redistribute paid access, submit prohibited inputs, share unauthorized access, evade run limits, abuse BYOK systems, or use chargebacks as a substitute for support.

## Restrictions

Enforcement may restrict an account temporarily or permanently. A restriction can cover posting comments and reviews, liking, publishing or updating listings, running workflows, purchases and wallet top-ups, and creating or using API keys.

## Appeals

To appeal, email `support@edgaze.ai` from the address on your account with the restriction message, relevant transaction or listing IDs, what you believe was incorrect, and any supporting records. Support will acknowledge the request and route it for review. An appeal does not guarantee restoration, especially where fraud, legal risk, processor restrictions, or safety concerns are confirmed.

## Related Policies

- [Acceptable Use Policy](/docs/acceptable-use-policy)
- [Chargeback Policy](/docs/chargeback-policy)
- [Creator Terms](/docs/creator-terms)


---

---
title: DMCA and IP Takedown Policy
description: Procedure for reporting copyright infringement, counter-notices, repeat infringers, and non-copyright intellectual property issues on Edgaze.
source: https://www.edgaze.ai/docs/dmca
last_updated: 2026-05-13
section: legal
---
# DMCA and IP Takedown Policy

> Procedure for reporting copyright infringement, counter-notices, repeat infringers, and non-copyright intellectual property issues on Edgaze.

## Overview

This policy explains how Edge Platforms, Inc. reviews copyright and intellectual property reports involving Edgaze listings, workflows, prompt products, profiles, assets, examples, screenshots, metadata, and other user-generated materials.

Edgaze is a platform and hosting provider for creator-published AI products. Creators are responsible for ensuring they have rights to the materials they publish.

## Purpose and Scope

### What this policy covers

This policy applies to copyright notices, counter-notices, repeat-infringer review, and non-copyright intellectual property reports involving Edgaze-hosted materials.

### Creator responsibility

Creators are responsible for ensuring they have rights to the materials they publish on Edgaze.

## Copyright Notices

### Required notice contents

If you believe content on Edgaze infringes your copyright, send a written notice containing:

- Your physical or electronic signature.
- Identification of the copyrighted work claimed to be infringed.
- Identification of the allegedly infringing material and enough information for Edgaze to locate it, such as URL, creator handle, Edgaze code, listing title, or screenshots.
- Your name, address, telephone number, and email address.
- A statement that you have a good-faith belief that use of the material is not authorized by the copyright owner, its agent, or the law.
- A statement that the information in the notice is accurate.
- A statement, under penalty of perjury, that you are the copyright owner or authorized to act for the copyright owner.

### Where to send notices

Send to support@edgaze.ai.

## Review and Action

### How Edgaze may respond

When Edgaze receives a facially valid notice, it may remove or disable access to the material, notify the affected user, request more information, preserve records, suspend publishing privileges, or take other action appropriate to the report.

### Incomplete or abusive notices

Incomplete, inaccurate, abusive, or legally insufficient notices may not be processed.

## Counter-Notices

### Required counter-notice contents

If your content was removed because of a copyright notice and you believe removal was mistaken or authorized, you may submit a counter-notice containing:

- Your physical or electronic signature.
- Identification of the material removed or disabled and where it appeared before removal.
- A statement under penalty of perjury that you have a good-faith belief the material was removed or disabled because of mistake or misidentification.
- Your name, address, telephone number, and email address.
- A statement that you consent to jurisdiction of the federal district court for your address, or if outside the United States, any judicial district where Edge Platforms, Inc. may be found.
- A statement that you will accept service of process from the person who submitted the original notice or that person's agent.

### Restoration process

Edgaze may forward your counter-notice to the original claimant. If the claimant does not notify Edgaze of a filed court action within the legally required period, Edgaze may restore the material where appropriate.

## Repeat Infringers

Edgaze may terminate or restrict accounts of users who repeatedly infringe copyrights or repeatedly submit infringing Products. Repeat infringement may be assessed based on valid notices, court orders, admissions, repeat removals, patterns of conduct, or other evidence.

## Trademarks and Other IP

### Non-copyright reports

Trademark, trade dress, publicity rights, trade secret, counterfeit, and other non-copyright IP reports may be reviewed outside the DMCA process. Include enough detail to identify your rights, the allegedly infringing material, and why the use is unauthorized or misleading.

### Marketplace confusion and impersonation

Edgaze may remove or restrict material that creates marketplace confusion, impersonates another brand, misuses logos, misrepresents affiliation, or violates creator obligations.

## Misrepresentation and Abuse

Submitting false, abusive, or misleading notices or counter-notices may expose you to liability and may result in account or platform restrictions.

## Contact

For intellectual property inquiries, contact `support@edgaze.ai`.

## Related Policies

- [Terms of Service](/docs/terms-of-service)
- [Acceptable Use Policy](/docs/acceptable-use-policy)
- [Creator Terms](/docs/creator-terms)


---

---
title: Security and Responsible Disclosure
description: How to report Edgaze security issues and the boundaries for good-faith vulnerability reporting.
source: https://www.edgaze.ai/docs/security-responsible-disclosure
last_updated: 2026-10-14
section: legal
---
# Security and Responsible Disclosure

> How to report Edgaze security issues and the boundaries for good-faith vulnerability reporting.

## Overview

This policy explains how to report security issues affecting Edgaze and the boundaries for good-faith vulnerability research.

It does not authorize unapproved testing, scanning, or access to accounts or data without permission.

## Reporting Security Issues

### What to include

If you believe you have found a vulnerability affecting Edgaze, report it privately through the [vulnerability report form](/security/report) or by email to `security@edgaze.ai`. Include a clear description, affected URL or feature, steps to reproduce, impact, screenshots or logs where useful, and your contact information.

## Good-Faith Research

Good-faith reporting means you:

- Avoid accessing, modifying, deleting, or exfiltrating data that is not yours.
- Avoid disrupting service, degrading performance, or triggering excessive automated traffic.
- Stop testing once you have enough information to demonstrate the issue.
- Keep the issue confidential while Edgaze investigates.
- Do not use the issue for fraud, extortion, competitive harm, spam, account takeover, or data extraction.

## No Authorization for Unapproved Testing

### Prohibited testing

This policy does not authorize penetration testing, automated scanning, social engineering, physical attacks, denial-of-service testing, credential attacks, rate-limit bypassing, payment abuse, or access to accounts/data without permission.

### Policy and legal limits

Testing that violates law, the [Acceptable Use Policy](/docs/acceptable-use-policy), or third-party terms is not authorized by this policy.

## Scope

### In-scope surfaces

Reports may relate to Edgaze web surfaces, APIs, auth flows, checkout flows, creator dashboards, hosted workflow execution, public docs, or platform-controlled infrastructure.

### Third-party services

Third-party services such as Stripe, Supabase, Vercel, Microsoft Azure, Cloudflare, OpenAI, Anthropic, Google, GitHub, Slack, and external APIs have their own security programs and should be reported through their channels unless the issue is specifically in Edgaze's integration.

## No Bounty Unless Announced

Edgaze does not currently offer a public bug bounty, reward, compensation, swag, or guaranteed acknowledgment unless separately announced in writing.

## What Edgaze May Do

Edgaze may investigate, request more information, prioritize, remediate, decline, disclose, or take protective action. Reports do not create an obligation to fix within a specific timeline.

## Contact

Security reports: [vulnerability report form](/security/report) or `security@edgaze.ai`

General support: `support@edgaze.ai`

## Related Policies

- [Acceptable Use Policy](/docs/acceptable-use-policy)
- [Privacy Policy](/docs/privacy-policy)
- [Terms of Service](/docs/terms-of-service)


---

---
title: Changelog
description: What changed on Edgaze, written for the people who use it.
source: https://www.edgaze.ai/docs/changelog
last_updated: 2026-10-18
section: resources
---
# Changelog

> What changed on Edgaze, written for the people who use it.

**Audience: Buyers and creators using Edgaze.**

What shipped, by day, written for people who run workflows, build them, or sell them. Days with nothing worth showing are left out.

Jump by month: [October 2026](#october-2026) · [September 2026](#september-2026) · [August 2026](#august-2026) · [July 2026](#july-2026) · [June 2026](#june-2026) · [May 2026](#may-2026) · [April 2026](#april-2026) · [March 2026](#march-2026) · [February 2026](#february-2026) · [January 2026](#january-2026) · [December 2025](#december-2025) · [November 2025](#november-2025) · [September 2025](#september-2025) · [August 2025](#august-2025) · [July 2025](#july-2025)

## October 2026

### October 18, 2026

- The docs have an **Ask** button next to search. It opens Composer in a read-only mode that searches and reads the documentation, streams its answer as it writes, shows which pages it looked at, and links the page each answer comes from. It cannot touch your workflows. Docs questions share your Composer allowance at a reduced rate, with a small daily limit, and signed-out visitors get a few free questions a day.

### October 15, 2026

- Paid runs always use the model the creator chose. Your first runs of a workflow were quietly switched to a cheaper model, and from the 11th run you could be asked for your own API keys even though you were paying. Both are fixed.
- Plus members can turn on **Use my API keys** in the run panel. Steps on OpenAI, Anthropic or Google models then run on the keys saved in your API Vault, and their model cost comes off the price, which the panel shows before you run. Steps on models only Edgaze hosts, like DeepSeek and Kimi, stay on Edgaze and stay in the price, and the creator's price still applies.
- If a provider rejects one of your keys, that step stops with a clear message instead of quietly running on Edgaze. Runs on your own keys are paid from your wallet, and your bundle runs are kept for hosted runs.
- AI steps in Workflow Studio no longer have their own API key or Edgaze-hosted switch. Every step is Edgaze-hosted, and your own keys are a single choice for the whole run.
- A run where some steps fail but the rest still produce your results now says "Completed with issues", in amber, and lists the steps that didn't finish. It used to say the run failed.
- You pay only for the compute of the steps that finished on a run that completes with issues, never more than the compute shown before the run, and no creator price. A bundle run is not used up, and a free demo that completes with issues does not use up your demo.
- The email and notification for a run that waited in line say "finished with issues" when some steps didn't finish.
- The API, webhooks and MCP report how a completed run went: `outcome` is `completed`, or `completed_with_issues` when some steps failed.
- A run waiting in line now reads `pending` in the API and `queued` in MCP until it starts. It used to say `running` while it waited.
- Live run pages and API streams stay connected on long runs. A stream hands over to a fresh connection about every 5 minutes without losing anything (the API sends `event: reconnect` with the last event id), and the run page keeps following a long run instead of giving up after 45 minutes.
- When support refunds a run, a run paid with a bundle goes back to your bundle, a run that used remixed workflows is refunded in full, and a run started with an API key no longer counts against that key's spend limit.
- Analytics events sent without identifying you no longer carry an empty user ID or the location of Edgaze's servers.
- The Privacy Policy names Webshare, the proxy provider used to fetch YouTube transcripts and web pages that block our servers.
- Workflow Studio test runs now use a weekly usage allowance instead of 10 free runs per workflow. It is measured by what each run actually costs, shown as a percentage, resets every Monday at 00:00 UTC and does not roll over. Test runs use the model each step is set to.
- Each test run gets an execution budget from its estimate before it starts, and never takes more than 30% of the week. A run that needs more stops with "Stopped: execution budget reached", keeps what it finished and counts only that.
- Settings has a new Usage section: this week's Workflow Studio usage and when it resets, your Composer usage, and **Use wallet funds** to keep testing from your wallet once the allowance runs out (compute price only, confirmed once a week).
- Workflow Studio shows a small usage ring next to **Run**, with this workflow's runs left this week, and asks before a run only when it can't start on the allowance or would be the week's first wallet-paid run.

### October 14, 2026

- Edgaze has a light theme. It follows your device's light or dark setting by default and switches with it, or you can pick Light or Dark yourself.
- Change the theme from the sun and moon button in the site header, the app sidebar, Workflow Studio, the docs and the blog, or choose System, Light or Dark in the footer and in Settings → Appearance.
- Switching themes fades the new one in from where you clicked, and your choice is remembered on this device.
- Checkout, payout setup and the security check match the theme you are using.
- "Connect your accounts" links from MCP and the API now open Connected accounts in settings. They pointed at a page that does not exist.
- The Wait block's example workflows wait as long as they say: 5 minutes, 2 seconds and 1 hour. They were finishing almost at once.
- When an API run needs a connected account, the `409` response lists the accounts to connect in `error.details`.
- Listing runs through the API no longer returns the inner runs of a workflow used inside another workflow. The other run endpoints already hid them.
- The API, billing, builder and MCP docs were checked against the product and corrected, including the full list of API errors, how cancelling a run works, and what happens to your funds while a run waits in line.
- Run bundles keep working after the creator publishes a new version. Your runs use the version you bought until the bundle runs out, the run panel says so, and you can still pick the newer version and pay for it from your wallet.
- An API key's spend cap now counts the creator's price as well as compute, so a run that would take a key over its cap no longer starts.
- Cookie choices have a new Marketing setting. Google Ads loads only if you allow it, and ad click IDs are kept only with that consent. Because this is a new choice, you will see the cookie banner once more.
- Server-side product analytics are linked to your account only when you have allowed analytics. Otherwise they are sent without anything that identifies you.
- The restricted-account page lists what a restriction covers and how to appeal through support@edgaze.ai.
- The Privacy Policy, Cookie Policy, Terms and the other policies were updated to name every service we use, where data is processed, and how refunds, disputes and waiting runs work.

### October 13, 2026

- On iPhone, the action receipt in the Gateway section fits inside its label again.

### October 12, 2026

- When Edgaze is at full capacity, your run waits in line instead of failing, and starts on its own as soon as there is room. The run page shows your place in line and an estimated wait, and you can close it.
- Signed in, we email you when a run that waited is done. On a demo, leave your email on the waiting screen and we send you the result.
- Plus runs go first in line and have capacity kept for them, and the waiting screen shows they are in the Plus priority line. Every run moves up the longer it waits, so nobody waits forever.
- A run that cannot start in time is released, and you are not charged.
- The API reports a waiting run as `pending` with its place in line (`queue`), and MCP shows it too.
- Runs are more reliable during brief outages: a start that could not reach the engine now waits and retries instead of failing.
- Edgaze MCP is listed in the official MCP registry as `ai.edgaze/edgaze`.
- Agent apps can tell which Edgaze tools only read, like search and inspect, and which one starts a run, so they know when to ask you first.
- The approval screen for agent apps checks who is asking. An app that only claims to be Claude, ChatGPT or Cursor is marked Unverified, and the screen names the site your approval sends access to.
- When an agent connects to MCP with an API key, paid runs respect that key's permissions and spend limit.
- Banned accounts are blocked everywhere, including the API, MCP, publishing, Composer, checkout and reviews.
- Reports unlist a listing only after three different accounts, none of them brand new, have reported it.

### October 9, 2026

- Runs have a new live view. Instead of a step log, you see what the workflow is doing in plain words, like "Writing your launch note", the text as it is written, and a progress bar.
- Results open with a headline that names what is ready, how long it took and what it cost, and one set of controls: Copy or Download, Run again, and a menu with raw data, full screen, Share and Open in Runs. With several outputs, you switch between them at the top.
- Run pages fill the screen while live and when finished, and work at phone width.
- Creators decide what customers see for each step in its settings, under What customers see: edit the activity line, and choose whether a model step shows its writing live.
- A workflow's steps stay with its creator. Buyers starting a run receive only the questions they answer, and runs through the API or MCP show stages instead of the workflow's steps to anyone but the creator.
- In agent apps that support it, an MCP run plays live in the chat, with a link to the run page when the app blocks the view.
- New run shows the same cards as the marketplace, with search that also finds unlisted workflows, and more loads as you scroll. Picking one shows its live price and a link to its product page before you continue.
- The Runs page groups runs under Today, Yesterday, Previous 7 days and Earlier, and shows a charge only when there is one.
- The product page's run card is simpler. Remix, API and a new MCP button sit in one row, and the wallet card appears only when you have funds or runs to spend.
- The MCP sheet asks which assistant you use and shows the exact setup steps for it. Windsurf is now Devin Desktop, and the steps for Cursor, Claude, ChatGPT and the rest match each app's current setup.
- Result images appear whole once loaded instead of painting top to bottom, and a failed run puts its reason in the middle of the screen.
- The version picker only shows when a workflow has more than one version, and version numbers count from the first version.

### October 8, 2026

- Product pages and demos fill in their example inputs again. Some forms showed up empty, and "Generating example inputs" could spin forever. It now always stops.
- Signed-in buyers and creators keep the example inputs when their version of the workflow loads. A field counts as yours only once you type in it.

### October 5, 2026

- Cancelling a run always finishes. A run cancelled just as it was wrapping up could sit on "Cancelling…" indefinitely.
- A run you cancel while it is still starting no longer goes on to run anyway.
- A cancelled run with nothing to show gets its own screen with how many steps finished and Run again. It used to say the workflow ran successfully with no outputs.
- A workflow's steps and prompts can only be read by its creator, and buyers no longer receive the step-by-step detail of their runs. Creators still see their own prompts and workflows in their library.
- Runs move between steps faster, now that the engine that runs them sits in the same region as Edgaze's database.

### October 4, 2026

- Runs start much faster. The first step begins a second or two after you click Run, where paid runs used to take 12 to 17 seconds.
- Results appear the moment they are final. Paid runs used to show as running for about 7 seconds after the last step while billing finished.
- Long runs show their results. A run with a very long log could say "This workflow did not produce any outputs" even though it had finished.
- Runs that finished but were still marked as running are now corrected automatically.
- The compare and use-case pages show each entry as a card, and the page header no longer covers the first logo.

## September 2026

### September 29, 2026

- Listings have reviews. Rate a workflow from 1 to 5 stars once you have run it successfully, or a prompt you bought, and creators can reply in public. Reviews are marked Verified run or Verified purchase, and you can report one.
- Run via API on a product page has a Try it tab. Run the workflow with your API key and see the result without writing code. A paid run first shows your wallet, what is left after the run, and the key's spend limit, and asks you to confirm.
- Comments on listings are now called Questions & discussion.
- When a demo needs a security check, it opens over the page instead of replacing the run panel.
- API keys you give a run are used only while a step runs and are deleted when the run ends. They are no longer saved with the run.

### September 26, 2026

- Public pages on phones no longer get stuck when you scroll past the footer.

### September 24, 2026

- File upload fields take a paste. Press ⌘V or Ctrl+V anywhere on the run form, or tap Paste on a phone. With several upload fields, the file goes to the one you picked or the only empty one, and otherwise you choose.
- Paste text into an upload field and you can attach it as a file. Name it `main.py` or `notes.md` so the model knows what it is reading.
- A file question can take several files. Turn on Allow multiple files in the block settings and set a limit of up to 10.
- Image blocks that edit an uploaded photo follow their prompt again. The photo's details were replacing the prompt, so edits came back unchanged or unrelated.
- When Gemini declines to make an image, the error now says why.
- GPT-6 Sol and GPT-6 Luna are in the model catalog. GPT-6 Sol is the new default and costs less than the GPT-5.6 models it replaces, and GPT-6 Luna is the lowest-cost option.
- GPT-5.6 Sol and GPT-5.6 Terra have left the catalog. Workflows that use them now run on GPT-6 Sol automatically, with no edits needed.
- Claude Opus 5.5 replaces Opus 5 at a lower price. Workflows set to Opus 5 or an older Opus move to Opus 5.5 automatically.
- GPT-5.6 Luna has left the catalog too. GPT-6 Luna is newer and cheaper, so workflows that use GPT-5.6 Luna now run on GPT-6 Luna automatically, with no edits needed.
- Very long prompts on GPT-6 models bill at the model's long-context rate. When a prompt passes 272K input tokens, the run's estimate and charge use that rate, so the shown estimate matches the real cost of a long run.

### September 23, 2026

- Signed out, each section of the developer console (workflows, API keys, webhooks, usage) now explains what it is for and offers a Sign in button, instead of sending you to a separate sign-in page.
- Signing in from the developer console or the docs opens a sign-in window, so you stay on the page you were reading.

### September 19, 2026

- Some older purchased workflows that stopped running after an earlier update work again.
- If you bought a workflow without pinning a version, you can run the active version again.
- Demo runs work again.
- Landing illustrations no longer cover the docs link on phones.

### September 18, 2026

- Workflows can act in your connected apps. New blocks for GitHub, Slack, Gmail, Google Drive, Google Docs, Google Calendar, and Google Sheets cover the actions people actually automate, like filing an issue, posting to a channel, or appending to a doc.
- Connect an account once from Connected accounts in settings. Each run asks you to approve exactly what it may do before it starts, the person running picks the repository or channel, and disconnecting takes effect immediately. Creators never see anyone's sign-in.
- If a connection expires mid-run, the run pauses so you can reconnect, then resumes where it left off instead of failing.
- When a connected app rejects something, you see the app's own reason and which step failed.
- Aviato is the first integration that needs no account at all. Edgaze covers it, lookups are part of the run's price, and previewing is free.
- Composer can now build on its own. It drafts and edits a workflow end to end, pauses to ask your approval before a step that writes to a connected app, and picks up the same run when you answer.
- Studio has guided block insertion. Every output port and edge has an insert button that opens a picker filtered to blocks that fit, condition branches are labeled, and clicking the canvas places a block where you clicked.
- Remix is a block. Pick a published workflow from the picker and it drops into your graph as a node with the parent's thumbnail.
- A new Repeat block runs a step a set number of times, with control over how many run at once and whether one failure stops the rest.
- A reload no longer eats unsaved work. Drafts come back after a crash and are protected while saving.
- Test runs in Studio use your real connected accounts. If you have not connected what a step needs, the run pauses so you can connect and resume.
- Runs keep going through deploys and come back from crashes. Cancelling a run now stops it mid-step instead of letting it run to the end.
- Publishing a workflow is all-or-nothing, so a failure cannot leave a half-saved listing. The version you bought keeps running at the price you paid.
- Webhooks retry a failed delivery for up to about nine hours instead of dropping it, a dead endpoint pauses itself instead of being retried forever, and delivery status shows in the developer console.
- GPT-6 Astra is in the model catalog, and Claude models with tight capacity are flagged in the picker.
- Web scrape is harder to beat. A bot-blocked page retries once through a different route, crawl delays are respected, and a page that only renders with JavaScript is no longer mistaken for real content.
- New [Gateway](/gateway) page explains how connected apps work, and the homepage has a Gateway section.
- New pages compare Edgaze with Zapier, n8n, Make, Gumloop, and Apify, and walk through setups for agents, the workflow API, MCP, and long-running workflows.
- Navigation was reworked: a four-section menu, a real drawer on phones, and a cleaner footer.
- Released as **v1.3.6**.

### September 16, 2026

- The privacy policy spells out how Google user data is handled when you connect a Google account.

### September 2, 2026

- Branded Open Graph cards.
- Product demo prefill experience.
- Ranked marketplace search results.
- Public billing and API documentation.

## August 2026

### August 30, 2026

- Durable delay units and seven-day limits.

### August 29, 2026

- Publish documentation platform post.
- Publish durable runs post.
- Publish mobile workflow creation post.
- Publish Workflow Studio rebuild post.
- Publish model resilience post.
- Publish runnable AI demo post.
- Blog reading and navigation experience.

### August 28, 2026

- Quiet mega-menu hover icons and link the whole prefill disclaimer.
- Guest drafts in the first-workflow tutorial.
- Guest drafts in Workflow Studio.
- Keep docs sitelinks crawlable while showing Docs and API.
- Drop the docs home sitelink chip row.
- Signed-in library previews on the hub.
- Preview created and purchased library collections.
- Preview a library item without leaving the hub.
- Highlight purchased library cards from a hash.
- Highlight created library cards from a hash.
- Highlight a library card from its item hash.
- Scroll a library card into view from its hash.
- Let guests build, save locally, and continue after sign-in in Studio.
- Label local drafts on the mobile builder clutter.
- Keep inspector vault and shared secrets behind sign-in.
- Let guests start and continue a local workflow from the launcher.
- Adopt a local guest workflow draft after sign-in.
- Hand compatible authenticated flow runs back for the same idempotency key.
- Ask Composer guests to sign in when a turn requires it.
- Rate-limit guest Composer with fingerprint and hashed IP caps.
- Keep an explicit return-to when opening sign-in.
- Send email confirmation back to the original destination.
- Prefer the tab-local return path after OAuth.

### August 25, 2026

- You can sign in with GitHub from the regular sign-in screen, checkout, onboarding, creator and invite claims, applications, and agent consent. Edgaze also shows which sign-in method you last used on this device.
- Form-based workflows keep their questions on the product page, so buyers see the fields a creator configured before they run.
- A Web scrape field can turn a product or site name such as `stripe` into the page to read. If you paste several links with notes, it uses the first real URL.
- Creator payouts are now available in Bangladesh.
- Marketplace rows stay full and stable while sections refresh, instead of leaving gaps or moving the wrong listing between rails.
- About, Brand, Help, Pricing, and Docs now share the same clear sitelinks and public navigation, making important pages easier to find from search and around the site.
- The developer console has clearer empty states and quieter controls for API keys, usage, and webhooks.
- Creators can sell before finishing payout setup. If setup is still incomplete 90 days after the first sale, paid listings pause until onboarding is finished; held earnings are not forfeited.
- The Invest page is easier to scan, with more room for the deck and less boxed chrome.

### August 24, 2026

- Edgaze MCP is linked from the footer, and its agent setup control stays readable and copyable on narrow screens.
- Developers can pin the public OpenAPI definition from [edgaze-ai/edgaze-openapi](https://github.com/edgaze-ai/edgaze-openapi). It updates automatically when the API on `main` changes.

### August 23, 2026

- The pricing page footer spans the full width instead of sitting inside the last section column.
- New and Noteworthy on the marketplace fills a full row instead of leaving one stray card after For You and Featured.
- Creator analytics and conversions use fresh listing metrics instead of stale counts.

### August 22, 2026

- Run-everywhere animations on the homepage keep moving on phones instead of freezing.

### August 17, 2026

- Creators can mark a workflow input as required in Studio. The toggle is off by default.
- Gemini 3.7 Flash and Flash-Lite are in the model picker with prices that match Google.
- Run estimates for Claude Sonnet 5 match Anthropic's current list price.
- Claude Opus 5 is in the model catalog. Workflows that still pointed at Opus 4.8 remap automatically.
- The Azure mark stays secondary in the model inspector so the model name stays easy to read.
- Azure-hosted models show as Hosted on Azure with the Azure mark, not Foundry.

### August 16, 2026

- Creators have one earnings dashboard for available earnings, Stripe balances, weekly bank deposits, recent sales, and performance by workflow.
- If Stripe still needs payout details, the dashboard says what is missing and opens payout setup without sending you away from the page.
- If you have not joined the creator program yet, Earnings starts with that step and opens the dashboard when you are ready.
- Workflow publish failures include a short error ID, so support can trace the exact problem without exposing private details.

### August 15, 2026

- Ask an agent for something ordinary, like an image or a short brief, and search can find the matching marketplace workflow from everyday language. You do not have to know the listing code.
- The price your agent sees in search is the price you are charged. It is not an old snapshot from when the listing was first published.
- When a run returns an image, a video, or a file, the agent gets a link to the hosted run page so you can open the real result. Plain text still comes back in the chat.
- Press and media assets live on [/brand](/brand). You can download marks, wordmarks, and color tokens. Old `/press` links redirect there.
- This changelog is now a dated public log, and new days are drafted from what ships on main.

### August 14, 2026

- Your agent can run a marketplace workflow from Cursor, Claude, ChatGPT, Codex, VS Code, Windsurf, OpenCode, and similar apps. It can search the catalog, read the form and the live price, start a demo or a paid run, and bring the result back.
- Connect at `https://mcp.edgaze.ai`. Sign in on `https://www.edgaze.ai`. The REST API stays on `https://api.edgaze.ai`.
- Let the app open sign-in. Do not go looking for a consent page yourself. A bare consent link has no sign-in request, so it will not work.
- Settings now has Connected apps. You can see which agents have access and disconnect one.
- What you sell through an agent is the same published listing people run on the site. There is no second graph and no second price.
- The homepage and [MCP docs](/docs/mcp/connect) have a prompt you can paste so an agent can set itself up.
- A zero wallet after install is normal. Top up at [Your wallet](/wallet) before a paid run. Start with [Your first run](/docs/mcp/first-run).

### August 13, 2026

- Product pages open faster. Coming back does not flash the wrong layout while we check whether you still have a demo.
- Comments and the run box wait until you scroll near them, so the first paint stays on the product. A link from email still opens the comment.
- Public products show up in search and in the sitemap. Private, empty, or noindex listings do not get advertised.
- The homepage headline is readable while the rest of the page finishes loading.

### August 12, 2026

- The listed run price matches what we charge, including rounding. Catalog copy now says when a listed price is an estimate and when the live quote is what you pay.
- Cancelled means cancelled on the product page, in your runs list, and in the API. A cancel is not shown as completed.
- Composer tells you what phase it is in and asks before it edits your workflow. Approvals show up in the chat instead of applying a patch silently.
- Profile and settings open faster from the account menu on a phone. The menu no longer dumps you back to a blank state.

### August 11, 2026

- The homepage shows real outcomes: an image, a chart, a document, a list. It looks like a product demo, not a feature grid.
- The run panel on that block matches the product-page demo. The button goes to the marketplace so you can run a real workflow.

### August 10, 2026

- Marketplace search understands Edgaze codes like `@handle/product`, so you can jump to a listing from the code on a card or a profile.
- Results line up better with what you typed, including titles, handles, and codes in the same query.

### August 9, 2026

- Share a product with a QR code or by copying the link. Both go to the same public listing.
- Live activity only shows public runs. Private or unpublished work stays off the feed.
- If a web scrape fails, you see the failure. A Success-only graph no longer paints a failed scrape as if it worked.
- There is a first-workflow tutorial with a short video for each step, from the first block to a run you can publish.
- A failed run no longer leaves money sitting on your balance. The hold goes back to your wallet.
- The cookie banner is smaller and waits until the mascot is ready, so it does not cover the first thing you came to do.

### August 6, 2026

- Homepage run limits are easy to see before you start a demo, so you know how many tries you have left.
- A scrape or file error does not use up your demo. Only a real completed demo counts.
- For You shows two full rows of listings on every screen size, instead of a short strip that looked empty.
- Every docs page asks if it helped. The vote is anonymous. We use it to fix pages people bounce off.

### August 2, 2026

- New Web scrape block: paste a URL and get the article. It works on GitHub, Wikipedia, YouTube, Reddit, and similar sites, and it fails in the open when a page cannot be read.
- You can upload PDFs, Word files, and zips. The workflow can read them when the model supports that kind of file.
- The homepage has demos you can actually run, not just screenshots of a builder.
- Failed runs explain what went wrong in plain language, including scrape and document errors.
- Listings that had no price now show one, so you can see the charge before you run.

## July 2026

### July 31, 2026

- You can search docs from the docs header. Results go to the heading, not just the page.
- The status page is clearer when a check is out of date, so you can tell a real incident from a stale canary.
- Retrying an API run keeps the same workflow version you started with. You do not silently jump to a newer publish.
- New builder tutorial: a company-intelligence workflow, from inputs to a finished brief. See [Company intelligence](/docs/builder/tutorial-company-intelligence).
- API docs cover versions and how to move a purchase to a newer one.

### July 30, 2026

- A paused run stays paused. Refreshing the page or reconnecting the stream does not restart it.
- Webhooks are not sent again if the first delivery fails. That retry rule is now in the API docs, so you can write your receiver against it.

### July 29, 2026

- You can cancel an API run you started, from the run detail or the list, if you have write access.
- Paid prompt text does not show up in marketplace feeds, trending, or homepage cards. You still see the full text on a product you own or bought.
- Two people cannot spend the same prepaid run at the same time. Runs already going count toward your free-run and max-run limits.
- Banned accounts cannot check out. The block is on the payment path, not only on the product page.
- You can only remix a public, published workflow. Drafts and private graphs are not remix sources.
- New guides: [free demos](/docs/free-demos), [managed execution](/docs/managed-execution), and [sell everywhere](/docs/sell-everywhere).
- New homepage. The latest blog post is in the nav.

### July 26, 2026

- The API reference is public and matches the live API. The OpenAPI document is served without a key.
- If an input is wrong, create-run tells you which field failed, not only that the request was invalid.
- You can see versions on a workflow you bought and move that purchase to a newer publish.
- An API key can be given `workflow:write` when you want it to accept those updates. New keys keep that permission off until you turn it on.
- The developer console has the same version and accept-update actions as the API.

### July 25, 2026

- Loops are simpler. A list goes in, a result comes out, and the inside of the loop has its own editor. You no longer wire item and index ports by hand.
- Long prompts open full screen, so you can edit them without the inspector feeling cramped.
- Inside a loop, the block library only offers blocks that belong there.
- Workflow Studio is in the phone menu. Composer has a menu button too, so you can switch without losing the chat.
- Docs for loops match the new editor. See [Workflow Studio](/docs/builder/workflow-studio).

### July 23, 2026

- Older purchases that were bought once still work. In your library they show as Legacy, so you can tell them apart from per-run products.

### July 22, 2026

- The API checks required inputs before it charges you. A missing field fails cheaply.
- Chat blocks no longer send a temperature you never chose. If you leave it alone, the model uses its default.
- A bad connection between blocks is caught while you build, with the error pointed at the loop editor when that is where it lives.
- A rule you wrote stays a rule. It does not turn into an AI block on its own.
- Loop cards show when a loop will cost more, because each item is another run of the inside. The graph stays on screen on a phone.

### July 21, 2026

- Composer builds one path from Input to Output and will not ship a workflow with dead ends.
- Status is a short line in the chat. You open a diff when you want to see what changed.
- On a phone, you start in Composer. The full graph is still there if you need it.
- Kimi and DeepSeek keep their logos in the model picker. You can search for them by name.
- Closing the side panel clears the selection. Lines between blocks are easier to see on a dark canvas.
- Composer usage and Plus are in one place, so the monthly cap and the upgrade are not on two different screens.

### July 20, 2026

- API links on the site go to `https://api.edgaze.ai`. Docs examples use that host.
- Run via API on a product page is ready to copy, including the workflow id and a create-run body.
- If Composer names a block that is not on the canvas, it recovers instead of breaking the draft.
- Marketplace images no longer leave a blank hole while they load.
- Released as **v1.3.0**.

### July 19, 2026

- Docs is split into three paths: run a workflow, create and sell, or build with the API. Start at [Docs](/docs).
- Checking a run, watching it live, and getting a webhook all use the same statuses. If a stream drops, you can pick it up again from the last event.
- A listing says whose keys it uses: Edgaze-hosted, the creator's connected key, or a key you provide.
- Billing docs cover the price you see, what the creator earns, failed runs, run packs, and older purchases. Start at [What you pay for](/docs/billing/what-you-pay-for).
- New products start in Composer. Prompt products people already bought still work.
- The run button waits until your files have finished uploading, so you do not start a run on a half-sent PDF.

### July 18, 2026

- Model names, prices, and backups come from one catalog. Old model names still work on workflows that already use them.
- You do not paste a key for models Edgaze already hosts. Hosted rates are on the [model catalog](/docs/model-catalog-pricing).
- The model picker shows logos and a short note when you hover, including when a backup will take over.
- Photos shrink on your phone before they upload, and the size limit is written next to the picker.
- Created and Purchased in your library need you to be signed in. Those routes are not public lists.

### July 17, 2026

- Your library is two lists: [things you made](/library/created) and [things you bought](/library/purchased). The old mixed index is a hub that sends you to one of those.
- After you buy, you land on what you bought, not on a generic library dump.
- Cards use a 16:9 thumbnail and a price that matches the listing.

### July 16, 2026

- Password reset and confirm links work in any browser, including the one you did not start the request from.
- YouTube transcripts break less often when a video page changes shape.
- Your runs page is a history you can search. Opening another run does not start a second live stream.
- You see one price at charge time. We do not show the creator split on the receipt.
- Remix starts with a short explanation of what you are copying and what you will set yourself.

### July 15, 2026

- Text is easier to read on dark screens, including marketplace cards and the builder canvas.
- Listing cards no longer get cut off on a phone.
- Sign-up fits the screen and starts with the form, so you are not scrolling past a hero to type an email.
- A paid run on the product page waits until you actually have access. You cannot start a charge from a stale "you already own this" state.
- Run again asks you to confirm, so a second charge is intentional.

### July 14, 2026

- Double-tap a listing card to like it. You do not have to hit a small heart.
- If something is down, a banner can say so across the site, including the marketplace and the builder.

### July 13, 2026

- You can ask for a missing block from the library, so a gap in the palette is a request, not a dead end.
- The homepage carousel uses real marketplace workflows, not placeholder cards.
- New homepage, and a clearer creators page that includes how earnings work.

### July 12, 2026

- The developer console is workflows, keys, webhooks, and usage. Each screen asks you to sign in.
- `/developer` is the public page. The console waits until you have an account, so a shared link does not open someone else's keys.

### July 11, 2026

- Composer shows how much you have used this month. Plus updates as soon as you pay, without a refresh loop.
- Pack prices are easier to read. A top-up cannot be counted twice if you retry the same payment.
- Version history in the builder is more reliable when you publish twice in a row.
- Publish and checkout handle Plus and run packs in the same flow, so you are not sent to a second page to finish paying.

### July 10, 2026

- Plus limits how many runs you can have going at once. Pricing and wallet show the upgrade next to that limit.
- Wallet history uses workflow names, not only run ids.
- You can start a run from your runs list and share that run with a link.
- Form values fill into chat blocks, so a product-page field becomes the prompt the model sees.
- If a run fails, the money held for it goes back to your wallet. You do not file a ticket to unstick a hold.

### July 9, 2026

- The public API is at `api.edgaze.ai`. Keys, runs, and webhooks use that host.
- You cannot remix an older kind of purchase. Remix is for published per-run workflows.
- Publish is a short flow: price, backup model, preview, then sell.
- Profiles show remix counts and the founding badge, without extra chrome around them.

### July 8, 2026

- The API can list workflows. The developer console can too, with the same catalog fields.
- Creator earnings show on listings as the creator's cut, not as a token bill.
- The API reference is in docs, next to create-run and webhooks.

### July 7, 2026

- Docs starts with running something, then selling it. Billing pages have next and previous, so you can walk [what you pay for](/docs/billing/what-you-pay-for) without going back to the index.

### July 6, 2026

- A workflow inside another workflow connects in the builder and still connects when it runs. Nested inputs map through instead of dying at the inner Input block.
- A run that has already started keeps going through a deploy. You do not lose a live job because we shipped in the middle of it.

### July 5, 2026

- New listings charge per run. You see one price. Failed runs are free. The creator earns 80% of their margin. Hosted compute is not part of that cut.
- Creators set their cut at publish. Buyers do not see a token bill or a compute invoice.
- Inputs that are too large are stopped before anyone is charged.
- You can buy a pack of runs. The pack is used first, then your wallet.
- At checkout you can top up, buy a pack, or run now if you have enough.
- A remixed workflow has its own price. You cannot point two workflows at each other in a loop.
- If we have to use a more expensive model, your price stays the same. Creators can turn that backup off so the run fails instead.
- Plus with your own key: you pay a small orchestration fee plus the creator's cut. Your provider bill is yours.
- You run the version you bought, at that version's price, even if the creator published a more expensive one later.
- Run packs expire after two years. Refunds have a support path.
- Older purchases still work for the people who already bought them.

### July 4, 2026

- Blocks show a hint of their settings on the card, so you can scan a graph without opening every inspector.
- Marketplace images stay sharp without being huge files.
- Creators earn on their cut. Hosted compute is not creator income, and it is not shown as if it were.

### July 3, 2026

- The pricing page matches wallet billing and Plus, including the own-key path. What you read there is what checkout charges.

### July 2, 2026

- Public API: start and read runs, find workflows, create keys with spend limits, and get a signed ping when a run finishes.
- If you already have access, the product page has Run via API with a copy-ready request.
- Workflow Studio home and the marketplace live feed were redesigned so the first action is obvious.
- Comment links from email open the right thread, including on a listing that paginates comments.
- Form fields on a run stay in a stable order, so a saved share link fills the same boxes.
- A real failure is not retried as if the model just hiccuped. You see the error instead of a second charge.

### July 1, 2026

- Workflow Studio has a new home, templates, block library, and settings. You can start from a template or a blank graph.
- Remix is more reliable when the parent workflow has nested blocks.
- Live activity is more accurate about what actually finished, not what was still queued.

## June 2026

### June 30, 2026

- The runs list shows when something actually finished, including the time, not only that it left "running."
- Template search suggests as you type, so you can find a starter graph without scrolling the whole library.

### June 29, 2026

- Wallet page: balance, history, and top-up in one place. See [Your wallet](/wallet).
- A purchase locks the version you bought. Each publish is a new version you can name.
- If a newer version exists, you see a banner and can switch. Switching is explicit.
- Plus includes checkout, a billing portal, and your own keys.
- You can share a run at `/run/{id}`. The page shows the result without opening the builder.
- You can remix a published workflow in Studio and set your own price on the new listing.

### June 28, 2026

- The live run focuses on the block that is working. The log works on a phone, including scroll and wrap.
- Product page, builder, and API all start a run the same way, and they check access first. A missing purchase fails before the model is called.

### June 27, 2026

- A card payment shows up in your wallet as soon as Stripe confirms it.
- Creator payouts wait until bank setup is done. You can keep selling. You cannot cash out on an unfinished Connect account.
- The price we showed you is the price we charge, even if a provider's cost jumps during the run.

### June 26, 2026

- Settings is easier on a phone, including sign out, so you are not hunting for a desktop-only control.
- The pitch deck opens again.
- Cookie preferences in the footer are simpler. You can change analytics without re-reading the whole banner.

### June 25, 2026

- Demos, including image demos, fail less often when a model or a file host is slow.
- You can try Composer without an account. When the free tries run out, we ask you to sign in instead of failing the chat.

### June 24, 2026

- Set it yourself clears the filled-in demo inputs, so you can replace a suggestion without deleting field by field.
- A finished demo stays on the page. It does not disappear behind "demo used."
- Cookie banner and preferences. Analytics waits until you say yes.

### June 19, 2026

- The product page appears right away. Fields fill in one by one if we have a suggestion, instead of blocking the whole form on the first hint.

### June 18, 2026

- Demo inputs can be filled in for you from the listing's sample.
- The bot check stays hidden unless something looks off, so most people never see a challenge.
- Signed-in demos on paid workflows start without an error when you still have a demo left.
- Image results show as images, not as a raw URL you have to open.

### June 17, 2026

- After a demo is used, you see the gallery and Buy Access. The page does not look like you can run another free try.
- On a phone, the sticky button is Buy Access, not another demo.

### June 16, 2026

- The run box is on the left. The thumbnail sits under the creator, so the first thing you read is what the product does.
- Buy Access is the main button on a paid listing.

### June 15, 2026

- You can run a demo on the product page. No extra window, and no jump into the builder.
- You can look at a finished demo again, including the output you already generated.
- The marketplace is quicker on a phone, including cards and the live feed.

### June 11, 2026

- Hosted runs keep their images and files after the run ends, so a refresh does not lose the result.
- If Anthropic or Gemini is down, the run can finish on a backup when the listing allows it.
- Trying a run in the builder while signed in is a real run, not a guest demo. It uses your wallet or pack when the workflow is paid.
- Each signed-in account has a demo limit. It is per account, not per browser.

### June 10, 2026

- Hosted runs fail less often when a model stalls or a file host is slow. You see a real error if it still cannot finish.

### June 9, 2026

- If Anthropic is down, the run can continue on OpenAI. Image blocks get the same backup.
- YouTube transcripts fail less often when a video has captions in a format we already support.

### June 5, 2026

- Back from a listing remembers where you were in the marketplace, including on a phone and including the category you were in.
- A comment link from email opens the thread on that listing.

### June 3, 2026

- New creator onboarding, including Composer, from a first draft to something you can publish.
- The marketplace is better on a phone, including live activity that does not jump the layout.
- Released as **v1.2.6**.

### June 2, 2026

- Edgaze codes are easier to find on cards and profiles. Live activity is quieter, so a busy hour does not take over the page.
- You can set notification preferences, including what email you get after a run or a comment.
- How it works asks you to sign in when you need an account, instead of showing a dead action.

## May 2026

### May 29, 2026

- The [blog](/blogs) is live. Posts about Composer, the first workflow, and why workflows beat prompts start there.

### May 28, 2026

- Composer is steadier when it edits your workflow. A long chat is less likely to apply a half-finished change.

### May 26, 2026

- Product pages are back, with a calmer comments section that does not sit on top of the run box.
- Composer slows down if you send too much at once, instead of dropping the draft.
- Hints and the run window are less noisy. Status text is shorter. The window does not steal focus while you type.

### May 25, 2026

- Photos on listings, Composer chats, and saved API keys fail less often. A retry does not create a second key.

### May 23, 2026

- You can draft a workflow in chat with Composer. Describe the outcome, and it builds a graph you can open in Studio.

### May 17, 2026

- Listings have better photos, likes, and a simpler menu. The product page is thinner, so the run and the gallery are the first things you see.

### May 13, 2026

- Legal and trust pages were refreshed, including terms, privacy, and the pages that say what a run is allowed to do.
- Careers date pickers work on a phone, so an application does not require a desktop calendar.

### May 8, 2026

- You can apply for a role from one form while signed in. Attachments go with the application. You do not email a PDF separately.

## April 2026

### April 28, 2026

- Creator onboarding walks you from a first workflow to publish, including the black sign-in and the first Studio session.

### April 26, 2026

- Preview inputs are checked before a run starts. A missing required field fails on the form, not after the model is called.

### April 25, 2026

- Released as **v1.2.5**. Featured storefronts can ship new workflows without waiting on a platform release.

### April 24, 2026

- YouTube transcripts work again after a player change on YouTube's side.
- Link previews work when you paste a URL in social apps, including the image and the title.

### April 23, 2026

- gpt-image-2 is available in image blocks. Lowest workflow prices are simpler to set at publish.
- If the main image model times out, a backup can finish the picture when the listing allows it.

### April 22, 2026

- Creators get paid more reliably, including when a transfer has to retry.
- The earnings dashboard stays signed in while you move between balances and payouts.
- Demos are harder to game with a refresh or a second tab. The library scrolls on a phone.
- Run windows sit in the middle of the desktop and stop spinning forever when a run is already done.

### April 21, 2026

- Demos show whether they are available, even while you move between listings. You do not tap Run and then find out the demo is gone.
- Payout setup status matches what Stripe has, including the country and the next step they still need.

### April 20, 2026

- Public pages and publish are cleaner. The publish flow asks for less, in a stable order, and the marketing pages match the product you actually get.

### April 19, 2026

- Template library in Workflow Studio, with docs for how a template becomes a listing.
- Publishing from a phone is easier. The form fits the screen and the preview is the listing card, not a desktop-only canvas.

### April 18, 2026

- A listing that changed owners sends you to the new one. Old links do not 404.
- The phone top bar is back, including search and the account menu.

### April 17, 2026

- You can zoom the canvas. Trackpad and buttons both work.
- Image blocks have aspect ratios, so a 1:1 and a 16:9 output are a setting, not a prompt you hope the model honors.

### April 15, 2026

- Saved API keys work from the run box, including keys you added in settings.
- Listing photos upload when someone is helping you publish, so a co-publisher can finish the gallery.

### April 14, 2026

- Claiming a profile is less likely to collide with someone else on the same handle.
- Following counts can stay private.
- Released as **v1.2.4**.

### April 13, 2026

- Stripe Connect works in more countries, with a clearer setup and the country asked up front.
- Duplicate payout accounts are combined, so you do not see two balances for the same bank.
- A missing sample output no longer breaks the demo. The run still starts. The gallery just stays empty until there is a result.
- Earnings and Stripe balances stay in sync after a payout or a retry.

### April 12, 2026

- Trending has clearer rules about what can appear and how long it stays there.
- Password reset sends you back to the page you were on, not to a generic home.
- Connect setup asks for your country correctly, including when you change it mid-flow.

### April 11, 2026

- Product pages count views. Public listings are easier to find in search, including title and description.

### April 10, 2026

- Listing pages, sign-in, and link previews are more reliable. A slow image host no longer blanks the whole card.

### April 9, 2026

- What you get on a product page is clearer on a phone: gallery, run, and price, in that order.
- Removed listings leave the public profile. They do not linger as a dead card.

### April 8, 2026

- An old tab can reload the builder or marketplace without a white screen.
- Gemini blocks and downloads fail less often.
- Sign-in errors are in plain language, including a wrong password and a cancelled Google prompt.

### April 7, 2026

- Verified creators. A checked profile is visible on the listing and on the public page.
- Released as **v1.2.3**.

### April 6, 2026

- Link previews are real images, not broken icons, when you paste an Edgaze URL in chat or social apps.

### April 5, 2026

- Demos and the phone run window behave. A finished demo does not leave the window spinning.
- Link previews use the right image for the listing you shared.

### April 4, 2026

- The software license was revised. The public terms match how runs and listings actually work.
- A busy live run is less likely to freeze when several blocks finish at once.

### April 3, 2026

- Live runs recover more cleanly when a model fails. You get the error on the block that failed, and the rest of the graph does not look like it is still running.

### April 2, 2026

- The run window is faster and more stable. Opening a second run does not stall the first one.

### April 1, 2026

- The run people see is separate from the builder, with live updates. Sharing a run no longer opens Studio.
- New icons across the builder. Gemini is more reliable on long prompts.

## March 2026

### March 31, 2026

- Live runs stream faster. Tokens and images show up as they land, instead of waiting for the whole block.

### March 26, 2026

- Anthropic and Gemini blocks in the builder, next to the models Edgaze already hosted.
- PDFs open correctly in the run output, including multi-page files.
- Released as **v1.2.2**.

### March 25, 2026

- About page copy and layout are fixed.
- Link previews work again after a metadata miss on product URLs.

### March 24, 2026

- Prices on product pages match the listing. Preview images are the gallery you uploaded, not a leftover builder thumbnail.

### March 23, 2026

- Builder and run fixes from real use: graphs that would not save, runs that would not leave "starting," and a few blocks that ignored their own settings.

### March 16, 2026

- Search engines get a better map of the site, including marketplace and docs.
- Released as **v1.2.1**.

### March 15, 2026

- Creator program, payments, press, and About are public. You can read how selling works and where the company is.
- Creators build. Buyers run. That split is the product, not a side mode.
- Released as **v1.2.0**.

### March 14, 2026

- Creators can connect a bank account and get paid through Stripe Connect. Selling can start before payout setup is finished. Cashing out cannot.

### March 13, 2026

- Edgaze Blog starts as a real section, not a placeholder.
- Product pages are clearer about price, demo, and what you get.
- Bank setup continues for people who already started Connect.

### March 11, 2026

- Storefront and builder fixes from the payments work: a listing that could not publish after Connect, and a storefront that showed the wrong owner.

### March 5, 2026

- Trending this week on the marketplace, with a short list of public listings that actually ran.

### March 4, 2026

- Landing, docs, and the rest of the site feel like one product. The same names, the same dark chrome, the same paths into run and build.

### March 3, 2026

- Creator invites. You can join from a link instead of a public form.
- Docs cover Stripe basics: connect a bank, wait for pending earnings, then payout.
- Published workflows keep working after builder changes. A graph you already sold does not break because the editor moved a port.
- The builder is better at showing errors on the block that caused them.

### March 1, 2026

- Stripe Connect, and the first legal pages for payouts. Creators can start onboarding. Buyers still pay Edgaze. The split to the creator waits on a successful run.

## February 2026

### February 27, 2026

- Site copy and legal pages updated ahead of payouts, so terms, seller pages, and the landing page agree on how money moves.

### February 26, 2026

- Edge Platforms, Inc. is a Delaware C-Corporation.
- The product is still Edgaze. The company name is on the legal pages. The site, the marketplace, and the builder do not change name.

### February 23, 2026

- Inspector, block library, and a clearer way to catch workflow errors before you publish.
- Your profile is on the top bar, including handle and the menu into settings.
- Released as **v1.1.0**.

### February 22, 2026

- Inspector and builder security improvements. A graph you open from a listing cannot run unexpected network calls from the editor itself.

### February 20, 2026

- Welcome email when you sign up.
- Password reset works, including the link back into the app.
- Menus are clearer: marketplace, library, builder, and account are labeled as those things.

### February 16, 2026

- Where a listing allows it, you can try a flow without buying. That is the first public demo on a product page.

### February 15, 2026

- Public beta. Marketplace, builder, accounts, docs, and publishing are open.
- Prompt Studio and Workflow Builder, with `@handle/name` product pages.
- Browse, search, storefronts, likes, and comments.
- Email or Google sign-in. Custom handles, with a 30-day wait to change them. Founding Creator badge for people who published early.
- This is the second Edgaze. The first one was a student app. The thing that survived is a packaged outcome someone else can run.
- Released as **v1.0.0**.

### February 11, 2026

- Fixes and docs before the public launch: sign-in loops, broken listing cards, and the first pass of builder docs that match the editor you actually get.

### February 10, 2026

- You can edit your handle. Loading is calmer while the new URL is reserved.

### February 4, 2026

- Builder docs. Security and interface fixes so a shared graph cannot write over someone else's draft.

### February 2, 2026

- Open beta on the marketplace. Preview images, docs, and landing pages updated so the public site matches the builder people were already using.

## January 2026

### January 30, 2026

- The builder is more stable on long graphs. Marketplace browsing is better, including search and category pages.

### January 29, 2026

- Workflow runs have a real screen, not only a toast in the builder.
- Sign-in sends you back to the page you were on.
- The apply form works end to end, including attachments.

### January 26, 2026

- Sign-in, product pages, prompts, and profiles are more reliable. A refresh no longer drops you on a blank profile or a listing without a run button.

### January 24, 2026

- Back works on workflow previews. Product-page sign-in no longer loops you through the same prompt.

### January 23, 2026

- More builder blocks, a preview that works on phones, a better block library, and a working feedback form.

### January 16, 2026

- Workflow comments work on a listing. You can share a prompt product with a public URL.
- The apply form shows phone numbers on Windows, including the country code.

### January 6, 2026

- Prompts and workflows show up in search, including title and handle.
- Landing links work. The site no longer jumps around on a phone when the top bar loads.

## December 2025

### December 27, 2025

- Sign-in, builder, and marketplace became one product. One account, one shell, one set of routes.
- Most of the original student tools are gone. What is left is the path that became workflows: build something, run it, let someone else run it.

## November 2025

### November 20, 2025

- Google sign-in, profiles, and social links. You can create an account, set a handle, and put links on the public page.
- The first profile menu and sidebar that look like the app that shipped in beta, not like a landing-page experiment.

### November 18, 2025

- First commit in this repository. The name is older. This is the day the current codebase starts, not the day the idea starts.

## September 2025

### September 22, 2025

- The student super-app is out. Building every campus tool by hand was the wrong center of gravity.
- The interesting part is the infrastructure under those tools: a visual builder, a way to publish, a way for someone else to run the result, and a way to pay for that run.
- The audience changes from students to anyone who wants to package an AI outcome. Most of the original tools will not last. The idea of a packaged outcome does.

### September 15, 2025

- The first edgaze.ai page goes live. Beta signups open. There is no launch event and no waiting list of people already sold.
- The waitlist starts at zero. That is not a joke in the copy. It is what the counter said.
- That student-tools beta page is still up at [edgaze-ai.pages.dev](https://edgaze-ai.pages.dev/). Visual builder, marketplace, credits, and "Build, share and monetize student tools" are all already on that page, before this repo exists.

## August 2025

### August 27, 2025

- The pitch is "The AI Super-App for Students": one application with the tools a student might need, instead of a pile of chatbots and forums.
- Underneath that pitch, a builder, a marketplace where other people could publish tools, and a credits system for running them start to show up. That is the DNA of today's Edgaze, still wearing a campus costume.

### August 25, 2025

- The first Edgaze is a set of purpose-built student tools, not a workflow platform.
- Scam Checker, AI University Decider, Offer Letter Checker, and AgentDB are on the board. Each one is a specific decision, not a generic chat.
- The idea that survives every later pivot is already here: package AI around an outcome someone can just run.

### August 13, 2025

- A frontend talks to a working backend. Edgaze runs.
- It is primitive next to the product now. It is the first day it is software instead of designs and a name.

### August 3, 2025

- EscapeMyAgent starts feeling too narrow. The problem is not only education agents. Students were making hard calls with bad information: universities, offers, whether something was legitimate, admissions, and a pile of disconnected services.
- The name becomes Edgaze. [edgaze.ai](https://edgaze.ai) is checked and taken as the home.
- This is the closest thing to Edgaze's birthday as a name.

## July 2025

### July 27, 2025

- EscapeMyAgent.com exists. It is not a company. It is a small product for a problem that was annoying enough to build.
- The problem: students dealing with education agents while applying to university, with almost no visibility into their own application, withdrawals, or refunds.
- You can check what an agent is doing, flag a questionable situation, and handle the parts of an application that used to sit with someone else.
- This is the first ancestor of Edgaze. The through-line is the same: someone should get a specific outcome without having to understand all the complexity behind it.


---

---
title: Edgaze Code
description: A short keyword that opens your workflow or prompt on Edgaze without sharing a long link.
source: https://www.edgaze.ai/docs/edgaze-code
section: resources
---
# Edgaze Code

> A short keyword that opens your workflow or prompt on Edgaze without sharing a long link.

**Audience: Buyers and creators using Edgaze.**

Edgaze Code is a short keyword attached to your listing. Someone types it on edgaze.ai and lands on your workflow or prompt directly.

It is not programming code. It is a memorable handle for distribution.

## Choose a code

Keep it short, spellable, and relevant to the product. Brandable beats generic. If people cannot recall it after hearing it once, pick something clearer.

## Share it

Tell people to visit edgaze.ai and enter the code, for example: "Go to edgaze.ai and type AIART." You can also share the listing's normal link. A code supplements marketplace search; it does not replace it.


---

---
title: Sell to Humans and Agents
description: How one published workflow reaches marketplace buyers, REST API callers, and MCP agent tools.
source: https://www.edgaze.ai/docs/sell-everywhere
section: resources
---
# Sell to Humans and Agents

> How one published workflow reaches marketplace buyers, REST API callers, and MCP agent tools.

**Audience: Creators who want one workflow product available across every Edgaze surface.**

**Outcome: Publish once in Workflow Studio and sell the same execution through the marketplace, the API, and MCP without rebuilding the graph.**

## Overview

When you publish a workflow on Edgaze, you are not shipping a one-off chat prompt. You publish a product with a product page, a pinned version, a displayed per-run price, and an execution graph Edgaze runs for every buyer.

That same published product is available through:

- the **marketplace** for human buyers who discover and run it on the product page;
- the **REST API** for applications and backends that create runs programmatically; and
- **MCP** for AI agents that find and run the same workflow product from chat. See [Edgaze MCP](/docs/mcp).

You do not maintain separate products per channel. Marketplace, API, and agent invocations execute the published workflow version under the same pricing and run rules.

## Marketplace

Buyers find your workflow on the [marketplace](/marketplace), open its product page, provide inputs within your published envelope, and run it. Each successful run charges the displayed per-run price and credits your creator share of margin. See [Publish and Price](/docs/billing/publish-and-price) and [Run a Workflow](/docs/billing/run-a-workflow).

Marketplace buyers also see your free demo path when demos are enabled. Demos never bill and never create earnings. See [Free Demos](/docs/free-demos).

## REST API

Developers with an API key can discover runnable workflows and create runs against the same published versions. API runs use the same funding rules (bundle first, then wallet) and the same displayed price for that version. See:

- [API Quickstart](/docs/api/quickstart)
- [Create a run](/docs/api/create-run)
- [API billing](/docs/billing/api-runs)

Your workflow does not need a second “API edition,” and there is no separate API-access switch. Every published public workflow is available through the API, except legacy unlock listings.

## MCP

Agents connect at `https://mcp.edgaze.ai` and run the same published workflow product. There is no second graph. See [Connect Edgaze MCP](/docs/mcp/connect) and [MCP for creators](/docs/mcp/for-creators).

## What stays the same across channels

- **Version pinning:** Buyers, API callers, and agents run a specific published version with its pinned price.
- **Input envelope:** Oversized inputs are rejected before charge.
- **Billing:** Successful runs charge the displayed price; failed or cancelled runs do not charge margin. Demo and builder test runs are never billed.
- **Earnings:** You earn 80% of margin on successful paid runs, regardless of whether the buyer came from the marketplace, the API, or an MCP agent.

## What you do in Edgaze

1. Build and test in [Workflow Studio](/builder).
2. Publish with margin, envelope, and product page assets.
3. Share the product page or Edgaze code for humans; developers use the API with a key from [Developer](/developer/keys); agents find it through [Edgaze MCP](/docs/mcp) with no extra setup.

## Related docs

- [Workflow Studio](/docs/builder/workflow-studio)
- [Edgaze Code](/docs/edgaze-code)
- [API overview](/docs/api)
- [Creator Earnings Guide](/docs/billing/creator-earnings-guide)
- [Managed Execution](/docs/managed-execution)

## Start building

Open [Workflow Studio](/builder) and publish a workflow you can sell on the marketplace and call from the API or an agent.


---

---
title: Free Demos
description: How one-time free demos let buyers run your real workflow with their own inputs before they pay.
source: https://www.edgaze.ai/docs/free-demos
section: resources
---
# Free Demos

> How one-time free demos let buyers run your real workflow with their own inputs before they pay.

**Audience: Creators enabling free demos on published workflows.**

**Outcome: Let a buyer experience a real Edgaze run for free, then convert them to a paid run or bundle.**

## Overview

A free demo is a real execution of your published workflow. It is not a video, screenshot, or mocked UI. Edgaze runs the same published graph buyers will pay for, with demo funding and billing rules that keep demos free for the buyer and unpaid for the creator. Because Edgaze pays for the demo, chat steps run on a standard demo model, and image outputs may be watermarked.

Demo runs and builder test runs are never billed. They do not charge wallet or bundle balance, and they do not create creator earnings.

## Why demos exist

Buyers decide faster when they can provide their own inputs and see a finished result. Demos reduce trust friction without giving unlimited free compute:

- the run is a genuine hosted execution of your workflow;
- demos are limited to one per workflow for each device and network, and one per workflow for each signed-in account, counted when the demo starts; and
- paid runs still use your published per-run price after the demo.

## What buyers see

On a product page with demos enabled, buyers can start a free demo from the run surface. The flow may include a short verification step (for example Turnstile) so demo capacity is not abused. During and after the run, the UI marks the experience as a demo so it is not confused with a paid purchase.

Buyers can often start from AI-assisted prefilled example inputs or clear them and enter their own, within your published input envelope. Prefills are examples, not verified facts - see [AI Demo Inputs](/docs/ai-demo-inputs). Inputs above the envelope are rejected before the run starts - the same rule as paid runs.

## What creators get

- A live proof that the product works with real inputs
- No earnings on demo runs (by design)
- The same published graph the buyer will pay for later, with chat steps on a standard demo model and image outputs possibly watermarked

Configure demos as part of publishing and listing settings in Workflow Studio / the publish flow. Keep demo inputs and thumbnails honest: demos should represent normal results, not one-off cherry-picked outputs.

## Billing and abuse rules

| Run kind                     | Buyer charged?        | Creator earns?                         |
| ---------------------------- | --------------------- | -------------------------------------- |
| Free demo                    | No                    | No                                     |
| Builder test run             | No                    | No                                     |
| Successful paid run          | Yes - displayed price | Yes - 80% of margin |
| Failed or cancelled paid run | No                    | No                                     |

Edgaze may rate-limit, block, or require verification when demo usage looks abusive. See [Workflow Run Policy](/docs/workflow-run-policy) and [Fraud & Abuse Policy](/docs/fraud-abuse-policy).

## Related docs

- [AI Demo Inputs](/docs/ai-demo-inputs)
- [Run a Workflow](/docs/billing/run-a-workflow)
- [Run Outcomes Reference](/docs/billing/run-outcomes-reference)
- [Publish and Price](/docs/billing/publish-and-price)
- [Sell to Humans and Agents](/docs/sell-everywhere)

## Start building

Open [Workflow Studio](/builder), publish a workflow with clear inputs and outputs, and enable a free demo so buyers can try a real run before they pay.


---

---
title: AI Demo Inputs
description: How Edgaze uses AI to prefill demo inputs, why examples can be wrong, and what you should verify before trusting a result.
source: https://www.edgaze.ai/docs/ai-demo-inputs
section: resources
---
# AI Demo Inputs

> How Edgaze uses AI to prefill demo inputs, why examples can be wrong, and what you should verify before trusting a result.

**Audience: Buyers trying free demos and creators shipping demo-ready workflows.**

**Outcome: Understand that demo prefills are AI-assisted examples, not verified facts, and know what to check.**

## Overview

On free demos and product embeds, Edgaze can prefill example inputs so you can run a workflow in one click. Those prefills are generated with AI to illustrate a realistic path through the product. They are not a claim that the sample data is accurate, complete, or right for your situation.

The run itself is still a real execution of the published workflow, though chat steps in a free demo use a standard demo model and image outputs may be watermarked. The AI step only seeds the starting inputs (and sometimes related example framing) so the demo feels immediate.

## Why we prefill with AI

Blank forms slow first runs. Prefills help you:

- see what kind of input the workflow expects;
- experience a finished result without inventing sample text; and
- decide faster whether to clear the examples and try your own data.

Creators still publish the workflow graph and pricing. Prefills elevate the demo experience; they do not rewrite the workflow or invent a paid purchase.

## What can go wrong

Generative models can produce incorrect, outdated, biased, or odd example content. Prefills may:

- invent names, employers, metrics, quotes, or credentials;
- miss the tone or domain the creator intended;
- include details that look plausible but are false; or
- be a poor fit for your real use case.

Workflow outputs built on those inputs can also be wrong. Edgaze does not guarantee that AI-generated examples or the resulting Outputs are accurate. Review both before you rely on them.

See also [Content Disclaimer](/docs/content-disclaimer) for broader rules on AI Outputs and product results.

## What you should do

1. Skim the prefilled fields before you hit run.
2. Change anything that looks off, or use **Change the example inputs** and enter your own.
3. Treat the demo result as a product preview, not verified advice or a certified outcome.
4. For real work, use your own inputs after you understand the workflow.

## For creators

Keep listings honest. Prefills are meant to show a normal path through your product, not to oversell one-off results. If your workflow needs precise or regulated inputs, say so in the listing and encourage buyers to replace examples with their own data.

## Related docs

- [Free Demos](/docs/free-demos)
- [Content Disclaimer](/docs/content-disclaimer)
- [Workflow Run Policy](/docs/workflow-run-policy)
- [Composer & Generative AI](/docs/builder/composer-ai)


---

---
title: Managed Execution
description: What Edgaze runs for you when a hosted workflow runs: execution, retries and failover, queueing, results, and billing, with no stack of your own.
source: https://www.edgaze.ai/docs/managed-execution
section: resources
---
# Managed Execution

> What Edgaze runs for you when a hosted workflow runs: execution, retries and failover, queueing, results, and billing, with no stack of your own.

**Audience: Creators and buyers who want to understand what Edgaze operates during a run.**

**Outcome: Know what Edgaze handles for you so you can publish workflows without running your own execution stack.**

## Overview

When someone runs a published workflow, Edgaze manages execution, progress, retries where supported, results, and billing.

You publish the product. Buyers and API callers trigger runs. Edgaze runs the infrastructure.

## What Edgaze operates

### Execution

Hosted runs execute on Edgaze runtime infrastructure. A run may include multiple nodes - inputs, models, tools, HTTP calls, conditions, merges, delays, and outputs - as defined in your published graph. See [Workflow Run Policy](/docs/workflow-run-policy).

### Retries and failover

Transient provider or tool failures may be retried. Creators on Plus can also turn off **model failover** at publish time. When failover is enabled, Edgaze may continue with an eligible alternative without increasing the buyer's displayed price. See [Failover](/docs/billing/failover).

### Queueing

When Edgaze is at capacity, a run may wait in line before it starts. Buyers see their place in line and can leave the page; the run starts when a slot frees up, and signed-in buyers get an email when it is done. Plus runs get priority. A waiting run that never starts expires and is not charged. See [When Runs Fail](/docs/billing/when-runs-fail).

### Streaming and progress

Buyers see live progress in the product page run panel. Developers can poll run status, read ordered run events, or connect to the optional SSE stream for a run. See [Streaming & Real-time](/docs/api/streaming).

### Long-running state

Buyers and API clients can leave and return to a run's status and results without keeping a browser tab open for the entire execution.

### Billing

Successful paid runs charge the displayed price using wallet or bundle funding. Ordinary failed and cancelled runs are not charged. Demo runs are never billed. Builder test runs use the weekly Workflow Studio usage allowance, and pay compute from the wallet only if you turn on wallet funds once it runs out (see [Pricing Limits](/docs/pricing-limits)). See [When Runs Fail](/docs/billing/when-runs-fail) and [Run Outcomes Reference](/docs/billing/run-outcomes-reference).

### Infrastructure you do not run

Creators do not need to operate separate execution infrastructure for marketplace or API runs. Publish the workflow and Edgaze hosts execution. Buyers see one price before a run. See [Infrastructure Cost Estimation](/docs/infrastructure-cost-estimation) and [What You Pay For](/docs/billing/what-you-pay-for).

## What creators still own

- The workflow graph, prompts, and tool configuration
- Product page copy, pricing margin, and input envelope
- Keys in API Vault when using BYOK / non-hosted credential modes
- Compliance of the product with [Creator Terms](/docs/creator-terms) and [Creator Guidelines](/docs/creator-guidelines)

## Related docs

- [Workflow Run Policy](/docs/workflow-run-policy)
- [Workflow Studio](/docs/builder/workflow-studio)
- [Sell to Humans and Agents](/docs/sell-everywhere)
- [API Create Run](/docs/api/create-run)

## Start building

Open [Workflow Studio](/builder) and publish a workflow. Edgaze will operate execution, progress, and settlement for every marketplace and API run.


---

---
title: Legacy and retired features
description: What Edgaze still supports for older listings, and which creation tools have been retired.
source: https://www.edgaze.ai/docs/legacy
---
# Legacy and retired features

**Audience: Buyers and creators with an existing prompt or one-time-unlock workflow.**

This page separates older features that still work from creation tools that are no longer available. Current workflows use wallet-funded runs or workflow bundles. The public API exposes current free and pay-per-run workflows only.

## Still supported: one-time workflow unlocks

Existing one-time-unlock workflow listings remain available in the Edgaze web app. Buyers can make new supported purchases on those listings, access workflows they already unlocked, and run the version attached to their purchase. These listings are not available through the public API.

Checkout is used for these supported legacy unlocks. It is also used to add wallet funds and buy workflow bundles. Current pay-per-run workflows do not require a separate universal checkout.

## Retired: Prompt Studio creation

<a id="retired-prompt-studio"></a>

Prompt Studio creation and publishing are retired. Visiting the old Prompt Studio route takes you to [Workflow Studio](/builder), where Composer can help turn an idea or prompt into a workflow.

Existing prompt storefronts, purchases, buyer access, creator library records, moderation, and ownership-transfer support remain available. Retiring the editor does not delete historical prompts or purchase records.

For new products, start with [Workflow Studio](/docs/builder/workflow-studio) or [Templates](/docs/builder/templates).


---

---
title: Edgaze REST API
description: Run marketplace workflows from your backend, poll durable run state, and receive signed webhooks when jobs finish.
source: https://www.edgaze.ai/docs/api
section: api
---
# Edgaze REST API

> Run marketplace workflows from your backend, poll durable run state, and receive signed webhooks when jobs finish.

**Audience: Developers building with the Edgaze API.**

Run marketplace workflows from your backend, poll durable run state, and receive signed webhooks when jobs finish. The API shares the same entitlement, billing, and execution engine as the product UI. A run started via API behaves identically to one started in the browser.

Authentication is a scoped secret key. Execution is asynchronous: you receive a run id immediately, then poll or subscribe until the workflow completes.

## Base URL

```apibaseurl

```

All v1 routes are relative to this origin. Use HTTPS in production and pin the base URL in your client configuration.

## Core concepts

Three primitives cover most integrations:

- **API keys:** Secret keys with `run:execute` and `run:read` scopes, and an optional spend cap per key. Run creation is rate-limited to 60 requests per minute per key. See [Authentication](/docs/api/authentication).
- **Runs:** POST to start, GET to poll status and outputs, GET `/runs` for history, POST `/cancel` to stop one, GET `/events` for step-level progress. See [Create Run](/docs/api/create-run).
- **Webhooks:** Signed HTTPS callbacks when runs complete or fail. See [Webhooks](/docs/api/webhooks).

## What you can build

- Embed Edgaze workflows in your product with per-run wallet billing and spend-capped keys.
- Automate internal ops with owned workflows: list, trigger, and audit runs from CI or cron.
- React to run completion via webhooks instead of tight polling loops.
- Discover marketplace listings programmatically, inspect `inputSchema`, then trigger runs on demand.
- Build dashboards that show run events and buyer-facing charges.

## Request flow

1. **Authenticate:** attach `Authorization: Bearer …` on every request.
2. **Discover:** `GET /workflows` lists the marketplace catalog (add `runnableOnly=true` to limit it to workflows your account can run); `GET /workflows/{id}` returns `inputSchema` and pricing.
3. **Execute:** `POST /runs` with workflow id and inputs. Expect **202 Accepted**.
4. **Track:** poll `GET /runs/{id}` every 1-3s, or configure webhooks.
5. **Consume:** read `outputs` from the completed run response.

## Endpoints

| Guide / endpoint                                           | Description                                |
| ---------------------------------------------------------- | ------------------------------------------ |
| [Authentication](/docs/api/authentication)                 | API keys, scopes, and security behavior    |
| [Quickstart](/docs/api/quickstart)                         | Zero to a completed run in four steps      |
| [List Workflows](/docs/api/list-workflows)                 | Browse the marketplace workflow catalog    |
| [Get Workflow](/docs/api/get-workflow)                     | Full schema, pricing, and example request  |
| [List Workflow Versions](/docs/api/list-workflow-versions) | Version history, active and purchased pins |
| [Accept Workflow Update](/docs/api/accept-workflow-update) | Move a purchase pin to the active version  |
| [Create Run](/docs/api/create-run)                         | Start an async workflow run                |
| [List Runs](/docs/api/list-runs)                           | Page through run history                   |
| [Get Run](/docs/api/get-run)                               | Poll status, outputs, and charge           |
| [Cancel Run](/docs/api/cancel-run)                         | Stop an in-flight run                      |
| [List Run Events](/docs/api/list-events)                   | Ordered step-level events                  |
| [Webhooks](/docs/api/webhooks)                             | Signed lifecycle callbacks                 |
| [Errors & edge cases](/docs/api/errors)                    | Error catalog and async failure modes      |
| [Billing & spend caps](/docs/api/billing)                  | Funding order and spend caps               |
| [Streaming](/docs/api/streaming)                           | Polling, events, and SSE                   |
| [OpenAPI specification](/docs/api/openapi)                 | Machine-readable OpenAPI 3.1 document      |

## Next steps

New to the API? Start with the [Quickstart](/docs/api/quickstart). For production hardening, read [Errors & edge cases](/docs/api/errors) and [Billing & spend caps](/docs/api/billing).


---

---
title: Authentication
description: Every API request must include a valid secret key in the Authorization header.
source: https://www.edgaze.ai/docs/api/authentication
section: api
---
# Authentication

> Every API request must include a valid secret key in the Authorization header.

**Audience: Developers building with the Edgaze API.**

Every API request must include a valid secret key in the Authorization header. Keys are scoped, revocable, and optionally spend-capped: create and manage them in the [Developer console](/developer/keys).

## Key format

```bash
Authorization: Bearer edgaze_sk_live_…
```

Keys follow the pattern `edgaze_sk_live_…`. Test keys are not available yet. The plaintext is shown once at creation in the Developer console. If you lose the key, revoke it and create a new one.

Never commit keys to source control. Use environment variables or a secrets manager, and rotate keys if exposure is suspected.

## Scopes

Each key is issued with one or more scopes. The API rejects requests that lack the required scope.

| Scope            | Access                                     |
| ---------------- | ------------------------------------------ |
| `run:execute`    | POST /runs                                 |
| `run:read`       | GET /runs/\*, including events and streams |
| `workflow:write` | Accept a workflow version update           |

Workflow list and detail endpoints accept either scope. Run status, event, and stream endpoints specifically require `run:read`; `run:execute` alone cannot read a run. Default keys include both scopes.

## Security behavior

The API is designed to avoid leaking tenant or resource existence.

- Invalid, revoked, or expired keys always return **401** with the same message: no enumeration of which condition applied.
- Cross-tenant resource access returns **404** for runs, not 403. You cannot probe whether a run id exists in another account.
- Workflow entitlement denial returns **403 forbidden** with a uniform message when you are authenticated but not allowed to run a listing.
- Scope violations return **403 insufficient_scope** before any handler logic runs.


---

---
title: Quickstart
description: Discover a workflow, send valid inputs, and wait for the result with copy-paste-safe curl commands.
source: https://www.edgaze.ai/docs/api/quickstart
section: api
---
# Quickstart

> Discover a workflow, send valid inputs, and wait for the result with copy-paste-safe curl commands.

**Audience: Developers making their first Edgaze API run.**

This guide uses `curl`, `jq`, and a shell such as Bash or Zsh. It deliberately reads workflow IDs, input requirements, and run URLs from API responses so you do not have to assemble them by hand.

## Before you start

You need:

- an API key with `run:execute` and `run:read` scopes;
- enough wallet balance or a valid bundle for a paid workflow;
- any provider setup shown by the selected workflow's `credentialMode` and `requiredProviders` fields; and
- any third-party accounts listed in the workflow's `requiredIntegrations`, connected to your Edgaze account.

Create a key in [Developer → API keys](/developer/keys). The plaintext is shown only once. Put it in an environment variable and keep the quotes:

```bash
export EDGAZE_API_KEY='paste_your_api_key_here'
export EDGAZE_API_BASE='https://api.edgaze.ai/v1'
```

The public API uses `api.edgaze.ai`, not the marketing-site URL. These examples use `--fail-with-body`, so `curl` returns a failure exit code for HTTP errors while still showing Edgaze's JSON error message.

## 1. Discover a workflow

List current marketplace workflows for which your account has API access:

```bash
WORKFLOWS_JSON="$(
  curl --fail-with-body --silent --show-error \
    "$EDGAZE_API_BASE/workflows?runnableOnly=true&limit=10" \
    -H "Authorization: Bearer $EDGAZE_API_KEY"
)"

printf '%s\n' "$WORKFLOWS_JSON" | jq '.workflows[] | {
  id,
  name,
  displayedRunPriceUsd,
  credentialMode,
  requiredProviders,
  requiredIntegrations
}'
```

`GET /workflows` returns catalog metadata, not the input schema. Copy one `id` from the output:

```bash
export EDGAZE_WORKFLOW_ID='paste_workflow_id_here'
```

If the list is empty, remove `runnableOnly=true` to inspect the catalog. A result with `apiRunnableNow: false` cannot be started by the current account. `runnableOnly` checks listing access; provider-key and Plus requirements are still reported separately.

## 2. Inspect its inputs

Fetch the selected workflow before constructing a run request:

```bash
WORKFLOW_JSON="$(
  curl --fail-with-body --silent --show-error \
    "$EDGAZE_API_BASE/workflows/$EDGAZE_WORKFLOW_ID" \
    -H "Authorization: Bearer $EDGAZE_API_KEY"
)"

printf '%s\n' "$WORKFLOW_JSON" | jq '{
  name,
  displayedRunPriceUsd,
  credentialMode,
  requiredProviders,
  requiredIntegrations,
  inputSchema
}'
```

If `requiredIntegrations` is not empty, connect each listed account in your Edgaze settings before starting a run. Otherwise POST /runs returns `409 integration_connection_required`.

Build an inputs object using the exact `nodeId` or `name` from each `inputSchema` entry. Supply every field where `required` is `true`, use a value of the documented `type`, and use one of `options` for dropdown fields. For example:

```bash
export EDGAZE_INPUTS_JSON='{"input_node_id":"replace with a real value"}'
```

Use `{}` when `inputSchema` is empty. This validation catches malformed local JSON before it reaches the API:

```bash
printf '%s\n' "$EDGAZE_INPUTS_JSON" | jq --exit-status 'type == "object"' >/dev/null
```

## 3. Start one run

Create one idempotency key and reuse it if the POST must be retried. A new key intentionally creates a new, potentially billable run.

```bash
export EDGAZE_IDEMPOTENCY_KEY="quickstart-$(date +%s)-$$"

REQUEST_BODY="$(
  jq --null-input --compact-output \
    --arg workflow "$EDGAZE_WORKFLOW_ID" \
    --arg idempotencyKey "$EDGAZE_IDEMPOTENCY_KEY" \
    --argjson inputs "$EDGAZE_INPUTS_JSON" \
    '{workflow: $workflow, inputs: $inputs, idempotencyKey: $idempotencyKey}'
)"

RUN_JSON="$(
  curl --fail-with-body --silent --show-error \
    -X POST "$EDGAZE_API_BASE/runs" \
    -H "Authorization: Bearer $EDGAZE_API_KEY" \
    -H 'Content-Type: application/json' \
    --data "$REQUEST_BODY"
)"

printf '%s\n' "$RUN_JSON" | jq .
export EDGAZE_RUN_ID="$(printf '%s\n' "$RUN_JSON" | jq --raw-output --exit-status '.run.id')"
export EDGAZE_STATUS_URL="$(printf '%s\n' "$RUN_JSON" | jq --raw-output --exit-status '.run.statusUrl')"
export EDGAZE_STREAM_URL="$(printf '%s\n' "$RUN_JSON" | jq --raw-output --exit-status '.run.streamUrl')"
```

A **202 Accepted** response means the run was created, not that it succeeded. Keep the returned URLs: they already contain the correct API host and run ID.

## 4. Poll until terminal

The following loop waits for `completed`, `failed`, or `cancelled`, and stops after about five minutes. `pending`, `running`, and `suspended` are non-terminal states.

```bash
EDGAZE_TERMINAL_STATUS=''

for ((attempt = 1; attempt <= 150; attempt++)); do
  RUN_STATE="$(
    curl --fail-with-body --silent --show-error \
      "$EDGAZE_STATUS_URL" \
      -H "Authorization: Bearer $EDGAZE_API_KEY"
  )" || break

  STATUS="$(printf '%s\n' "$RUN_STATE" | jq --raw-output --exit-status '.status')" || break
  printf 'status=%s\n' "$STATUS"

  case "$STATUS" in
    completed)
      EDGAZE_TERMINAL_STATUS="$STATUS"
      printf '%s\n' "$RUN_STATE" | jq '{status, displayedChargeUsd, outputs}'
      break
      ;;
    failed|cancelled)
      EDGAZE_TERMINAL_STATUS="$STATUS"
      printf '%s\n' "$RUN_STATE" | jq '{status, reason, displayedChargeUsd}'
      break
      ;;
  esac

  sleep 2
done

if [ -z "$EDGAZE_TERMINAL_STATUS" ]; then
  printf 'Run did not reach a terminal state in this polling window. Continue with: %s\n' "$EDGAZE_STATUS_URL"
fi
```

Do not treat **202** as success, and do not treat `suspended` as failure. Branch on the final `status`; for a failed run, `reason` is a sanitized explanation suitable for logs or user-facing error handling.

## Optional: stream progress

SSE is useful for live progress. Polling remains the simplest durable integration.

```bash
curl --fail-with-body --no-buffer --silent --show-error \
  "$EDGAZE_STREAM_URL" \
  -H "Authorization: Bearer $EDGAZE_API_KEY"
```

The stream starts with a `snapshot`, sends `run.status` and node lifecycle events, emits `event: ping` heartbeat frames while idle, and closes after the terminal snapshot. A connection also rolls over about every 5 minutes: it ends with an `event: reconnect` frame whose `id` is the last event it sent, and the run keeps going. `curl` does not reconnect automatically. After a roll-over or a disconnect, reconnect with the last numeric SSE `id` you processed:

```bash
export EDGAZE_LAST_EVENT_ID='paste_last_processed_event_id_here'

curl --fail-with-body --no-buffer --silent --show-error \
  "$EDGAZE_STREAM_URL" \
  -H "Authorization: Bearer $EDGAZE_API_KEY" \
  -H "Last-Event-ID: $EDGAZE_LAST_EVENT_ID"
```

Process events idempotently because a client can disconnect after receiving an event but before saving its cursor.

## Common first-run errors

| HTTP or status                        | Meaning                                                           | Next action                                                                                         |
| ------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `401 unauthorized`                    | Missing, invalid, expired, or revoked key                         | Check `EDGAZE_API_KEY` or create a new key                                                          |
| `403 insufficient_scope`              | The key lacks the endpoint's scope                                | Add `run:execute` for POST and `run:read` for run reads/streams                                     |
| `403 forbidden`                       | The workflow is unavailable to this account through the API       | Choose a result returned with `apiRunnableNow: true`                                                |
| `409 integration_connection_required` | The workflow needs a third-party account you have not connected   | Connect the accounts in `requiredIntegrations`, then retry                                          |
| `402 spend_cap_reached`               | The key's spend cap rejected the POST                             | Raise the cap or wait for its window to reset; no run was created                                   |
| `429 rate_limited`                    | Too many create-run requests                                      | Wait for the `Retry-After` response header, then retry with the same idempotency key                |
| `status: failed` after 202            | Preparation, wallet, provider, or execution failed asynchronously | Inspect `reason`; retry only when appropriate and use a new idempotency key for a genuinely new run |

See [Create Run](/docs/api/create-run) for the complete request contract, [Streaming](/docs/api/streaming) for SSE event behavior, and [Errors](/docs/api/errors) for synchronous versus asynchronous failures.


---

---
title: Webhooks
description: Configure HTTPS endpoints in the Developer console to receive signed run lifecycle events.
source: https://www.edgaze.ai/docs/api/webhooks
section: api
---
# Webhooks

> Configure HTTPS endpoints in the Developer console to receive signed run lifecycle events.

Configure HTTPS endpoints in the Developer console to receive signed run lifecycle events. Webhooks complement polling: use them when you need push notification instead of a poll loop.

**Audience: Developers receiving terminal run notifications.**

## Subscribable events

- `run.completed`: dispatched when a run succeeds. `outcome` is `completed`, or `completed_with_issues` when the run returned its outputs but some steps failed (it is charged only for the steps that finished).
- `run.failed`: dispatched when a run fails.
- `run.cancelled`: dispatched when a run is cancelled.

## Verification

Each delivery includes `edgaze-signature: t=<unix>,v1=<hmac>` and `edgaze-webhook-id`. The signed payload is `{timestamp}.{raw_json_body}` using HMAC-SHA256 with your endpoint secret. Reject signatures older than five minutes to prevent replay.

Verify the signature against the exact bytes received, before parsing or re-serializing the JSON:

```javascript
import { createHmac, timingSafeEqual } from "node:crypto";

export function verifyEdgazeWebhook(rawBody, signatureHeader, secret) {
  const fields = Object.fromEntries(
    signatureHeader.split(",").map((field) => {
      const separator = field.indexOf("=");
      return [field.slice(0, separator).trim(), field.slice(separator + 1).trim()];
    }),
  );
  const timestamp = Number(fields.t);
  if (!Number.isFinite(timestamp) || !fields.v1) return false;
  if (Math.abs(Date.now() / 1000 - timestamp) > 300) return false;

  const expected = Buffer.from(
    createHmac("sha256", secret).update(`${timestamp}.${rawBody}`, "utf8").digest("hex"),
    "hex",
  );
  const actual = Buffer.from(fields.v1, "hex");
  return actual.length === expected.length && timingSafeEqual(actual, expected);
}
```

In a Next.js Route Handler, obtain `rawBody` with `await request.text()` and read the header with `request.headers.get("edgaze-signature")`. Return a non-2xx response when the header is missing or verification fails.

## Delivery guarantees

- Every subscribed endpoint gets its own queued delivery. The first attempt is made as soon as the run settles.
- A failed attempt is retried automatically: up to six attempts per delivery, spaced roughly 1 minute, 5 minutes, 30 minutes, 2 hours, and 6 hours apart, with jitter.
- Retried failures are: any 5xx, `408`, `425`, `429`, a connection error, and a timeout (an attempt gets five seconds to respond).
- Not retried: any other 4xx, and a redirect. Those mean the endpoint rejected or is misconfigured, so the delivery is marked failed immediately.
- When a receiver returns `Retry-After`, a longer wait is honored. A shorter one is ignored.
- Delivery is at-least-once, so the same event can arrive more than once. Deduplicate on `edgaze-delivery-id` when it is present; see [Delivery headers](#delivery-headers).
- Endpoints are called in parallel, and retries are interleaved with new events. Ordering is not guaranteed.
- Webhook failures never block run completion: your handler must be idempotent.
- After 15 consecutive deliveries that exhaust every attempt, the endpoint is paused and stops receiving events. The Developer console shows why and re-enables it in one click.
- Use test delivery and delivery logs in the Developer console to debug signature or payload issues. A test delivery is a single attempt and is never retried.

Retries make a missed notification unlikely, not impossible: an endpoint that stays down for more than about nine hours exhausts the delivery. If missing a terminal run would cause a correctness or billing problem on your side, reconcile on a schedule with [List Runs](/docs/api/list-runs) filtered by status, and use the run id to deduplicate against what you already processed.

A run cancelled through [Cancel Run](/docs/api/cancel-run) dispatches `run.cancelled` the same way, and is never charged.

## Delivery headers

| Header               | Meaning                                                                                                                                                         |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `edgaze-signature`   | `t=<unix>,v1=<hmac>` over `{timestamp}.{raw body}`.                                                                                                             |
| `edgaze-webhook-id`  | The endpoint this delivery was sent to. Use it to select the right secret.                                                                                      |
| `edgaze-delivery-id` | Stable id for this delivery. Every retry repeats it, so it is your deduplication key. Absent on test deliveries and on rare single-attempt fallback deliveries. |
| `edgaze-attempt`     | 1-indexed attempt number. Anything above `1` means an earlier attempt did not succeed.                                                                          |
| `edgaze-event`       | The event type, so you can route before parsing the body.                                                                                                       |

Retries send byte-identical bodies, so the signature verifies the same way on every attempt. Only the timestamp and signature change, because each attempt is signed when it is sent.

When `edgaze-delivery-id` is absent, deduplicate on the payload's `runId` and `type` instead.

Store the delivery id you have already processed and return `200` without reprocessing when you see it again:

```javascript
export async function POST(request) {
  const deliveryId = request.headers.get("edgaze-delivery-id");
  if (deliveryId && (await alreadyProcessed(deliveryId))) {
    return new Response(null, { status: 200 });
  }
  // Verify the signature, persist the payload keyed by deliveryId, then acknowledge.
  return new Response(null, { status: 200 });
}
```

## Payload reference

```json
{
  "type": "run.completed",
  "runId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "status": "completed",
  "outcome": "completed",
  "reason": null,
  "runUrl": "https://api.edgaze.ai/v1/runs/7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "occurredAt": "2026-07-08T10:00:42.000Z"
}
```

## Test deliveries

The Developer console's test delivery sends a signed payload with `type: "webhook.test"`. It carries no run, is sent once, and has no `edgaze-delivery-id`. Verify the signature as usual, then acknowledge it with `200` and skip run processing:

```json
{
  "type": "webhook.test",
  "message": "This is a test delivery from Edgaze.",
  "occurredAt": "2026-07-08T10:00:42.000Z"
}
```


---

---
title: Errors & Edge Cases
description: Complete error catalog and async failure modes for production integrations.
source: https://www.edgaze.ai/docs/api/errors
section: api
---
# Errors & Edge Cases

> Complete error catalog and async failure modes for production integrations.

Complete error catalog and async failure modes for production integrations. Branch on `error.code`: messages are stable but intended for humans, not programmatic matching.

**Audience: Developers implementing retries and failure handling.**

All errors use the envelope `{ "error": { "code": "…", "message": "…" } }`. Some errors add an optional `details` field inside `error`.

## Error catalog

| Code                              | HTTP | When                                                                                                                                                                              |
| --------------------------------- | ---- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `unauthorized`                    | 401  | Invalid, missing, revoked, or expired API key                                                                                                                                     |
| `account_restricted`              | 403  | The account that owns the key is restricted                                                                                                                                       |
| `insufficient_scope`              | 403  | Key lacks required scope                                                                                                                                                          |
| `forbidden`                       | 403  | Not entitled to the workflow or version (non-leaky)                                                                                                                               |
| `creator_listings_paused`         | 403  | The creator's paid listings are paused; the run was not created                                                                                                                   |
| `not_found`                       | 404  | Unknown workflow or run, or cross-tenant run                                                                                                                                      |
| `method_not_allowed`              | 405  | The resource does not support the HTTP method                                                                                                                                     |
| `idempotency_conflict`            | 409  | Idempotency key reused with a different request                                                                                                                                   |
| `integration_connection_required` | 409  | The workflow needs a third-party account the runner has not connected                                                                                                             |
| `invalid_request`                 | 409  | Accept Workflow Update when the workflow has no active version                                                                                                                    |
| `spend_cap_reached`               | 402  | API key spend cap exceeded (sync, before run created)                                                                                                                             |
| `rate_limited`                    | 429  | 60 POST /runs requests per minute per key                                                                                                                                         |
| `invalid_json`                    | 400  | Request body is not valid JSON                                                                                                                                                    |
| `missing_workflow`                | 400  | POST /runs without a `workflow` id                                                                                                                                                |
| `invalid_inputs`                  | 400  | Missing, unknown, conflicting, or incorrectly typed inputs                                                                                                                        |
| `invalid_request`                 | 400  | Invalid query parameter, pagination value, or request body (for example a malformed UUID), mismatched header and body idempotency keys, or an idempotency key over 255 characters |
| `invalid_cursor`                  | 400  | Invalid SSE Last-Event-ID or afterSequence                                                                                                                                        |
| `output_too_large`                | 413  | The run's output exceeds the maximum readable response size                                                                                                                       |
| `internal_error`                  | 500  | Unexpected server error (no internals leaked)                                                                                                                                     |
| `cancel_unavailable`              | 503  | Cancellation could not be delivered; retry the cancel shortly                                                                                                                     |

`invalid_inputs` responses may include `error.details`, an array of `{ "input", "message" }` objects naming each problem field. Treat `details` as optional.

`integration_connection_required` responses include `error.details`, an array of the accounts to connect. Each entry has `provider` (display name), `providerId`, `makesChanges` (whether the workflow writes to that account), and `connectUrl`, a page where a person can connect it in Edgaze settings.

## Async failures after 202

```doccallout
{"variant":"warning","text":"POST /runs may return 202 before funding checks finish. If the account lacks funds, polling later reports status: failed; there is no synchronous 402 for insufficient wallet balance. Spend-cap breaches return 402 immediately and do not include a run id."}
```

The condition-by-condition contract for charging and retries is maintained in [Create Run: funding and acceptance behavior](/docs/api/create-run#funding-and-acceptance-behavior).

## Run model edge cases

- **free:** runnable via wallet path when entitled.
- **per_run:** wallet or bundle charged at trigger.


---

---
title: Billing & Spend Caps
description: API runs bill identically to product UI runs. Keys optionally enforce spend caps before a run starts.
source: https://www.edgaze.ai/docs/api/billing
section: api
---
# Billing & Spend Caps

> API runs bill identically to product UI runs. Keys optionally enforce spend caps before a run starts.

API runs bill identically to product UI runs. Keys optionally enforce spend caps before a run starts: useful for staging keys, partner integrations, and blast-radius control.

**Audience: Developers responsible for API spend.**

For wallet funding details, see [API Runs (billing guide)](/docs/billing/api-runs).

## Funding order

When a run starts, Edgaze uses available funding in this order:

1. Eligible locked bundle for the pinned workflow version.
2. Wallet balance for the displayed run price.

## Spend caps

Caps can be daily, monthly, or lifetime. Each request reserves the run's creator margin plus its estimated compute hold against the cap. When that would exceed the key's cap, POST /runs returns **402 spend_cap_reached** and does not start a run. When the run finishes, the cap counts what the run was actually charged and releases the rest of the reservation.

## Pricing visibility

Workflow list and detail responses include `displayedRunPriceUsd`, the estimated run price shown to the buyer. Prefer GET /workflows/{id} when you need the latest estimate. GET /runs/{id} returns `displayedChargeUsd` when the final charge is available. For workflows that use your provider credentials, the provider may bill that account separately.


---

---
title: Streaming & Real-time
description: Track run progress with polling, event logs, and optional SSE streaming.
source: https://www.edgaze.ai/docs/api/streaming
section: api
---
# Streaming & Real-time

> Track run progress with polling, event logs, and optional SSE streaming.

Track run progress with polling, event logs, and optional SSE streaming. For server-side integrations, polling is the recommended default: it is simple, durable, and works through any HTTP client.

**Audience: Developers building live run progress.**

## Recommended pattern

1. POST /runs → capture `run.id` and `statusUrl` from the 202 response.
2. Poll GET /runs/{id} every 1-3s until terminal status (`completed`, `failed`, `cancelled`).
3. Read outputs from the completed run response.

## Event log

GET /runs/{id}/events returns ordered pages of lifecycle events. Continue with `afterSequence` when `hasMore` is true. Use it for step-level progress or debugging.

The first event is normally `run.queued`, followed by progress events such as `run.preparing` and `run.started`. Sequence numbers define event ordering; do not infer order from wall-clock polling time.

See [List Run Events](/docs/api/list-events) for the full reference.

## Waiting for capacity

Edgaze starts a run as soon as it is accepted while there is capacity. When the platform is at full capacity, the run waits in line instead of failing, and starts automatically in order. Nothing is needed from you, and waiting is never charged.

While it waits, the run stays `pending`, GET /runs/{id} returns a `queue` object, and the event log carries `run.queue_position` events whenever its place changes:

- `queue.state`: `waiting` while in line, `starting` once it leaves the line.
- `queue.position`: its place in line, where 1 is next.
- `queue.etaSeconds`: an estimate of the wait, or `null` when unknown.

`queue` is `null` once the run starts. If a run waits longer than its limit, it fails with a reason that says it was not charged, and you can submit it again.

## Event content

Each event carries a `data` object with the content for its type, or `null` when the event has no public content. It is an allowlist: fields not listed here are never included.

- `text`: an incremental chunk of a step's output, on `node.output.delta`.
- `status`: the run status this event implies, on run-level events.
- `reason`: why a run failed, why it is suspended (`wait_signal`, `wait_timer`), or why a node was skipped (`branch_not_selected`, `condition_false`, `upstream_failed`).
- `queue`: the run's place in line, on `run.queue_position` (see above).
- `activity`: a customer-facing description of what a stage is doing: `kind` and `label`, plus optional `model`, `icon` (a public image path), `aspect` (an image's shape, such as `16:9`), and `pass` (`current`, optional `total`).
- `progress`: a progress hint with `floor`, `ceiling`, and `etaMs`.
- `isOutput`, `outputLabel`, `output`: on a stage that produces a result, `isOutput` is `true`, `outputLabel` names the result, and `output` carries its value when it is small enough to inline. The run's full outputs are always available from GET /runs/{id}.

Concatenate `data.text` in sequence order, grouped by `nodeId`, to reproduce a step's output as it is generated. Failure text follows the same safe format as `Run.reason`.

### Presented runs

When you run a workflow you did not create, events are presented rather than raw. `nodeId` is an opaque stage id (for example `s_…`) that is stable within one run but unrelated across runs and to the workflow's internal structure. Live `text` is sent only for stages that produce a result, and stages describe themselves through `activity` and `progress`. Runs of your own workflows report the workflow's own node ids and omit the presentation fields.

Event types are an open set. Ignore types you do not recognize rather than treating them as errors.

## Live streaming

Run creation returns `streamUrl`. Connect with the same Bearer API key; the key needs `run:read`. The stream begins with a `snapshot`, replays available events, then follows new node and run-status events. While idle, the stream sends a heartbeat every 15 seconds as an `event: ping` frame whose data is `{"t": <unix ms>}`. Ignore `ping` frames; they carry no `id` and do not advance your cursor.

If the stream ends unexpectedly on the server side, it sends a final `event: error` frame with data `{"error": "…"}` and closes. Reconnect with the last `id` you processed, as below.

### Roll-over about every 5 minutes

A single stream connection lasts at most about 5 minutes. Before that limit, the server ends the connection on purpose with one final frame and closes cleanly:

```text
retry: 1000
event: reconnect
id: 42
data: {"lastSequence":42,"retryMs":1000}
```

This is not an error, and the run keeps going. Reconnect to the same `streamUrl` with `Last-Event-ID` set to that `id` (or `afterSequence=<id>`). Every event up to that id was already sent on the closing connection, and the new connection continues with the next one, so nothing is lost or repeated. Browser `EventSource` clients do this automatically: they wait the `retry` interval and resume with the last `id`. A run that waits in line or runs for a long time can span several connections.

Resume after a disconnect with `Last-Event-ID`. If your SSE client cannot set that header, pass `afterSequence=<last_id>`. Event ids increase monotonically, replay and live tailing do not duplicate an event, and an already-terminal run sends its snapshot and closes cleanly.

## Stopping a run

POST /runs/{id}/cancel requests that a run still in flight stops. Cancellation of a started run is asynchronous: the call returns `cancelRequested: true` with the run's current status, and the run reaches `cancelled` shortly afterwards. Wait for the terminal event on the stream, poll GET /runs/{id}, or handle the `run.cancelled` webhook. The buyer is not charged. The call needs `run:execute` and is idempotent, so cancelling an already-terminal run returns its existing status with `cancelRequested: false`. See [Cancel Run](/docs/api/cancel-run).


---

---
title: OpenAPI specification
description: Machine-readable OpenAPI 3.1 document for the Edgaze v1 REST API.
source: https://www.edgaze.ai/docs/api/openapi
section: api
---
# OpenAPI specification

> Machine-readable OpenAPI 3.1 document for the Edgaze v1 REST API.

The v1 REST API ships with an OpenAPI 3.1 document. Generators, documentation tools, and validators can consume it without an API key.

**Audience: Developers generating SDKs, importing into Postman/Insomnia, or building custom API tooling.**

## Where to find it

Pin the spec repository. It is the versioned artifact (JSON and YAML), updated automatically when the API on `main` changes:

- `https://github.com/edgaze-ai/edgaze-openapi`

```sh
curl -L https://raw.githubusercontent.com/edgaze-ai/edgaze-openapi/main/openapi.json \
  -o edgaze-openapi.json
```

Production also serves the same JSON without a key:

- `https://api.edgaze.ai/v1/openapi` (production, dedicated host)
- `https://www.edgaze.ai/api/v1/openapi`
- `https://www.edgaze.ai/openapi.json`

## What is in the document

- `openapi: "3.1.0"` and `info.version: "1.0.0"`.
- `servers` points at `https://api.edgaze.ai/v1`.
- `securitySchemes.bearerAuth` is HTTP bearer. Every non-webhook operation declares `security: [{ bearerAuth: [] }]` and carries `x-required-scopes` for programmatic scope checks.
- Stable `operationId` values for client generation.
- Response headers include `Cache-Control` and `Vary` on every authenticated response. `createRun` adds rate-limit headers on 429. `streamRun` declares the SSE headers.
- `createRun` documents the `Idempotency-Key` header (max 255 chars) and the 409 `idempotency_conflict` conflict response.
- `streamRun` documents the `Last-Event-ID` resume header.
- A `webhooks` section describes `run.completed`, `run.failed`, `run.cancelled`, and `webhook.test`, each with the `edgaze-signature` HMAC verification contract.

## Version resolution

The public v1 API resolves every run to a workflow version. Different callers may use different versions of the same workflow based on their access.

POST /runs resolves the version in this order:

1. **Explicit `version` in the request body.** The caller must have access to that version. A malformed (non-UUID) `version` returns 400 `invalid_request`; a well-formed but unknown or forbidden `version` returns 403 `forbidden`.
2. **Pinned access.** When `version` is omitted and the caller's access is pinned, the run uses that version. A newer release does not silently upgrade the caller.
3. **Current version.** When `version` is omitted and the caller is not pinned, the run uses the current active version.

GET /workflows/{id} surfaces three related fields so integrators can detect and reason about drift without polling every run:

- `pinnedVersionId`: the version this caller is pinned to via a prior purchase, or `null` when they follow the active version.
- `activeVersionId`: the workflow's current active version.
- `updateAvailable`: `true` when the caller is pinned to an older version than the active one.

Cache these values per workflow. When `updateAvailable` becomes `true`, inspect newly required inputs or output shapes before the next run. Buyers who want to use the newest version can call POST /workflows/{id}/accept-update (requires `workflow:write`).


---

---
title: List Workflows
description: Discover current free and pay-per-run workflows in the paginated marketplace catalog.
source: https://www.edgaze.ai/docs/api/list-workflows
section: api
---
# List Workflows

> Discover current free and pay-per-run workflows in the paginated marketplace catalog.

```apibar
list-workflows
```

## Overview

Use this endpoint to discover workflow catalog metadata before starting a run. It is the first call in most integrations: list or search workflows, select one with `apiRunnableNow: true`, fetch its detail for `inputSchema`, then POST /runs with the workflow id and inputs.

**Audience: Developers discovering runnable workflows.**

With no query parameters you get the paginated Marketplace catalog. This is the recommended discovery path. Use `scope=mine` only when you specifically need workflows published by the authenticated account.

```doccallout
{"variant":"info","text":"The list response does not contain inputSchema. Use q, offset, and limit to search, then fetch GET /workflows/{id} before creating a run."}
```

Each item also carries `requiredIntegrations`, the third-party accounts the runner must connect before a run can start. Check it alongside `apiRunnableNow`: a workflow with integrations you have not connected returns `409 integration_connection_required` from POST /runs.

## Authorization

Required scopes (either satisfies this endpoint):

```apiscopes
list-workflows
```

Pass the key as a Bearer token: `Authorization: Bearer edgaze_sk_live_…`

## Parameters

```apiparams
list-workflows
```

## Response

All responses are JSON. Errors use `{ error: { code, message } }`. Example success and error payloads are in the request/response panel above.

## Edge cases

```apiedges
list-workflows
```

---

## Endpoint reference
- **Method:** `GET`
- **Path:** `https://api.edgaze.ai/v1/workflows`
- **Scopes:** `run:read`, `run:execute`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with your secret API key. |
| `scope` | query | string | no | Marketplace catalog or the key holder's current workflows. Defaults to marketplace. |
| `q` | query | string | no | Search title, description, tags, owner handle, or Edgaze Code. |
| `offset` | query | integer | no | Pagination offset. Used with marketplace scope. |
| `limit` | query | integer | no | Page size (max 50). |
| `sort` | query | string | no | Marketplace sort order. |
| `runModel` | query | string | no | Filter by pricing model. |
| `runnableOnly` | query | boolean | no | When true, only workflows the key holder can run right now. |
## Example responses

### 200 Success

Paginated marketplace catalog (the default with no query parameters).

```json
{
  "workflows": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "name": "SEO Blog Writer",
      "description": "Generate an SEO-optimized blog post from a topic.",
      "ownerHandle": "creator",
      "edgazeCode": "SEO1",
      "runModel": "per_run",
      "displayedRunPriceUsd": 2.5,
      "pricingExplanation": "Displayed price includes creator margin and hosted compute.",
      "userAccess": "wallet",
      "accessLabel": "Pay per run",
      "credentialMode": "edgaze_hosted",
      "requiredProviders": [
        "openai"
      ],
      "requiredIntegrations": [],
      "apiRunnableNow": true,
      "runsCount": 1240
    }
  ],
  "pagination": {
    "offset": 0,
    "limit": 24,
    "hasMore": false
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 403 Insufficient scope
```json
{
  "error": {
    "code": "insufficient_scope",
    "message": "This API key is missing the required scope: run:read."
  }
}
```

### 400 Invalid query
```json
{
  "error": {
    "code": "invalid_request",
    "message": "Invalid query parameters."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to list workflows."
  }
}
```

## Edge cases

### Default scope

A bare request is the marketplace catalog; scope=mine returns current owned workflows.

### Scope requirement

Either run:read or run:execute satisfies the scope check for this endpoint.


---

---
title: Get Workflow
description: Retrieve a single workflow with input schema, access state, pricing, and an example run request.
source: https://www.edgaze.ai/docs/api/get-workflow
section: api
---
# Get Workflow

> Retrieve a single workflow with input schema, access state, pricing, and an example run request.

```apibar
get-workflow
```

## Overview

Fetch full detail for one workflow, including the `inputSchema` you need to build a POST /runs body. The response tells you whether the account has API listing access (`apiRunnableNow`), what the displayed run price is (`displayedRunPriceUsd`), and which credential mode and providers apply.

**Audience: Developers preparing a workflow run.**

Use this after listing workflows when you need schemas for a specific id, or when your integration caches workflow metadata and refreshes a single listing on demand.

```doccallout
{"variant":"info","text":"GET /workflows/{workflow_id} before the first production run. Check apiRunnableNow, credentialMode, requiredProviders, and requiredIntegrations before POST /runs. Build inputs from the returned inputSchema: both exact name and nodeId keys are accepted."}
```

`requiredIntegrations` lists the third-party accounts the runner must have connected, each with `provider`, `providerId`, `actions` (plain-language descriptions, each marked `read` or `write`), and `writes` (whether the workflow makes changes in that account). It is separate from `requiredProviders`, which covers AI model provider keys. When the list is not empty, connect those accounts in your Edgaze settings before running; otherwise POST /runs returns `409 integration_connection_required`, with the accounts still to connect in `error.details`.

## Authorization

```apiscopes
get-workflow
```

## Parameters

```apiparams
get-workflow
```

## Response

Example success and error payloads are in the request/response panel above.

## Edge cases

```apiedges
get-workflow
```

---

## Endpoint reference
- **Method:** `GET`
- **Path:** `https://api.edgaze.ai/v1/workflows/{workflow_id}`
- **Scopes:** `run:read`, `run:execute`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with your secret API key. |
| `workflow_id` | path | string | yes | UUID of the workflow. |
## Example responses

### 200 Success
```json
{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "SEO Blog Writer",
  "description": "Generate an SEO-optimized blog post from a topic.",
  "ownerHandle": "creator",
  "edgazeCode": "SEO1",
  "runModel": "per_run",
  "displayedRunPriceUsd": 2.5,
  "pricingExplanation": "Displayed price includes creator margin and hosted compute.",
  "userAccess": "wallet",
  "accessLabel": "Pay per run",
  "apiRunnableNow": true,
  "apiAccessAllowed": true,
  "purchaseUrl": null,
  "credentialMode": "edgaze_hosted",
  "requiredProviders": [
    "openai"
  ],
  "requiredIntegrations": [],
  "versionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
  "versionLabel": "ver_abc1",
  "pinnedVersionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
  "activeVersionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
  "updateAvailable": false,
  "inputCount": 2,
  "inputSchema": [
    {
      "nodeId": "input_1",
      "name": "topic",
      "type": "text",
      "required": true,
      "placeholder": "Blog topic"
    },
    {
      "nodeId": "input_2",
      "name": "tone",
      "type": "dropdown",
      "required": false,
      "options": [
        {
          "label": "Professional",
          "value": "Professional"
        },
        {
          "label": "Casual",
          "value": "Casual"
        },
        {
          "label": "Technical",
          "value": "Technical"
        }
      ],
      "defaultValue": "Professional"
    }
  ],
  "responseShape": {
    "run": {
      "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
      "status": "accepted",
      "statusUrl": "https://api.edgaze.ai/v1/runs/{id}",
      "eventsUrl": "https://api.edgaze.ai/v1/runs/{id}/events",
      "streamUrl": "https://api.edgaze.ai/v1/runs/{id}/stream"
    }
  },
  "exampleRequest": {
    "method": "POST",
    "url": "https://api.edgaze.ai/v1/runs",
    "body": {
      "workflow": "550e8400-e29b-41d4-a716-446655440000",
      "inputs": {
        "topic": "Edge AI",
        "tone": "Technical"
      }
    }
  }
}
```

### 403 Forbidden

Non-leaky: same response for not entitled and restricted workflows.

```json
{
  "error": {
    "code": "forbidden",
    "message": "You do not have access to this workflow."
  }
}
```

### 404 Not found
```json
{
  "error": {
    "code": "not_found",
    "message": "Workflow not found."
  }
}
```

### 400 Missing workflow
```json
{
  "error": {
    "code": "missing_workflow",
    "message": "Workflow id is required."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to load the workflow."
  }
}
```

## Edge cases

### Non-leaky access denial (HTTP 403 · `forbidden`)

A 403 forbidden is returned when you lack entitlement. A 404 is returned only when the workflow ID does not exist.

### Input key aliases

Inputs accept either the exact input name (topic) or nodeId (input_1). Unknown keys, ambiguous names, and conflicting values supplied through both aliases are rejected.


---

---
title: List Workflow Versions
description: List immutable workflow versions visible to the caller and inspect active and purchase pins.
source: https://www.edgaze.ai/docs/api/list-workflow-versions
section: api
---
# List Workflow Versions

> List immutable workflow versions visible to the caller and inspect active and purchase pins.

**Audience: Developers building with the Edgaze API.**

```apibar
list-workflow-versions
```

## Overview

Use this endpoint to compare the creator's active version with the version attached to a buyer's purchase. Owners see the complete history. Buyers with access to the workflow also see the complete history, with `isActive` marking the creator's active version and `isPurchased` marking the version their purchase is pinned to. Callers without access receive 403 `forbidden`.

Do not assume that one workflow id always resolves to one graph. A fixed `pinnedVersionId` continues to run until the buyer accepts an update. A null pin follows `activeVersionId`.

## Authorization

Requires either `run:read` or `run:execute`.

```apiscopes
list-workflow-versions
```

## Parameters

```apiparams
list-workflow-versions
```

## Response

`updateAvailable` is true only when a buyer has a non-null purchase pin that differs from the active version. Review `releaseNotes` and refresh the workflow's input schema before changing versions.

## Edge cases

```apiedges
list-workflow-versions
```

## Related endpoints

- [Get Workflow](/docs/api/get-workflow)
- [Accept Workflow Update](/docs/api/accept-workflow-update)
- [Create Run](/docs/api/create-run)

---

## Endpoint reference
- **Method:** `GET`
- **Path:** `https://api.edgaze.ai/v1/workflows/{workflow_id}/versions`
- **Scopes:** `run:read`, `run:execute`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with run:read or run:execute scope. |
| `workflow_id` | path | string | yes | UUID of the workflow. |
## Example responses

### 200 Success
```json
{
  "isOwner": false,
  "activeVersionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
  "pinnedVersionId": "55c7d7de-34f5-416f-bb0f-e1e7192ffb08",
  "updateAvailable": true,
  "versions": [
    {
      "id": "55c7d7de-34f5-416f-bb0f-e1e7192ffb08",
      "createdAt": "2026-07-01T10:00:00.000Z",
      "releaseNotes": "Initial purchased version.",
      "isActive": false,
      "isPurchased": true
    },
    {
      "id": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
      "createdAt": "2026-07-20T10:00:00.000Z",
      "releaseNotes": "Improved output schema.",
      "isActive": true,
      "isPurchased": false
    }
  ]
}
```

### 403 Forbidden
```json
{
  "error": {
    "code": "forbidden",
    "message": "You do not have access to this workflow."
  }
}
```

### 404 Not found
```json
{
  "error": {
    "code": "not_found",
    "message": "Workflow not found."
  }
}
```

### 400 Missing workflow
```json
{
  "error": {
    "code": "missing_workflow",
    "message": "Workflow id is required."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to load workflow versions."
  }
}
```

## Edge cases

### Legacy follow-active purchases

A null pinnedVersionId follows the active version. updateAvailable is false because there is no fixed purchase pin to compare.

### Scope alternatives

Either run:read or run:execute authorizes this read operation.


---

---
title: Accept Workflow Update
description: Re-pin a buyer purchase to the workflow's current active immutable version.
source: https://www.edgaze.ai/docs/api/accept-workflow-update
section: api
---
# Accept Workflow Update

> Re-pin a buyer purchase to the workflow's current active immutable version.

**Audience: Developers building with the Edgaze API.**

```apibar
accept-workflow-update
```

## Overview

This endpoint opts a buyer into the creator's current active version. It changes the immutable version selected by later runs that omit `version`.

Review release notes and the current input schema before accepting. A new version may change required inputs, output fields, pricing, or provider requirements.

## Authorization

Requires `workflow:write`. New keys do not receive this scope by default.

```apiscopes
accept-workflow-update
```

## Parameters

```apiparams
accept-workflow-update
```

## Response

The response returns the new `pinnedVersionId`. Repeating the call when the purchase already points to the active version is safe and returns `200`.

## Edge cases

```apiedges
accept-workflow-update
```

## Related endpoints

- [List Workflow Versions](/docs/api/list-workflow-versions)
- [Get Workflow](/docs/api/get-workflow)
- [Create Run](/docs/api/create-run)

---

## Endpoint reference
- **Method:** `POST`
- **Path:** `https://api.edgaze.ai/v1/workflows/{workflow_id}/accept-update`
- **Scopes:** `workflow:write`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with the opt-in workflow:write scope. |
| `workflow_id` | path | string | yes | UUID of the purchased workflow. |
## Example responses

### 200 Updated
```json
{
  "ok": true,
  "workflowId": "550e8400-e29b-41d4-a716-446655440000",
  "pinnedVersionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa"
}
```

### 403 Forbidden

The key lacks workflow:write, or the account has no buyer purchase to re-pin. Branch on error.code.

```json
{
  "error": {
    "code": "forbidden",
    "message": "You do not have access to this workflow."
  }
}
```

### 409 No active version
```json
{
  "error": {
    "code": "invalid_request",
    "message": "Workflow has no active version to accept."
  }
}
```

### 400 Missing workflow
```json
{
  "error": {
    "code": "missing_workflow",
    "message": "Workflow id is required."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to accept update."
  }
}
```

## Edge cases

### Owner keys

Owners do not use buyer update acceptance and receive 403 forbidden.

### Input and output drift

After accepting, refresh GET /workflows/{id}; the active version may define different inputs or outputs.


---

---
title: Create Run
description: Start an asynchronous workflow run. Returns 202 Accepted with a run id and polling URLs.
source: https://www.edgaze.ai/docs/api/create-run
section: api
---
# Create Run

> Start an asynchronous workflow run. Returns 202 Accepted with a run id and polling URLs.

**Audience: Developers building with the Edgaze API.**

```apibar
create-run
```

## Overview

This is the primary execution endpoint. It accepts a workflow id and an inputs object, validates required inputs, entitlement, and spend caps synchronously, then returns **202 Accepted** with a run id and URLs for polling.

Runs are asynchronous. A successful response means the request was accepted, not that the run finished. Always follow `statusUrl` until the run reaches a terminal state, then read outputs from the same response or from GET /runs/{id}/events for step-level progress.

Build `inputs` from the selected workflow's current `inputSchema`; there is no universal field such as `topic`. Every key must match either one published `nodeId` or its exact input `name`. Unknown keys are rejected so spelling mistakes cannot be silently ignored. Send an `Idempotency-Key` header and reuse it when retrying the same logical POST so a network retry does not create another billable run.

You may use a field's `nodeId` or `name` alias. Do not send both with different values: conflicting aliases return 400 `invalid_inputs`. Sending both is accepted only when their values are identical. When two published fields share a name, that name is ambiguous and you must use their node IDs.

```doccallout
{"variant":"info","text":"POST immediately after resolving inputSchema from GET /workflows/{id}. Store run.id and poll every 1-3 seconds. Handle 402 spend_cap_reached and 429 rate_limited at request time; handle wallet failures by polling for status failed."}
```

## Authorization

Requires `run:execute`.

```apiscopes
create-run
```

## Parameters

```apiparams
create-run
```

## Version resolution

POST /runs pins each run to one immutable workflow version. The same workflow id can therefore execute different graphs for different callers, and the resolution rules are as follows:

- **Explicit pin.** When you set `version` in the request body to an immutable version id you are entitled to, the run executes that exact graph. Owners can select any version in the workflow's history; buyers can select the version their purchase pin already covers (or the current version when not pinned) and any version they hold a bundle with runs left for.
- **Bundle.** When you omit `version` and you hold a bundle with runs left, the run executes the version that bundle was bought for (soonest-expiring bundle first) and draws from it. A creator publishing a newer version does not move the bundle.
- **Pinned access.** When you omit `version` and your access is pinned to a version, the run executes that version. A creator publishing a newer version does not silently upgrade you.
- **Current version.** Otherwise the run executes the workflow's current active version.

Cache `pinnedVersionId`, `activeVersionId`, and `updateAvailable` from GET /workflows/{id} to reason about drift. When `updateAvailable` flips to `true`, review the new version before the next run: input shapes and output shapes can change between versions.

A `version` that is not a well-formed UUID returns 400 `invalid_request`. A well-formed but unknown or forbidden `version` returns 403 `forbidden`. The public API never reveals whether an unknown version id belongs to another workflow.

## Idempotency

Use the `Idempotency-Key` HTTP header. The compatibility field `idempotencyKey` in the JSON body is also accepted. If both are present they must be identical after surrounding whitespace is removed; otherwise the request returns `400 invalid_request`. Header names are case-insensitive under HTTP, while key values are case-sensitive.

The public v1 API keeps this key optional for backward compatibility. New integrations should treat it as required for every `POST /runs`: without a key, an ambiguous network retry can create and charge a second run. Edgaze's own first-party run clients are rejected when they omit their attempt key.

Keys may contain any non-empty string up to 255 characters. Uniqueness is scoped to the Edgaze account behind the API key, not to one API key or workflow.

The request fingerprint covers the workflow, normalized inputs, and requested version. Reusing a key with the same request returns `202` and the original run URLs without creating or charging another run. Reusing it with a different request returns `409 idempotency_conflict`. A failed or cancelled run is still the original result for that key. To intentionally retry execution as a new run, use a new key.

## Funding and acceptance behavior

The table below describes behavior visible to an API client.

| Condition                                  | API result                            | Charge                                     | Safe retry                                                 |
| ------------------------------------------ | ------------------------------------- | ------------------------------------------ | ---------------------------------------------------------- |
| Valid request                              | `202 accepted`                        | Final charge is reported with the run      | Reuse the same key for the same logical request            |
| API-key spend cap exceeded                 | `402 spend_cap_reached`               | No charge                                  | Raise the cap or wait for its window to reset              |
| Insufficient wallet or eligible bundle     | `202`, followed by `status: failed`   | No charge                                  | Add funds, then use a new key for a new run                |
| Invalid published inputs                   | `400 invalid_inputs`                  | No charge                                  | Correct the input, then use a new key                      |
| Required third-party account not connected | `409 integration_connection_required` | No charge                                  | Connect the accounts listed in `error.details`, then retry |
| Creator's paid listings paused             | `403 creator_listings_paused`         | No charge                                  | Retry later; no run was created                            |
| Run reaches its compute limit              | `202`, followed by a failed status    | The run response and wallet history apply  | Use a new key only when another execution is intended      |
| Payment card issue                         | Not handled by `POST /runs`           | Runs use existing wallet or bundle funding | Resolve the separate wallet top-up checkout                |

## File inputs

`POST /runs` accepts JSON, not multipart form data. For an input whose schema type is `file`, send a JSON-safe WorkflowMedia object under that input's `nodeId`:

```json
{
  "__workflowMedia": true,
  "kind": "image",
  "url": "https://example.com/input.png",
  "mimeType": "image/png",
  "filename": "input.png"
}
```

Use an HTTPS URL your workflow can retrieve, or replace `url` with a raw `base64` field. Never put an API key or authorization token in the media URL.

## Response

Only POST /runs is rate-limited (60 req/min per key). Invalid JSON returns 400 `invalid_json`. Missing workflow returns 400 `missing_workflow`. Missing, unknown, conflicting, or incorrectly typed workflow inputs return 400 `invalid_inputs`. Reusing an idempotency key with a different workflow, normalized inputs, or requested version returns 409 `idempotency_conflict`.

Example payloads are in the request/response panel above.

## Edge cases

```apiedges
create-run
```

---

## Endpoint reference
- **Method:** `POST`
- **Path:** `https://api.edgaze.ai/v1/runs`
- **Scopes:** `run:execute`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with run:execute scope. |
| `Idempotency-Key` | header | string | no | Currently optional for backward compatibility, but strongly recommended for every request. Preferred location; maximum 255 characters. If the body field is also present, both values must match. |
| `workflow` | body | string | yes | Workflow UUID. |
| `inputs` | body | object | no | Strict map of exact input names (or nodeIds) to values matching inputSchema. Unknown keys and conflicting aliases are rejected. May be empty only when the workflow has no required inputs. |
| `version` | body | string | no | Optional immutable workflow version UUID. The caller must be entitled to this version. A malformed UUID returns 400 invalid_request; an unknown or forbidden version returns 403 forbidden. |
| `idempotencyKey` | body | string | no | Compatibility body location for the idempotency key. Prefer the Idempotency-Key header. |
## Example responses

### 202 Accepted

Run accepted. Poll statusUrl until terminal state.

```json
{
  "run": {
    "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "status": "accepted",
    "statusUrl": "https://api.edgaze.ai/v1/runs/7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "eventsUrl": "https://api.edgaze.ai/v1/runs/7c9e6679-7425-40de-944b-e07fc1f90ae7/events",
    "streamUrl": "https://api.edgaze.ai/v1/runs/7c9e6679-7425-40de-944b-e07fc1f90ae7/stream"
  }
}
```

### 402 Spend cap reached
```json
{
  "error": {
    "code": "spend_cap_reached",
    "message": "This API key has reached its spend cap. Raise the cap or wait for the window to reset."
  }
}
```

### 403 Forbidden
```json
{
  "error": {
    "code": "forbidden",
    "message": "You do not have access to run this workflow."
  }
}
```

### 400 Invalid request
```json
{
  "error": {
    "code": "invalid_inputs",
    "message": "A required workflow input is missing."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 404 Not found
```json
{
  "error": {
    "code": "not_found",
    "message": "Workflow not found."
  }
}
```

### 409 Idempotency conflict
```json
{
  "error": {
    "code": "idempotency_conflict",
    "message": "This idempotency key was already used for a different run request."
  }
}
```

### 409 Integration connection required

The workflow needs third-party accounts the caller has not connected. error.details lists them; connect each one, then retry.

```json
{
  "error": {
    "code": "integration_connection_required",
    "message": "Connect GitHub before running this workflow.",
    "details": [
      {
        "provider": "GitHub",
        "providerId": "github",
        "makesChanges": false,
        "connectUrl": "https://www.edgaze.ai/settings#gateway"
      }
    ]
  }
}
```

### 429 Rate limited

60 requests per minute per API key.

```json
{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded. Slow down and retry."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to start the run."
  }
}
```

## Edge cases

### Async wallet failures (HTTP 202)

POST returns 202 before wallet funding is verified. If balance is insufficient, the run fails asynchronously. Poll GET /runs/{id} and check for status failed.

### Spend cap is synchronous (HTTP 402 · `spend_cap_reached`)

Spend cap checks happen before the run row is created. A cap breach returns 402 immediately with no run ID.

### Rate limit ordering (HTTP 429 · `rate_limited`)

Rate limiting is enforced before run execution. A 429 never creates a partial run.

### Same billing as the product UI

API runs use identical entitlement, wallet, bundle, and BYOK billing paths as runs started from the web app.

### Safe retries

Send idempotencyKey and reuse the same value when retrying one logical request. Use a new value only for a genuinely new run.

### Strict input keys (HTTP 400 · `invalid_inputs`)

Unknown keys, ambiguous name aliases, and different values supplied for the same field by name and nodeId return 400 invalid_inputs before billing or run creation.

## Notes

- Only POST /runs is rate-limited (60 req/min per key).
- Invalid JSON returns 400 invalid_json. Missing workflow returns 400 missing_workflow.


---

---
title: List Runs
description: Page through your account's run history, filtered by status or workflow.
source: https://www.edgaze.ai/docs/api/list-runs
section: api
---
# List Runs

> Page through your account's run history, filtered by status or workflow.

```apibar
list-runs
```

## Overview

**Audience: Developers building a run history view.**

Returns the runs owned by the API key's account, newest first. Every run counts: those started by any key on the account and those started from the web UI both appear here.

The list response omits `outputs` and `reason` to stay compact. Read [Get Run](/docs/api/get-run) when you need a single run in full.

Runs are scoped to the API key owner, so this endpoint never returns another account's runs.

```doccallout
{"variant":"info","text":"Page with offset and limit while pagination.hasMore is true. Narrow with status or workflow. Read GET /runs/{id} for outputs and failure reasons."}
```

## Authorization

```apiscopes
list-runs
```

## Parameters

```apiparams
list-runs
```

## Response

Example payloads are in the request/response panel above.

Each row carries `id`, `status`, `workflowId`, `workflowVersionId`, `startedAt`, `completedAt`, `displayedChargeUsd`, `billingStatus`, and `outcome` (`completed` or `completed_with_issues` for a completed run, otherwise `null`). A run waiting for capacity lists as `pending` and matches `?status=pending` until it starts. The `pagination` object reports the `offset` and `limit` that were applied plus `hasMore`.

## Edge cases

```apiedges
list-runs
```

---

## Endpoint reference
- **Method:** `GET`
- **Path:** `https://api.edgaze.ai/v1/runs`
- **Scopes:** `run:read`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with run:read scope. |
| `status` | query | string | no | Filter by status: pending (not started yet, including runs waiting for capacity), running, completed, failed, or cancelled. |
| `workflow` | query | string | no | Only return runs of this workflow id. |
| `offset` | query | integer | no | Pagination offset. Defaults to 0. |
| `limit` | query | integer | no | Page size from 1 to 50. Defaults to 24. |
## Example responses

### 200 Success
```json
{
  "runs": [
    {
      "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
      "status": "completed",
      "workflowId": "550e8400-e29b-41d4-a716-446655440000",
      "workflowVersionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
      "startedAt": "2026-07-08T10:00:00.000Z",
      "completedAt": "2026-07-08T10:00:42.000Z",
      "displayedChargeUsd": 2.5,
      "billingStatus": "settled",
      "outcome": "completed"
    }
  ],
  "pagination": {
    "offset": 0,
    "limit": 24,
    "hasMore": false
  }
}
```

### 400 Invalid query
```json
{
  "error": {
    "code": "invalid_request",
    "message": "limit must be an integer from 1 to 50."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 403 Insufficient scope
```json
{
  "error": {
    "code": "insufficient_scope",
    "message": "This API key is missing the required scope: run:read."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to list runs."
  }
}
```

## Edge cases

### Suspended runs read as running

A suspended run is reported as running in this list. GET /runs/{id} reports the precise state.

### Owner-scoped

Only runs belonging to the API key's account are returned, including runs started from the web UI.

### No outputs

Rows omit outputs and reason to keep the query flat. Fetch GET /runs/{id} for those fields.


---

---
title: Get Run
description: Poll canonical run status, failure reason, buyer-facing charge, and final outputs.
source: https://www.edgaze.ai/docs/api/get-run
section: api
---
# Get Run

> Poll canonical run status, failure reason, buyer-facing charge, and final outputs.

```apibar
get-run
```

## Overview

**Audience: Developers polling an asynchronous run.**

Poll this endpoint after POST /runs to track execution. The response includes canonical `status`, a sanitized `reason` for failures, buyer-facing charge (`displayedChargeUsd`), explicit `billingStatus`, and final `outputs` once the run completes.

`billingStatus` is `pending` while a paid run is not financially final, `settled` when `displayedChargeUsd` is final, and `not_charged` when a terminal run produced no charge. New successful runs publish `status: "completed"` only after billing settlement commits. The `pending` terminal combination remains documented so clients can recognize and safely poll older or reconciled runs.

`outcome` says how a `completed` run went: `completed` when every step finished, `completed_with_issues` when the run returned its outputs but some steps failed. A run that completed with issues is charged only for the compute of the steps that finished, with no creator price. `outcome` is `null` for every other status.

A run that is waiting for capacity, or has not started yet, reports `status: "pending"`; it becomes `running` when its first step is about to start.

Runs are scoped to the API key owner. You only see runs started by keys belonging to the same account: cross-tenant ids return **404**, not 403.

```doccallout
{"variant":"info","text":"Poll every 1-3s until status is completed, failed, or cancelled and billingStatus is settled or not_charged. On success, read outputs and displayedChargeUsd. On failure, inspect reason."}
```

## Authorization

```apiscopes
get-run
```

## Parameters

```apiparams
get-run
```

## Response

Example payloads are in the request/response panel above.

## Edge cases

```apiedges
get-run
```

---

## Endpoint reference
- **Method:** `GET`
- **Path:** `https://api.edgaze.ai/v1/runs/{run_id}`
- **Scopes:** `run:read`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with run:read scope. |
| `run_id` | path | string | yes | UUID returned from POST /runs. |
## Example responses

### 200 Success
```json
{
  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "status": "completed",
  "reason": null,
  "suspended": false,
  "workflowId": "550e8400-e29b-41d4-a716-446655440000",
  "workflowVersionId": "8f57e8f7-7b74-4fe2-a425-722a135d93aa",
  "startedAt": "2026-07-08T10:00:00.000Z",
  "completedAt": "2026-07-08T10:00:42.000Z",
  "displayedChargeUsd": 2.5,
  "billingStatus": "settled",
  "outcome": "completed",
  "queue": null,
  "outputs": [
    {
      "nodeId": "output_1",
      "name": "article",
      "type": "text",
      "value": "# Edge AI in 2026\n\n…"
    }
  ]
}
```

### 404 Not found

Cross-tenant or unknown run IDs return 404 (non-leaky).

```json
{
  "error": {
    "code": "not_found",
    "message": "Run not found."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 403 Insufficient scope
```json
{
  "error": {
    "code": "insufficient_scope",
    "message": "This API key is missing the required scope: run:read."
  }
}
```

### 413 Output too large
```json
{
  "error": {
    "code": "output_too_large",
    "message": "The run output exceeds the maximum readable response size."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to load the run."
  }
}
```

## Edge cases

### Cross-tenant isolation (HTTP 404 · `not_found`)

Runs belong to the API key owner. Requesting another user's run ID returns 404, not 403.

### Displayed charge only

displayedChargeUsd is the buyer-facing price. Raw compute cost is never exposed via the API.

### Billing finality

billingStatus is pending until settlement, settled when displayedChargeUsd is final, or not_charged for terminal runs without a charge. Poll a terminal pending response until billing is final.

### Terminal states

Poll until status is completed, failed, or cancelled. Provider and orchestration timeouts are reported as failed with a safe reason.

### Completed with issues

outcome is completed when every step finished and completed_with_issues when the run returned its outputs but some steps failed. Both have status completed and fire run.completed. A run that completed with issues is charged only the compute of the steps that finished, without the creator's price; outcome is null for any status other than completed.

### Waiting for capacity

When Edgaze is at full capacity, a run stays pending and queue reports its place in line (position, 1 is next) and etaSeconds, an estimate. It starts automatically, in order; you do not need to retry. queue is null once the run starts. A run that waits past its limit fails with a reason saying it was not charged.


---

---
title: Cancel Run
description: Stop an in-flight run. Cancelled runs reach a terminal state and are never charged.
source: https://www.edgaze.ai/docs/api/cancel-run
section: api
---
# Cancel Run

> Stop an in-flight run. Cancelled runs reach a terminal state and are never charged.

```apibar
cancel-run
```

## Overview

**Audience: Developers stopping work a buyer no longer wants.**

Requests cancellation of a run that has not reached a terminal state. Cancellation is asynchronous for a run that has already started: the call records the request and returns, and the run reaches `cancelled` shortly afterwards. A run that has not started yet (still waiting for capacity or being prepared) is cancelled before the call returns.

To confirm the outcome, poll [Get Run](/docs/api/get-run) until it reports a terminal status, wait for the `run.cancelled` webhook, or watch the run's stream for its terminal event. A run that finishes before the cancellation takes effect keeps its real outcome.

Cancelled runs are not charged, and `billingStatus` settles to `not_charged`.

Cancellation requires `run:execute` rather than `run:read`, because it changes a run's outcome and its billing.

```doccallout
{"variant":"info","text":"The call is idempotent. Cancelling a run that already completed, failed, or was cancelled returns 200 with cancelRequested false and the existing status. A cancelled run appears as cancelled in GET /runs, GET /runs?status=cancelled, and GET /runs/{id}."}
```

## Authorization

```apiscopes
cancel-run
```

## Parameters

```apiparams
cancel-run
```

## Response

Example payloads are in the request/response panel above.

`cancelRequested` distinguishes the success cases:

- `true` with `status: "cancelled"`: the run had not started and is now cancelled.
- `true` with a non-terminal `status` such as `running`: cancellation was requested and is in progress. Poll GET /runs/{id} or wait for the `run.cancelled` webhook for the terminal state.
- `false`: the run was already terminal (or finished while the request was made) and nothing changed. `status` is its real outcome.

A `503 cancel_unavailable` response means the cancellation could not be delivered. It is safe to retry the same call shortly.

## Edge cases

```apiedges
cancel-run
```

---

## Endpoint reference
- **Method:** `POST`
- **Path:** `https://api.edgaze.ai/v1/runs/{run_id}/cancel`
- **Scopes:** `run:execute`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with run:execute scope. |
| `run_id` | path | string | yes | UUID returned from POST /runs. |
## Example responses

### 200 Cancellation requested

The run had started. Cancellation is in progress; poll GET /runs/{id} or wait for the run.cancelled webhook for the terminal status.

```json
{
  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "status": "running",
  "cancelRequested": true
}
```

### 200 Cancelled

The run had not started yet, so it was cancelled before the call returned.

```json
{
  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "status": "cancelled",
  "cancelRequested": true
}
```

### 200 Already finished

Cancelling a terminal run is a no-op and reports the existing status.

```json
{
  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "status": "completed",
  "cancelRequested": false
}
```

### 404 Not found
```json
{
  "error": {
    "code": "not_found",
    "message": "Run not found."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 403 Insufficient scope
```json
{
  "error": {
    "code": "insufficient_scope",
    "message": "This API key is missing the required scope: run:execute."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to cancel the run."
  }
}
```

### 503 Cancellation unavailable
```json
{
  "error": {
    "code": "cancel_unavailable",
    "message": "Cancellation could not be delivered. Retry shortly."
  }
}
```

## Edge cases

### Requires run:execute

Cancelling changes a run's outcome and its billing, so it needs run:execute rather than run:read.

### Idempotent

A run that already completed, failed, or was cancelled returns 200 with cancelRequested false and its status unchanged.

### Cancellation is asynchronous

cancelRequested true with a non-terminal status means cancellation was requested, not finished. An in-flight step may take a moment to stop, and a run that finishes first keeps its real outcome. Output produced before cancellation remains available in run events.

### Cancellation unavailable (HTTP 503 · `cancel_unavailable`)

If the cancellation cannot be delivered, the call returns 503 cancel_unavailable. Retry the same call shortly.

### Cross-tenant isolation

Cancelling another account's run returns 404, not 403.


---

---
title: List Run Events
description: Read ordered events for a run, including start, step progress, and completion markers.
source: https://www.edgaze.ai/docs/api/list-events
section: api
---
# List Run Events

> Read ordered events for a run, including start, step progress, and completion markers.

**Audience: Developers building with the Edgaze API.**

```apibar
list-events
```

## Overview

Returns a page of ordered events for a run. Each event has a monotonic sequence number and ISO timestamp.

Terminal event names match the final run status: `run.completed`, `run.failed`, or `run.cancelled`. Event payloads contain only the fields documented in the public API.

Use alongside GET /runs/{id} when you need step-level visibility: for example, showing progress in a dashboard or debugging which node failed.

```doccallout
{"variant":"info","text":"Fetch after POST /runs while polling status. Pass afterSequence from nextAfterSequence to read the next page. The default page is 100 events and the maximum is 500."}
```

## Authorization

```apiscopes
list-events
```

## Parameters

```apiparams
list-events
```

## Response

Example payloads are in the request/response panel above.

## Edge cases

```apiedges
list-events
```

---

## Endpoint reference
- **Method:** `GET`
- **Path:** `https://api.edgaze.ai/v1/runs/{run_id}/events`
- **Scopes:** `run:read`
## Parameters
| Name | In | Type | Required | Description |
| --- | --- | --- | --- | --- |
| `Authorization` | header | string | yes | Bearer token with run:read scope. |
| `run_id` | path | string | yes | UUID returned from POST /runs. |
| `afterSequence` | query | integer | no | Return events after this sequence. Defaults to 0. |
| `limit` | query | integer | no | Page size from 1 to 500. Defaults to 100. |
## Example responses

### 200 Success
```json
{
  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "events": [
    {
      "type": "run.started",
      "sequence": 1,
      "ts": "2026-07-08T10:00:00.000Z",
      "nodeId": null,
      "attempt": null,
      "data": {
        "status": "running"
      }
    },
    {
      "type": "node.output.delta",
      "sequence": 2,
      "ts": "2026-07-08T10:00:03.000Z",
      "nodeId": "llm_1",
      "attempt": 1,
      "data": {
        "text": "# Edge AI in 2026"
      }
    },
    {
      "type": "node.completed",
      "sequence": 3,
      "ts": "2026-07-08T10:00:15.000Z",
      "nodeId": "llm_1",
      "attempt": 1,
      "data": null
    },
    {
      "type": "run.completed",
      "sequence": 4,
      "ts": "2026-07-08T10:00:42.000Z",
      "nodeId": null,
      "attempt": null,
      "data": {
        "status": "completed"
      }
    }
  ],
  "hasMore": false,
  "nextAfterSequence": null
}
```

### 404 Not found
```json
{
  "error": {
    "code": "not_found",
    "message": "Run not found."
  }
}
```

### 400 Invalid query
```json
{
  "error": {
    "code": "invalid_request",
    "message": "Invalid query parameters."
  }
}
```

### 401 Unauthorized
```json
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}
```

### 403 Insufficient scope
```json
{
  "error": {
    "code": "insufficient_scope",
    "message": "This API key is missing the required scope: run:read."
  }
}
```

### 500 Server error
```json
{
  "error": {
    "code": "internal_error",
    "message": "Failed to load run events."
  }
}
```

## Edge cases

### Reconstructing streamed output

node.output.delta events carry data.text. Concatenate them in sequence order, grouped by nodeId, to rebuild what a node produced as it ran.

### data is an allowlist

Events expose only text, status, reason, queue, activity, progress, isOutput, outputLabel, and output. Cost records, payer identity, and raw provider errors are never included; failure text is generalized the same way as Run.reason.

### Presented runs

For workflows you did not create, nodeId is an opaque stage id that is stable within one run only, live text is sent only for stages that produce a result, and stages describe themselves with activity and progress.

### Treat event types as an open set

New event types may be added. Ignore types you do not recognize rather than failing.

### Bounded pages

Pages default to 100 events and are capped at 500 events.

### Prefer the stream for live UIs

GET /runs/{id}/stream delivers the same events over SSE without a polling loop.