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

Have Codex build a small server endpoint, connect it to an Adalo button, and return an editable AI listing description with clear authentication and retry rules.

- Canonical URL: https://adalocado.com/guides/codex-adalo-custom-actions
- Verification: Documented from current sources
- Topic: APIs and Integrations
- Skill level: Advanced
- Last reviewed: 2026-10-26
- Builder and evidence scope: Visual builder Custom Actions documentation reviewed October 26, 2026; endpoint and example app not deployed or reproduced
- Verification owner: Adalocado editorial
- Next review: 2027-01-26
- Index status: index-now

## Short answer

Use Codex to build a server endpoint that validates the caller, generates a listing draft, and returns simple JSON. Connect an Adalo Custom Action to that endpoint, save the returned text, and let the seller review it before publishing.

## Intended outcome

A design for a Generate Description button that produces an editable draft while keeping provider credentials and usage controls on the server.

An AI writing feature becomes manageable when its interface is small: send the listing facts, receive a draft, and let the seller decide what to publish. Codex can prepare the code and checks around that boundary.

## Requirements

- An Adalo test app with Custom Actions available
- A server project Codex can edit and an HTTPS staging endpoint
- An AI provider account with credentials stored in the server environment
- A documented way for the endpoint to verify the app user's session
- A small set of fictional listings and a defined generation usage limit

## Step by step

1. **Define one button and one result**

   Choose a Generate Description button on an existing listing's edit screen. Inputs are title, condition, and seller notes. The result is one suggested description. Publishing remains a separate seller action, and the previous description stays available until the seller accepts a replacement.

2. **Have Codex specify the request contract**

   Design POST /listing-description to accept listingId, inputRevision, requestKey, title, condition, and notes. Use a flat success response such as status, description, and requestId, all text fields. Document field limits, error status codes, and example payloads before writing the handler.

3. **Build authentication before generation**

   Ask Codex to implement server verification using your app's supported identity mechanism and to check that the caller may edit the listing. A user ID in JSON or a shared app secret alone does not prove who is calling. If no verifiable identity reaches the endpoint, solve that connection before enabling paid generation.

4. **Implement the server with a local provider stub**

   Have Codex validate lengths, keep the provider key in environment configuration, enforce user limits, and store request keys scoped to the verified user. Test a deterministic fake response first. Return a safe error for provider failures and reject an existing key used with different input.

5. **Connect the Custom Action to staging**

   Configure the button's Custom Action with your endpoint, authentication, and dynamic inputs. Run its connection test using fictional data, map the returned text outputs, and save description to the intended Listing in a subsequent success action. Confirm the target record before adding navigation.

6. **Exercise retries and the review screen**

   Persist the pending request key for the current listing revision before sending. Retry that operation with the same key after a network failure; create a new key when the input changes. Confirm the seller can edit or discard the generated text and that failures do not erase an existing description.

## Why it works

- The server is a narrow boundary between an app interaction and a provider request. It can verify identity, reject invalid input, enforce usage limits, and translate provider output into fields Adalo can map.
- A persistent request key identifies one generation operation. Server-side deduplication matters because disabling a button does not prevent retries, reconnects, or repeated network delivery.

## A reusable prompt for Codex

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.

## What belongs in Adalo and on the server

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.

## Keep the first response deliberately small

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.

## Test the integration in two stages

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.

## What still needs checking

- Original written integration design; verify authentication, output mapping, and runtime behavior in a test app before release.

## Data model

| Collection | Properties | Relationships |
| --- | --- | --- |
| Listings in Adalo | Title; condition; seller notes; draft description; input revision; pending request key | Each listing belongs to one seller User |
| Generation Requests on the server | Verified user ID; request key; input hash; status; result; expiry | Each request is scoped to one user and one listing revision |

## Common failures

### The response arrives but no output can be mapped

Test a flat JSON response with text fields and recheck output detection. The visual builder documentation supports Text, Number, and Date/Time outputs; do not return an array of nested suggestions for this first feature.

### The generated text updates a different listing

Verify the Current Listing record used by the follow-up update action. Keep the generation and save sequence on the record's edit screen until that context is proven.

### A repeated tap creates another paid request

Check that the same pending request key survives the retry and that server storage enforces uniqueness per verified user. Persist the result and define how in-progress requests respond.

## Testing checklist

- [ ] A valid draft request returns one editable description without automatically publishing the listing.
- [ ] Missing or invalid user authentication is rejected before the endpoint calls the AI provider.
- [ ] Reusing the same request key for the same listing revision returns the stored result without a second generation.
- [ ] A changed listing revision receives a new key; reusing an old key with different input is rejected.
- [ ] A timeout or provider error leaves the previous saved description intact and offers a retry.
- [ ] The AI provider credential is absent from screen data and client code
- [ ] Caller identity and listing access are verified on the server
- [ ] The response uses fields the actual Custom Action editor can map
- [ ] The seller reviews and accepts the draft before publishing

## Limitations

- Codex builds and reviews the integration code; the app's runtime AI request goes to a separately configured API service.
- The example is an implementation design, not a deployed service or an end-to-end Adalo reproduction.
- Confirm Custom Action availability in your Adalo plan and the authentication capabilities of your actual app before implementing this design.
- AI generation has separate provider usage costs and can produce inaccurate wording; a person must review the draft.
## Sources

- [OpenAI: Codex best practices](https://learn.chatgpt.com/docs/learn/best-practices)
- [Adalo: Custom Actions and limitations](https://help.adalo.com/integrations/custom-actions)
- [OpenAI API: Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices)

## Changelog

- 2026-10-26: Created a Codex-assisted AI listing workflow with explicit request contracts, authentication, retries, and human review.

## Related resources

- [Connect an external inventory to Adalo with a Codex-built adapter](https://adalocado.com/guides/codex-adalo-external-collections)
- [Debug an Adalo workflow with Codex using records and evidence](https://adalocado.com/guides/codex-adalo-debugging)
- [Plan an Adalo app with Codex before building the screens](https://adalocado.com/guides/codex-adalo-app-planning)

Markdown version: https://adalocado.com/guides/codex-adalo-custom-actions.md