Real-time & inline evaluation

Most integrations don't have a scenario sitting in FlowBeacon yet — they have a live Make.com blueprint and want governance on it right now. The inline endpoint is built for exactly that.

POST /evaluate/inline takes a raw blueprint in the request body and returns the full result in a single synchronous response — violations, the canvas module graph, and (optionally) step-by-step remediation. It is ephemeral: the blueprint is evaluated in memory and never stored. No pre-import, no scenario_id issued by us, no result token, no polling, no webhook.

Three ways to evaluate — pick one

	Stored (by ID)	Async inline	Sync inline
Endpoint	POST /evaluate + scenario_ids	POST /evaluate + blueprints	POST /evaluate/inline
Scenario must pre-exist	✅ yes	❌ no	❌ no
Returns results	poll / webhook	poll / webhook	in the same response
Stored	✅	❌ ephemeral	❌ ephemeral
Best for	dashboards over imported scenarios	batch/CI without import	grids, editors, real-time UX

If you already hold a blueprint and want one round-trip, use sync inline.

Request

POST /api/public/v1/evaluate/inline
{
  "scenario_id": "4729318",          // optional label, echoed back; no server meaning
  "name": "Lead sync to CRM",        // optional
  "blueprint": { "flow": [ /* raw Make.com blueprint JSON */ ] },
  "include_modules": true,           // canvas nodes + edges (default true)
  "include_remediation": false       // step-by-step fix guidance per violation (default false)
}

Only blueprint is required. Like every authenticated endpoint, the call still carries the Bearer key and X-FB-Signature (see Authentication).

Response

One envelope with everything a governance UI needs:

{
  "ok": true,
  "data": {
    "scenario_id": "4729318",
    "scenario_name": "Lead sync to CRM",
    "score": 85,
    "passing_count": 4,
    "failing_count": 1,
    "critical_count": 1,
    "evaluated_codes": ["SEC-1", "SEC-3", "SEC-5", "SEC-9"],
    "violations": [
      {
        "policy": "SEC-5",
        "status": "fail",
        "severity": "critical",
        "title": "Hardcoded secrets in module parameters",
        "description": "",
        "remediation_available": true,
        "failing_modules": [{ "module_id": "7", "module_name": "HTTP Request", "badge": "critical" }]
      }
    ],
    "module_summary": [{ "module_id": "7", "badge": "critical", "violation_count": 2, "policies": ["SEC-5"] }],
    "modules": [{ "id": 1, "module": "gateway:CustomWebHook", "app": "gateway", "x": 0, "y": 0 }],
    "connections": [{ "from": 1, "to": 7 }],
    "modules_count": 8,
    "evaluation_status": "evaluated"
  },
  "meta": { "watermark": "wm_a1b2c3d4" }
}

Optional enrichment fields

description, summary, and compliance_frameworks on a violation are best-effort. Depending on the policy and what the evaluator captured, description may be an empty string, and summary and compliance_frameworks may be absent. Render them only when present, and rely on policy, title, severity, status, and failing_modules as the always-present fields.

Set include_remediation: true to attach a remediation object (with ordered steps) to each violation. It costs one generation per violation, so leave it off for the fastest result and turn it on when you're rendering a fix panel.

Remediation runs under a time budget

Remediation generations run concurrently but are capped by an overall time budget so the call always returns promptly (no gateway timeout). If a violation's steps don't finish within the budget, that violation comes back with "remediation_pending": true and no remediation block instead of one with steps. Latency scales with violation count, so on blueprints with many findings expect some to be pending under load — render those as "remediation loading" and re-request, rather than treating the missing block as an error.

curl

BODY='{"scenario_id":"4729318","name":"Lead sync","blueprint":{"flow":[]},"include_remediation":true}'
curl -sS -X POST "https://api.flowbeacon.ai/api/public/v1/evaluate/inline" \
  -H "Authorization: Bearer $API_KEY" \
  -H "X-FB-Signature: $(sign POST /api/public/v1/evaluate/inline "$BODY")" \
  -H "Content-Type: application/json" \
  -d "$BODY" | jq

(sign is the helper from the Quickstart.)

Getting the blueprint from Make.com

A running Make scenario cannot read its own blueprint — there is no system variable that exposes it. You fetch it out-of-band from Make's API, then hand it to us:

1. Get the scenario id. Inside a scenario it's the system variable {{scenario.id}}. Outside, it's the id in the scenario URL.
2. Fetch the blueprint from Make: GET https://eu1.make.com/api/v2/scenarios/{scenarioId}/blueprint with a Make API token (Authorization: Token <make-token>, scope scenarios:read). This returns the full flow[] JSON.
3. POST it to /evaluate/inline.

Two tokens, two systems

Fetching the blueprint uses a Make API token (scenarios:read). Evaluating it uses your FlowBeacon fb_live_ key. They are different credentials for different systems.

The FlowBeacon Make custom app's Evaluate Blueprint module wires this up for you — map the output of a Get Blueprint step into the module and it POSTs inline automatically.

Integrating a governance grid

A grid renders governance for a user's live scenarios without importing them first:

1. List the user's scenarios (Make API, or your own catalog).
2. For the selected scenario, fetch its blueprint (Make API).
3. POST /evaluate/inline with include_modules: true and include_remediation: true.
4. Render straight from the single response — modules + connections draw the canvas, module_summary badges the nodes, violations[].remediation.steps fills the fix panel. No second round-trip, no stored scenario_id.

Limits & caveats

• Body size. Real Make blueprints commonly run 15–60 KB and beyond. The endpoint shares the 5 MB ceiling with POST /evaluate, but make sure your edge/proxy doesn't impose a smaller cap. An oversized body returns 413 blueprint_too_large with a max_bytes field.
• Quota. Each call counts as one evaluation against your daily quota, same as POST /evaluate.
• Connection-aware checks. Some policies need a live Make connection. Pass connection_id (and/or make_metadata) so connection-dependent controls evaluate instead of returning n-a. The response's enrichment block reports what resolved.
• Latency. include_remediation: true generates guidance per violation. For a snappy first paint, fetch without it and lazily request remediation only for violations the user expands.