MCP: ApiCall action refuses non-grouped/standalone API endpoints, even though runtime supports them

[sgardoll]

Summary

The flutterflow_ai DSL's ApiCall action fails to compile against any endpoint that isn't attached to an API group, throwing:

Bad state: Endpoint "<EndpointName>" is not attached to an API group.

This blocks DSL-driven editing of projects whose authors used single API calls in the FF editor (the common, idiomatic case for one-off endpoints). The underlying runtime helper Actions.apiCallNode(project, endpointName, groupName: ...) accepts a nullable groupName and resolves standalone endpoints fine — it's only the DSL compile path that artificially forbids them.

Offending code

flutterflow_ai/lib/src/dsl/compiler.dart, around line 4694:

final endpointGroup = action.endpoint.groupName;
if (endpointGroup == null) {
  throw StateError(
    'Endpoint "${action.endpoint.name}" is not attached to an API group.',
  );
}
return Actions.apiCallNode(
  project,
  endpointName: action.endpoint.name,
  groupName: endpointGroup,   // <-- helper accepts nullable
  ...
);

The Actions.apiCallNode helper signature in flutterflow_ai/lib/src/ui/actions.dart:

static FFActionNode apiCallNode(
  FFProject project, {
  required String endpointName,
  String? groupName,    // <-- already nullable
  ...
})

Removing the null check (or constructing the DSL Endpoint such that groupName may legitimately be null) would let the same DSL flow target standalone endpoints.

Repro

1. Create a project with a standalone API call (FF editor → API Calls → New API Call → don't put it in a group). Call it e.g. MyEndpoint.
2. From a flutterflow_ai script, write:

final ep = Endpoint.post(
  'MyEndpoint',
  'https://example.com/x',
  variables: {'q': string},
  body: {'q': '<q>'},
);
app.editPage('SomePage', (page) {
  page.ensureActions(
    page.findByText('Submit'),
    triggerType: FFActionTriggerType.ON_TAP,
    actions: [ApiCall(ep, params: {'q': AppState('query')})],
  );
});

3. Run flutterflow ai run script.dart --project-id <id>.

Expected

DSL push compiles and wires the standalone endpoint as the ApiCall target — same as it would for a grouped endpoint.

Actual

Bad state: Endpoint "MyEndpoint" is not attached to an API group.

Workarounds

• Wrap the endpoint in a single-endpoint API group (defeats the point of standalone endpoints).
• Attach via Endpoint..attachToGroup('SomeGroup') after declaring the endpoint, even when no group exists (also defeats the point).
• Skip the DSL ApiCall entirely and wire the action in the FF editor by hand after the DSL push (which is the workaround I'm currently using, but undermines the DSL's value proposition for projects that already have standalone endpoints).

Why this matters

Many FF projects in the wild have standalone API calls — that's the default UX path when adding "an API call" rather than building out a group. Any agent / DSL pipeline that wants to edit such a project against an existing standalone endpoint is forced to either restructure the project (move the endpoint into a group, breaking team conventions) or skip the API wiring entirely.

Environment

• flutterflow_ai SDK as bundled in current FlutterFlow AI workspace
• Issue surfaced while implementing edits against an existing project that contained both apiGroup-attached and standalone endpoints; standalone-endpoint refactor blocked entirely from DSL.