Tutorial: Company Intelligence Workflow

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

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:

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

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

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.

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:

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.

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.

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.