#Can I list all my available convex api functions?

4 messages · Page 1 of 1 (latest)

gleaming wharf
#

I would like to dyanmically iterate through all the convex functions I have available

sour solsticeBOT
#

Hi @gleaming wharf. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

You can’t enumerate all functions from the api object at runtime in the browser – it’s a Proxy and Object.entries(api) etc. will be empty. [How to get the schema definitions]

Instead, you have a few options outside the client runtime:

  1. CLI: npx convex function-spec
    This command outputs all deployed functions (name, type, visibility, args, etc.) for a deployment. It’s what support recommended in the Discord thread and is the simplest way to get a complete list, e.g. to feed a tool or generate a manifest. [How to get the schema definitions]

  2. TypeScript API file via convex-helpers (multi‑repo style)
    Use the convex-helpers package to generate a typed API file from your deployment, then post‑process it:

    npm install convex-helpers
    npx convex-helpers ts-api-spec
    

    This generates an api.ts that’s similar in spirit to convex/_generated/api.d.ts but is a simple TS module you can inspect or transform (e.g. build a list of function paths). [Multiple repositories]

  3. Server-side parsing of api.d.ts or codegen output
    As mentioned in the Discord thread, one pattern is:

    • Run npx convex dev (which generates convex/_generated/api.d.ts). [Generated api]
    • Have a separate script watch or read that file (or its imports) and build a JSON manifest of { path, type, args, ... }.
    • Serve or embed that manifest wherever you need it (including the client).
#
  1. Dashboard listing
    The Convex dashboard’s Functions page shows exactly this list of functions, but that’s for manual inspection, not programmatic use. [Deployment functions]

There is no documented way to introspect the runtime api Proxy on the client to get all function names, so any dynamic iteration must be based on one of the generation/CLI approaches above and then consuming the resulting manifest or spec on the client.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: