Skip to main content
This page is part of an AI coding agent skill and is written for agents, not humans. For the human-readable Base44 docs, see the developer documentation.

​
base44 api fetch

Call any public Base44 API operation (Apps API and Workspace API) with your CLI login; no API key or personal access token is needed. Add --help after the method and path to print the operation’s contract instead of calling it. Find the method and path first with api search, api catalog or api grep.

​
Syntax

​
Options

​
Authentication

Required: To call an operation, yes (npx base44 login). --help and a --read-only refusal send nothing and need no login.

​
The Contract (--help)

--help prints the operation’s description, parameters, requestBodySchema and responseSchema as JSON (plus requestBodyContentType for a non-JSON body). A contract can run to tens of KB, so select the parts you need:
Read the description before calling: it often names the operation to use instead, or the other operations a task needs (a custom domain, for example, also needs DNS records and linking before it serves). It accepts the path template as is.

​
Path Placeholders

  • {app_id} is filled from --app-id, BASE44_APP_ID, or the linked project, so an endpoint from search or catalog can be passed as is.
  • Any other placeholder (e.g. {workflow_id}) must be replaced with a real value by hand; fetch fails before sending otherwise.
  • The workspace ID is never filled in: Workspace API operations take it as a workspaceId query parameter or a {workspace_id} path placeholder. Get it from base44 workspace list.
  • IDs for the next call: a create returns the new resource, including its id; put that into the next path’s placeholder.

​
Read-Only Mode

--read-only refuses, before sending, any operation the spec doesn’t mark read-only. Use it whenever you are only looking, so a wrong endpoint can’t change anything.
  • Read-only is the spec’s mark, not the HTTP method: some list operations are a POST (e.g. POST /api/workspace/members/list) and still pass.
  • The contract doesn’t show the mark; api search <text> --read-only lists only the operations that have it.
  • It also refuses a path with an encoded /, \ or . (%2f, %5c, %2e), which it can’t check.

​
Request Bodies

  • JSON: --body '{"key":"value"}', --body @payload.json, or --body @- < payload.json. Stdin is read only with @-.
  • Multipart: when the contract shows requestBodyContentType: multipart/form-data, use --form name=value and --form name=@path instead of --body. Don’t combine --body and --form.

​
Output

The response body as the server sent it. Progress lines (“Loading the API spec”, “Calling …”) go to stderr and stdout carries only the response, so pipe stdout alone into jq. Don’t use 2>&1.
  • JSON is formatted in a terminal and passed through unchanged when piped.
  • Global --json keeps stdout machine-readable: a non-JSON text response is wrapped as {status, contentType, body}.
  • An empty response (e.g. a delete) prints {"status":204}.
  • A binary response isn’t printed; it’s described by status, contentType and bytes. Add --output <file> to save it.
  • With --output, it prints status, contentType, bytes and the output path.

​
Errors

  • Exit code is 0 on success and 1 on failure. A failure prints the server’s error and a request ID to stderr; with --json, stdout gets {error, code, details}.
  • Rate limit: the error also says how long to wait.
  • A 403 isn’t always about permissions: read the response body’s reason (some operations need a published app, for example).
  • No operation matches under --help or --read-only: the cached spec may predate the route, so add --refresh, or find the right path with api search.
  • Undoing a write is up to the API: read the description before writing, since some changes can’t be fully reverted.

​
Examples

​
Notes

  • fetch has no timeout: a call such as a deploy can take minutes.
  • fetch doesn’t validate the request itself; the server does.