First Experience Using AI (Claude 3.7 Sonnet) to Create a Wappler API Action – A Small Insight

Wappler General Need Help
1

Dear Friends,

Today I experimented for the first time with an AI model (Claude 3.7 Sonnet) to generate a Server Connect API action directly within Wappler. To my surprise, the model did an excellent job: the API action was correctly structured and generated.

However, there was one issue: the model consistently failed to correctly define variables in $_POST. Each time it tried, Wappler returned an error:

Invalid action_step. Unknown module or action. Please provide a valid JSON string that has module, action and options.

To overcome this, I manually added the $_POST variables myself, and then asked the model to read the updated Server Connect file to understand how the variables were structured properly. I also requested that it write a note to remind itself how to correctly define $_POST variables in future attempts (I’ve included that note below for reference).

Why am I sharing this?

Because I think that whenever we spot something that the AI model does incorrectly in Wappler, it’s worth teaching it the correct way and then asking it to take note of the pattern. This way, over time, we might help the models get better at working with Wappler-specific logic, modules, and structures—especially when generating code via AI tools or assistants.

This could also support our fellow developers in fine-tuning their AI workflows when working with Wappler.

Of course, if this approach isn’t helpful or relevant, feel free to let me know, @George or anyone else!

The Note is the following:

Server Connect API Input Parameters - Implementation Note

Correct Structure for Input Parameters

When implementing Server Connect API endpoints in Wappler, the proper structure for input parameters must be observed:

"meta": {  "options": {},  "$_POST": [    {"type": "text", "name": "paramName1"},    {"type": "number", "name": "paramName2"},    {"type": "boolean", "name": "paramName3"}  ],  "$_GET": [    {"type": "text", "name": "queryParam1"}  ],  "$_HEADER": [    {"type": "text", "name": "authToken"}  ]}

Implementation Details

  1. Parameters must be defined directly under the meta object (not inside meta.options)
  2. Each parameter requires both type and name properties
  3. Common data types:
  • text - For string values
  • number - For numeric values
  • boolean - For true/false values
  • array - For array structures
  • object - For JSON objects
  • file - For file uploads

Parameter Access

Parameters are accessed in action steps using expressions:

  • Body parameters: {{$_POST.paramName}}
  • Query parameters: {{$_GET.paramName}}
  • Header values: {{$_HEADER.paramName}}

Validation

Proper parameter definition allows for automatic validation:

  • Required parameters: Add "required": true property
  • Default values: Add "default": "value" property

Best Practices

  • Define all expected parameters explicitly
  • Use descriptive parameter names
  • Choose appropriate data types
  • Document parameters with meaningful comments when needed

This structure follows the standard Server Connect pattern and ensures proper parameter handling throughout the API workflow.

3 Likes
2

Good catch indeed. We haven't provided instructions for that yet. Will include those in the next update.

2 Likes