Saved execution requests

Saved Requests store argument payloads (and optionally the last response) for API Functions and Server Functions so you can reload an execute form. Shipped in Release 33. Webhook handles and Tabi tables are not supported in the product UX today even if a DTO enum lists them.

You need Execute permission (plus access to the function’s environment). There is no separate “Manage Saved Requests” flag.

What is stored

Each saved request is environment-scoped and owned by a user. Fields include name, optional description, resourceType, resourceId, request JSON, optional response, and optional executionId.

resourceType in the UI is one of apiFunction, publicApiFunction, serverFunction, publicServerFunction.

Canopy

On the execute page for an API or server function, fill arguments, run if you want, then save the request under a name.

Secure argument values are omitted unless the argument is a Vari reference (PolyVariable). Reloading a saved request will not restore a pasted secret.

Open the Saved Requests collection (or “View Saved Requests”) filtered by function. Execute reopens the form with savedRequestId.

Sharing within the environment vs owner-only, and retention/size limits, are TBD. Treat saved requests as env-scoped named snapshots, not a public catalog.

REST

Base path /saved-requests. Authorize with Bearer API key. Instance Swagger tag: Saved Requests. See API reference.

  • GET /saved-requests — list; query resourceType, resourceId (SuperAdmin may pass environmentId)

  • POST /saved-requests — create; 409 on unique-constraint clash (Canopy mints a new UUID per save)

  • GET /saved-requests/:id

  • PATCH /saved-requests/:id

  • DELETE /saved-requests/:id

Create/update/delete require Execute and environment access.

$ curl -H "Authorization: Bearer $POLY_API_KEY" \
    "$HOST/saved-requests?resourceType=apiFunction&resourceId=$FN_ID"