Retool agent can create a REST resource: set it up for Sume

Can Retool's agent create a REST API resource for Sume from a prompt? Yes, if you hand it the right facts. Retool's changelog entry for October 2 says users can prompt the app-building agent to create REST API or PostgreSQL resources directly from the app builder (read 2026-10-04). The agent will fill in what you tell it and guess the rest, so the useful work is writing a prompt that leaves nothing to guess for Sume: the base URL, exactly one auth header, and a free request to test with.

This post gives that prompt, the two mistakes it prevents, and a safe way to handle the key.

The facts the agent needs

Sume's REST API lives at https://api.sume.com. Authentication is either Authorization: Bearer <key> or x-api-key: <key>. The documentation is explicit that sending both returns 401 unauthorized with the message "Send only one API key credential." An agent that adds a default Authorization header and then also sets x-api-key will produce a resource that fails every call.

The machine-readable description is the OpenAPI document at https://api.sume.com/reference/json. Pointing the agent at it removes the need to describe each endpoint by hand.

A prompt you can paste

Write the prompt as constraints, not a wish. Name the one header, name the test request, and say what the agent must not do. Keep the key itself out of the prompt: use Retool's secret or configuration storage for the value and let the resource read it from there.

If a key was already pasted into a chat or prompt, treat it as exposed and rotate it. Sume's authentication guidance says to rotate a key that appears in logs or chat history, and to keep keys out of frontend code, screenshots and tickets.

• Create a REST API resource named sume with base URL https://api.sume.com.
• Send exactly one auth header on every request: x-api-key. Do not add an Authorization header.
• Read the key from the configuration variable SUME_API_KEY.
• After creating it, run GET /v1/me and show me only the status code.
• Do not run any other request until I confirm. The OpenAPI spec is at https://api.sume.com/reference/json.

curl -sS -o /dev/null -w '%{http_code}\n' https://api.sume.com/v1/me -H "x-api-key: $SUME_API_KEY"

Check what the agent built

Open the created resource and look at three things before you build a query on it. First, the headers list should contain one auth header, and it should reference a variable rather than a literal key. Second, there should be no headers copied from a sample request, such as a Content-Type on a GET that you do not need. Third, the base URL should have no trailing path, so the queries you write next use /v1/... cleanly.

Then run GET /v1/me. A 200 means the key and header are right. A 401 almost always means a doubled credential or a stale key; the error body uses the envelope {error:{code,message,request_id}}, and the request_id is the value to quote if you ever contact support.

Paid calls from the same resource

Once the test passes, the first paid query is where Retool's retry behavior matters. A write such as an image or video request returns 202 when accepted, which means accepted, not finished. Add an Idempotency-Key header built from a stable value, such as the Retool record id, so that a retry or a double click returns the original job instead of creating a second paid one. Reusing a key with a different payload returns 409 idempotency_conflict, which is the signal that the record changed and needs a new key.

Then poll GET /v1/jobs/:id/status, honoring next_poll_after_seconds, and read GET /v1/jobs/:id/result when the job completes. The post on Retool workflow resource blocks and async polling shows how to structure that loop, and the one on a webhook relay with an API key header covers receiving results instead of polling.