Crevio
An AI agent that runs your online business: products, orders, customers, email, and sites.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeRead-only
What it can do
What data it sees
Do you need an account
No: the server works without sign-in
An AI agent that runs your online business: products, orders, customers, email, and sites.
Server tool list (14)
Raw names from tools/list. Only developers need these.
| whoami | Identify the account, user, and credential behind this connection, with plan, credit balance, rate limits, and the tools available. Call it first to verify the setup. |
| ask_crevio | Delegate a job to the Crevio agent and wait for the result. Starts a run that works your account through the Crevio API (products, customers, orders, email, socials, sites, research), waits up to timeout_seconds, and returns the run with the agent's final reply in `result`. For anything longer, use start_task and wait_for_run. |
| start_chat | Open a chat with the Crevio agent and queue a run, without waiting. Returns the run immediately — its `chat_id` is the conversation to continue with send_message. Follow the run with wait_for_run or get_run. |
| list_chats | List the account's chats, newest first. |
| get_chat | Get a chat's title, kind, and latest run. |
| send_message | Continue a chat with follow-up instructions or answers — the agent keeps its context. Resumes a run waiting in needs_input, or queues a new run when the last one finished. Returns run_busy while a run is still in progress. Optionally waits for the reply. |
| list_messages | Read a chat's messages, oldest first. Returns the most recent `limit` messages; page back through older ones with starting_after. |
| wait_for_run | Wait for a run to settle (completed, failed, or needs_input) and return it with the agent's final reply. Returns wait_timed_out if it is still running when the timeout passes; call again. |
| get_run | Fetch a run's current status, summary, pending approvals, and (once settled) the agent's final reply. |
| list_runs | List the account's task runs, newest first — delegated jobs and scheduled tasks alike. Filter by status or task. |
| resolve_approvals | Approve or deny the integration actions a run is paused on (status needs_input with pending_approval_ids). Submit a decision for every pending id at once; the run resumes in the background. |
| cancel_run | Stop a run that is pending, running, or waiting for input. The run is finalized as failed with 'Cancelled by the caller'. |
| api_search | Discover available Crevio API endpoints. Use this BEFORE `api_execute` when you're unsure which endpoint to call, need to check parameter names, or want to explore what's available for a domain (e.g. "experiences", "discounts"). A `tools` method returns the full API catalog — an array of hashes keyed with strings: "method", "path", "summary", "description", "tags", "parameters", "request_body". Examples: `tools.select { |t| t["tags"]&.include?("Products") }.map { |t| "#{t["method"]} #{t["path"]} — #{t["summary"]}" }` `tools.find { |t| t["path"].include?("price_variants") && t["method"] == "POST" }["request_body"]` `tools.map { |t| t["tags"] }.flatten.compact.uniq.sort` — list all API domains |
| api_execute | Execute Ruby in a sandboxed VM against the Crevio REST API. Use `api_search` first to find the endpoint and its body fields, then call it here. Chain calls, transform results, return the final expression. ## Available in your code ``` get(path, params = {}) # paths auto-prefixed with /v1, routed in-process post(path, **body) # body as keyword args or a hash — both work patch(path, **body) delete(path) find_endpoints(query) # -> ["METHOD /path — summary", ...] iso8601(offset_seconds = 0) # mruby Time has no strftime/iso8601 ``` Returns the **last expression**; `puts` is side-channel only. Every run answers `{result:, calls:, output:}` — `calls` audits each REST call (`method`, `path`, `status`, plus `error_code`/`param` on failure). When `result` has unexpected nils, read `calls` for a non-2xx. Never project only success fields (`{id: r["id"]}`) — that hides the error from `result`. ## Rules that the schema does not tell you - Params are unwrapped, Stripe-style: fields at the TOP level. `{product: {...}}` is silently dropped by most endpoints. - Associations take the bare resource name and a prefix_id string — `product: "prod_x"`, never `product_id:`. Some required ones never appear in a schema's `properties`. - Courses and content live under `/experiences`, NOT `/products`. - Lists answer `{object: "list", data: [...], has_more}`; single resources answer the object directly. - Connected integrations go through the same REST surface: `post("/connections/<id>/execute", tool: "<tool>", arguments: {...})`, with ids from `get("/connections", search: "<service>")`. - Sandboxed mruby: no `File`, `ENV`, `Net::HTTP`, `Process`. 10s, 10 MB. ## Example — publishing a product (the ordering trap) A product cannot be created active: it needs a price variant first, or the call 422s. ```ruby product = post("/products", name: "...") post("/price_variants", product: product["id"], name: "Standard", amount_type: "fixed", amount: 4900, currency: "u |