---
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.

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. Optional spend caps and rate limits per key. See [Authentication](/docs/api/authentication).
- **Runs:** POST to start, GET to poll status and outputs, 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 admin dashboards that show run events and buyer-facing charges without exposing raw compute cost.

## Request flow

1. **Authenticate:** attach `Authorization: Bearer …` on every request.
2. **Discover:** `GET /workflows` lists runnable listings; `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) | Discover workflows your key can access    |
| [Get Workflow](/docs/api/get-workflow)     | Full schema, pricing, and example request |
| [Create Run](/docs/api/create-run)         | Start an async workflow run               |
| [Get Run](/docs/api/get-run)               | Poll status, outputs, and charge          |
| [List Run Events](/docs/api/list-events)   | Step-level event log                      |
| [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                  |

## 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).