Build an AI listing assistant for Adalo with Codex and a Custom Action

In this server repository, build the smallest endpoint for an Adalo listing-description assistant. First inspect the existing framework and authentication. Write the request and response contract with sample JSON. Verify the caller and their right to edit the listing; do not trust userId in the body. Keep the provider key server-side. Add input bounds, per-user usage limits, persistent request deduplication, a provider timeout, and safe error responses. Begin with a fake provider so local tests make no paid calls. Return a single description string and give me the Adalo Custom Action field mapping. State any authentication detail you cannot establish from this project.

Provide Codex with the hosting setup, current session documentation, and an example redacted request from the app. Without those details, it can design an interface, but it cannot truthfully claim the app's identity flow is connected.

Adalo owns the seller's inputs, the edit screen, the loading and error messages, and the decision to save or publish. The server owns privileged provider access, request validation, identity verification, usage enforcement, and generation. Codex helps create and test that server code during development.

This also answers a common interpretation of putting Codex inside an app. The example does not embed your Codex workspace or make your subscription an app backend. It uses code prepared with Codex to connect the app to a separately configured runtime API.

For a fictional used bicycle, title might be City bicycle, condition might be Used, and notes might be Scratched frame; basket included. The server should return one draft that preserves those facts. Ask the generation instruction to avoid inventing repairs, warranties, certifications, or condition claims that the seller never supplied.

The visual Custom Action documentation distinguishes output mapping from screen actions and notes that outputs from a Screen Action are unavailable to subsequent actions. Use a button-triggered sequence for this pattern. It also states that Custom Actions cannot run directly as form-submission actions; configure the actual editor path rather than assuming every form event exposes them.

First test contracts and failure handling locally using the fake provider: valid text, missing credentials, invalid listing access, excessive input, repeated key, changed input with an old key, and a simulated timeout. A successful local response demonstrates the handler, not the Adalo wiring.

Then use staging to test one real button sequence, including output mapping, persisted draft text, a timeout, and a deliberate retry. Only after that should you enable a tightly limited provider call and review the generated wording. Team-level Custom Action edits can affect other apps using the same action, so give a changed contract its own action when necessary.