3Min API

Use this when the user wants to send data to one of their endpoints or read what it has stored — a test call, a real write, or checking what arrived. Not for finding out why something failed: error_details and webhook_delivery come from logs only. Examples: "Send a test order through", "Show me the last few submissions", "Has anything new come in since this morning?" Runs against the endpoint's own default API key; a collaboration key cannot be used here. POST, PUT and DELETE are asynchronous and return 202 with a record id; the row is written a few seconds later, so read it back about 5 seconds on. PUT is a full overwrite — fields left out of the body are erased, so fetch the record first and send it back with only the change applied. The four read modes are not interchangeable: - GET with record_id — one record in full. - GET without record_id — a page of recent records, newest first. For showing a list, not for watching one: looping on it refetches the same page and pays again. - SEARCH — find records by text anywhere in the payload, last 30 days. - POLL — what arrived since the last call, oldest first. The only mode that can say "since when", so it is the one for keeping up with new records. Every request costs one call against the monthly quota, including a POLL that comes back empty. help(topic: "api") has the error codes and help(topic: "polling") the polling contract — read them when a call is rejected or a polling loop is being built, not to make a call.

api_call

Use this when the user wants to stop one or more tasks that have not finished. Not for stopping work already underway: a worker that received the task is not notified and may still carry it out. Examples: "Cancel that order", "Stop all the imports I just started" Takes up to 100 task ids and returns a result for each: cancelled, already_terminal (with the final status), or not_found. Some ids being cancelled while others are not is a normal outcome. Cancelling marks the task cancelled and stops any further delivery attempts. A worker already running the job finds out only when its next status report comes back 409. Completed, failed and cancelled tasks never change status.

task_cancel

Use this when a specific task id is at hand and the user wants that task's current status or its outcome. Not for waiting on a task: a working task returns the same response until the worker reports, so calling again in a loop costs a call and changes nothing. Examples: "Is it done yet?", "What did the worker send back?" Returns the full task in any status: status (working, completed, failed or cancelled), status_message, and — once finished — the result or error, passed through unmodified, up to about 100 KB. These values come from the worker's calls to the status report API — but a failed task does not always mean the worker reported one. 3Min API itself sets failed, with its own error, when delivery never succeeded or 24 hours passed without a final report, and cancelled on cancellation. A task id from another account, or one past retention, is reported as not found. Telling those three apart, and what to check for each: help(topic: "tasks").

task_get

Use this when the user wants someone else to call their endpoint — a partner, a client, another team — and to control what they can do. Not for the user's own calls: every endpoint already has a default API key, and api_call uses it. Examples: "Give our fulfilment partner read access to orders", "Invite [email protected] to this endpoint", "Stop that partner from deleting records" A collaboration key is one API key with a person and a permission set attached, so access can be narrowed or withdrawn for one partner without touching anyone else. Each one holds two API keys, sandbox and production, activated separately, and permissions are set per environment; deploy copies the sandbox set over production, so a partner on production keeps calling the configuration they were given while sandbox is edited. Most endpoints never need one — reach for a collaboration key only when the API is handed to someone outside. Key values are masked in every response. Full values, the default key's included, are on the endpoint's dashboard page; a masked value fails authentication, so there is no point passing one back. Deleting a key, switching one off, regenerating it, renaming it, and revoking an invitation are dashboard-only. help(topic: "collaborators") has the permission rules and error codes — read it when a call is rejected, not to make one.

collaborators

Create and manage an HTTP endpoint that receives JSON from anywhere — a form, a script, a partner's system, or an AI agent — and stores each record. Records reach the user's own system by webhook, by poll, or by direct read. List, create, update, and deploy your endpoints to production. Use help(topic: "endpoints") for field rules and error codes. Workflow: 1. create — new endpoint 2. api_call — test in sandbox (create already runs the first one for you) 3. update with webhook_url — forward every call to the user's own system. Almost every production user consumes their data this way, so ask for a receiving URL instead of waiting to be asked; help(topic: "webhooks") covers the receiver side. 4. logs — verify results / collaborators — create keys and invite partners 5. deploy — push sandbox config to production (when all testing is done) Be proactive: a one-line intent is enough to create an endpoint. Call create right away — field_definitions is optional. Omit it to create instantly with an empty schema that accepts any payload, or, when the intent implies specific fields, infer a reasonable field_definitions yourself and pass it. Don't ask the user to hand-write field name/type lists. create automatically runs one sandbox test-call and returns its result in the response's testCall field. Report that result instead of repeating the same sample; data the user supplies is a separate call and should be sent. If testCall succeeded, tell the user their API already works, then move to the next step (deploy to production, or the wordpress_plugin tool if they'll use it on WordPress/a blog). Supported: list, get, create, update, deploy, webhook config. Not supported (web only): delete endpoint, toggle active/inactive.

endpoints

Use this when the user asks about their tasks without a specific task id at hand — what is running, what has finished, or what happened to something started earlier, including in a previous conversation. Not for a task's result or error: rows carry neither, and task_get is where they are. Examples: "How did that order I sent go?", "Show my recent tasks", "Is the import still running?" Returns a summary of every task within retention — all statuses, most recently updated first, 25 per page (up to 100) with keyset pagination. Each row has the task id, worker name, status, status_message and timestamps. status and status_message are set by the worker through the status report API, or by 3Min API when delivery fails, 24 hours pass, or the task is cancelled; for a failed task status_message holds the reason.

task_list

Use this when the user refers to one of their workers — by name, by what it does, or by asking what is available — and a worker name is needed to start a task. Not for registering or changing one: that is dashboard-only. Examples: "What workers do I have?", "Send this to our ERP", "Is there a worker that handles invoices?" Returns each worker's name and description, 10 per page with keyset pagination, optionally narrowed by a name search. A worker is an HTTP server the user runs, and it is not an endpoint — a task never touches one. 3Min API delivers tasks to it and the worker reports back. Each worker holds a URL, auth credentials, a signing secret and a callback key that are kept out of AI conversations; none of them appear here. Names are unique per user regardless of letter case. On Free, a worker is removed 7 days after it was registered. Building one: help(topic: "tasks") — read it when writing a worker, not to start a task.

worker_list

Use this when a call did not do what the user expected and the question is why — whether a record arrived, why calls are being rejected, or whether a webhook fired. Not for reading data on a loop: every lookup costs a call and text search returns no payloads, so api_call is the read path. Examples: "Did that test call go through?", "Why are my calls failing?", "Show me orders containing Dana" This is the diagnostic view of stored records. It carries what api_call does not: error_details for rejected calls, webhook_delivery for failed deliveries, and which collaboration key made the call. For reading data as part of normal operation, api_call is the tool. Three modes, one at a time: - record_id — one record with its payload, to confirm a specific call landed. - search_text — find records by text anywhere in the payload. - status "failed" with no search_text — the calls the endpoint rejected, newest first, each with error_details. This is the mode for "why are my calls failing". Text search returns no payloads. To read the contents of several records, api_call(method: "SEARCH") runs the same keyword match and returns whole records — one call rather than one per record. start_date and end_date are optional and default to the last 30 days. Results are cursor-paginated. help(topic: "logs") has the webhook_delivery fields and the error codes — read it when a delivery failed or a call is rejected, not to make a call.

logs

Use this when the user asks what 3Min API is or what it can do, or when something needs a rule the tool descriptions do not carry — an error code, a receiver contract, a plan limit. Not for choosing a tool: the descriptions do that, and reading a topic first only spends a call. Examples: "What is this?", "What does a webhook receiver have to return?", "Why was that call rejected?" Call it with no topic for what the service is and what people build on it. Topics: overview, pricing, endpoints, collaborators, webhooks, api, polling, logs, mcp, tasks. The topics that a tool description points at are the ones worth reading: webhooks and polling for getting records out, and tasks for writing a worker. Those three describe servers the user has to build, which is why they are not in a description. The rest are reference — error codes, field rules, plan limits — and are there when a call is rejected.

help

Use this when the user wants a job handed to one of their registered workers. Not for storing data — that is an endpoint and api_call. A task is work given to a server the user runs. Examples: "Ask the inventory worker to restock SKU 1042", "Run the monthly report on my reporting worker now" 3Min API does not run the job: it delivers the JSON input to the worker as a signed POST and returns a task id with status "working". The worker then sets the status through the status report API — progress messages while working, then completed with a result or failed with an error. Each delivery carries its callback_url, and the callback key it authenticates with is on that worker's own page — dashboard, Tasks, Workers, the worker, Callback key. It is never returned here. A task not reported completed or failed within 24 hours is marked failed, as is one that could not be delivered. The same worker and input sent again within about 2 to 4 minutes returns the existing task unless it failed. input is limited to 100 KB. How the worker receives and reports, and how long records last: help(topic: "tasks").

task_create