The generic `api` command

Every dedicated CLI subcommand wraps a specific backend endpoint, but not every endpoint has a dedicated subcommand. splashify api is the escape hatch — any endpoint the app calls is reachable from the CLI through this one command.

Quick start

splashify api GET    /app/segments
splashify api GET    "/app/contacts?page=2&page_size=50"
splashify api POST   /app/messages/send-text --data '{"phone":"+919876543210","message":"hi"}'
splashify api POST   /app/ai-agents --data '{"name":"Support Bot"}'
splashify api PUT    /app/billing --data '{"display_name":"Acme"}'
splashify api PATCH  /app/segments/<id> --data '{"name":"new name"}'
splashify api DELETE /app/contacts/<id>

Syntax

splashify api <METHOD> <path> [--data '<json>']

<METHOD> is GET, POST, PUT, PATCH, or DELETE (case-insensitive)
<path> may be given with or without the /api/v1 prefix — /api/v1/app/me and /app/me are equivalent
Query parameters can be added directly: ?key=value&other=x
--data '<json>' sends a JSON request body — required for POST / PUT / PATCH writes

When to reach for `api`

Use api when:

The backend exposes an endpoint that's newer than your CLI version
You're prototyping against an undocumented endpoint
You need a query parameter the friendly command doesn't surface
You want to debug the raw response shape before wrapping it

If you find yourself running the same api call repeatedly, that's a signal to ship a friendly subcommand — file an issue with the endpoint and your usage pattern.

Auth + JSON

The same oc_live_ token from splashify connect is used. The same upgrade-prompt detection on 402/403 applies (see Subscription). Responses are pretty-printed JSON, just like every other command — pipe through jq as needed.

Common patterns

# Tail webhook events without the friendly command
splashify api GET "/app/integrations/logs?limit=20" | jq '.logs[]'

# Hit an endpoint that requires a path param resolved from /app/me
USER=$(splashify api GET /app/me | jq -r '.user.user_id // .user_id')
splashify api GET "/app/meta-ads/$USER/insights"

# Mutate a field there's no flag for yet
splashify api PUT "/app/segments/$SEG_ID" --data '{"refresh_interval_minutes":15}'

# Mass-DELETE with confirmation gate
for id in $(splashify api GET "/app/contacts?tag=test" | jq -r '.contacts[].id'); do
  echo "DELETE $id"; read -p "ok? " a; [ "$a" = y ] && splashify api DELETE "/app/contacts/$id"
done

Limits

The CLI does not stream multipart uploads through api — use the dedicated media upload, templates upload-media, and ai-agent knowledge upload commands for those.
The CLI does not consume Server-Sent Events (SSE) through api — use broadcast <id> progress (the one SSE surface that has a friendly subcommand).
Bodies larger than ~10 MB should be uploaded via the dedicated multipart commands.

Access Tokens — provides the bearer token
Every dedicated page — api is the fallback, not the recommendation

The generic api command