3Min API

Use this when the user wants a specific person to get access to an endpoint through a collaboration key — the person receives an email, signs up, and accepts on the dashboard. Not for revoking an invitation — that is dashboard-only. Examples: "Invite dana@example.com to the orders endpoint", "Send our partner's developer an invite" Sends an invitation email to the address given, for the collaboration key given; the invitation expires after seven days. The address must be the full one — a masked value is rejected — and cannot be the user's own. Inviting an address whose invitation is still pending sends the email again and restarts the seven days rather than creating a second invitation, unless the key is already at its limit of active invitations; an address that has already accepted is rejected. help(topic: "collaborators") has the invitation limits and error codes — read it when a call is rejected, not to make one.

collaborator_invite

Use this when the user asks who can call an endpoint or what a partner is allowed to do. Not for the full key values — those are shown only on the endpoint's dashboard page. Examples: "Who has access to the orders endpoint?", "What can our fulfilment partner do on production?" Read-only: returns the endpoint's collaboration keys, newest first, ten per page — each with its name and description, whether its sandbox and production keys are switched on, and the operations allowed in each environment. Key values are masked. The row with is_default true is the endpoint's own default key; the others were made for people outside.

collaboration_key_list

Use this when the user asks who has been invited to an endpoint or whether an invitation was accepted. Not for revoking an invitation — that is dashboard-only. Examples: "Did Dana accept the invite?", "Who have I invited to orders?" Read-only: returns the endpoint's pending and accepted invitations, newest first, ten per page — each with its collaboration key, its status, and when it was sent, accepted and due to expire. Invitee email addresses are masked, so sending an invitation again needs the full address from the user.

collaborator_invite_list

Use this when the user wants to see which endpoints they have, or asks whether anything is wrong with them. Not for one endpoint's fields, keys or webhook — that is endpoint_get. Examples: "What endpoints do I have?", "Is anything wrong with my APIs?" Read-only: returns the user's endpoints, newest first, ten per page — each with its name, URL, whether sandbox and production are switched on, and when it was first deployed. The first page also reports what the owner has not been told: an endpoint whose calls keep being rejected, a deleted endpoint that is still being called, this month's calls nearing the limit, and an endpoint due for automatic deletion.

endpoint_list

Use this when the user wants to see the most recent records of an endpoint. Not for keeping up with new records over time: the list is newest first and cannot say "since when", so repeating it fetches the same page again and pays for records already seen. Examples: "Show me the last few submissions", "What's in the orders endpoint right now?" Read-only: returns a page of whole records with their payloads, newest first — 10 by default, up to 30 — and a cursor for the next page when there is one. Each page costs one call against the monthly quota.

record_list

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, delivery and timestamps. status and status_message are set by the worker through the status report API (for a local worker, the CLI calls it), or by 3Min API when delivery fails, 24 hours pass without a report, or the task is cancelled; for a failed task status_message holds the reason. delivery is "pending" until the worker has received the task and "delivered" after, so a working task that is still pending has not reached its worker yet.

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 record_list, record_get and record_search are 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 record_get and record_search do 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, those record tools are the ones to use. 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, record_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 wants what has arrived since a point in time, or is building something that keeps up with new records. Not for showing the latest records once: this reads forward from a point, oldest first. Examples: "Has anything new come in since this morning?", "Set up a sync that pulls new orders every few minutes" Read-only: returns records oldest first, up to 100 per call, after since on the first poll and after the cursor from the previous response on every poll after it — so it is the read that can say "since when", and a client that passes the cursor back never gets a record twice. Every poll costs one call against the monthly quota, including one that comes back empty. help(topic: "polling") has the polling contract — read it when a polling loop is being built, not to make one call.

record_poll

Use this when the user wants an answer computed from task results saved on their PC — a total, an average, the rows that match — rather than the raw results. Not for a result that task_get already returned in full: its result field holds it. Examples: "What was the average price over the last 20 runs?", "Total the amounts in that large export" This tool creates a task for the built-in results reader on the user's PC: it returns a task id with status "working", and the reader reports back the answer, which task_get returns. The reader is a local worker that the 3Min API CLI registers, and it answers only while that CLI is running there. 3Min API picks the PC by host when given, otherwise the PC of the task_id, task_ids or worker given — all on one PC, since a reader sees only its own — otherwise the only PC that has a reader. sql is read-only SQL over one view, results: one row per saved result (per run, for a repeating task) with task_id, run_no, worker, created_at, status, bytes, shape_hash and payload, the result JSON. Only the scope given is visible — worker, task_id, task_ids, since, at least one, combined with AND — and writes or other tables are refused. A JSON path the SQL names that no result in the scope has reads as NULL and is listed in missing_paths. Each call is a new task: it costs calls like any task — at least 4, counting task_get — and shows in task_list. The same input sent again within about 2 to 4 minutes returns the existing task. Which paths a result has, and how to compute over them: help(topic: "tasks"), "Reading a large result".

task_result_query

Use this when the user needs part of a saved task result as it is — the items or text themselves, not a figure computed from them. Not for totals, counts or searches over a result: task_result_query computes those on the PC and sends back only the answer. Examples: "Show me the first 50 items of that export", "Give me the raw text of run 3" This tool creates a task for the built-in results reader on the user's PC: it returns a task id with status "working", and the reader reports back the piece, which task_get returns. The reader is a local worker that the 3Min API CLI registers, and it answers only while that CLI is running there. 3Min API picks the PC by host when given, otherwise the PC of the task_id, otherwise the only PC that has a reader. It returns up to about 90 KB of the value at path — $ by default, the whole result — starting at offset: array elements, object keys or text characters, with total and next (null at the end). run_no picks one run of a repeating task, the latest without it. Each call is a new task: it costs calls like any task — at least 4, counting task_get — and shows in task_list, and each piece waits until the CLI fetches it. The same input sent again within about 2 to 4 minutes returns the existing task. Reading in pieces: help(topic: "tasks"), "Reading a large result".

task_result_read

Use this when the user wants the records that contain some text — a name, an email, an order number — anywhere in their payload. Not for records older than 30 days, which this search does not reach, nor for finding out why a record failed: delivery state is not part of a record. Examples: "Find the order from dana@example.com", "Any submissions mentioning refund?" Read-only: matches q as a case-insensitive partial match across the whole payload of the last 30 days of records, and returns whole records — 10 by default, up to 30 per page — with a cursor for the next page. Each page costs one call against the monthly quota.

record_search

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, cli. The topics that a tool description points at are the ones worth reading: webhooks and polling for getting records out, tasks for how a task runs and for writing a public worker, and cli for setting up a local worker. Those cover what the user builds or sets up, 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 to change what a partner's collaboration key may do in one environment — allow or stop creates, reads, updates or deletes. Not for the endpoint's own default key, whose permissions cannot be changed, nor for switching a key off, which is dashboard-only. Examples: "Stop that partner from deleting records", "Let the client only read on production" Replaces the key's allowed operations for the environment given with the list sent — nothing is added to what was there. The change applies from the key's next call, so an operation left out is refused from then on. Deploy copies each key's sandbox set over production, so a set narrowed only on production is widened again by the next deploy. help(topic: "collaborators") has the permission rules and error codes — read it when a call is rejected, not to make one.

collaboration_key_set_permissions

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

Use this when the question is about the user's own account rather than one endpoint — which plan it is on, how much of this month's quota is left, and when it resets. Not for changing anything: plans are changed on the dashboard, and this only reads. Examples: "What plan am I on?", "How much quota do I have left?", "When does my usage reset?" Takes no arguments; the account comes from authentication. Returns the current plan with its monthly limit and retention, the billing period, and usage (used, limit, remaining, percentage). usage.status is normal below 80% of the limit, warning from 80% until the limit is passed, and exceeded once usage is over it. A short grace margin past the limit keeps work already in flight from being cut off; beyond that the record tools (record_create, record_list and the rest), logs and the task tools are rejected until the period resets. Retrying does not clear that; only the reset does. An account with no subscription at all comes back as noSubscription. How the limits and data retention work: help(topic: "pricing").

subscription

Use this when the user wants to change an existing endpoint — rename it, edit its description, change its fields, or set or clear its webhook URL. Not for deleting an endpoint or switching it on or off — those are dashboard-only. Examples: "Add a phone field to orders", "Send the contact form to https://example.com/hook", "Stop the webhook on orders" Changes only the fields given. field_definitions replaces the whole sandbox field list and each declared field becomes required on later sandbox calls; production keeps the fields it was last deployed with until the next deploy, and an endpoint never deployed has none — production rejects its calls. webhook_url applies to the environment given, sandbox when omitted. The webhook's auth header is not settable here and lives on the dashboard. A header already saved there keeps being sent when the URL changes, but clearing webhook_url clears that header too, and only the dashboard can set it again. help(topic: "endpoints") has the field name rules and error codes; help(topic: "webhooks") has the receiving contract — read them when a call is rejected or the receiver is being built, not to make a call.

endpoint_update

Use this when the user wants to change a record that already exists. Not for adding a new record. Examples: "Mark that order as shipped", "Fix the email on the last contact" Replaces the record with body as a whole — every field left out of body is erased — so changing one field means reading the record first and sending it back with that change applied. Accepted asynchronously: the response is 202 and the change is written a few seconds later. If the endpoint has a webhook for that environment, the updated record is delivered to that URL. Each call costs one call against the monthly quota, and sending it again delivers it again. help(topic: "api") has the error codes — read it when a call is rejected, not to make one.

record_update

Use this when the user asks how much their endpoint has handled — this month, a past month, or whether the volume justifies a plan. Not for finding a particular call: these are counts, not records. Examples: "How many orders came in this month?", "Was August busier than July?", "Am I close to my limit?" Returns a monthly summary (total, success and failed calls, success rate, average response time) and a per-day breakdown of creates, reads, updates and deletes. available_months lists the months that have data, and one call covers one month, so comparing two means calling twice. avg_response_time_ms covers creates, updates and deletes only — reads are excluded, so it does not move when read traffic does. Figures can lag a little behind live traffic. They are never deleted, so a month stays readable long after its records are gone — the numbers outlive the data they came from. A month with no traffic comes back with summary null and daily_stats empty — that is not an error. month must be YYYY-MM; anything else is invalidMonthFormat. An endpoint that is not yours is endpointNotFound.

stats

Use this when the user mentions WordPress, a blog or a WP site — or picks WordPress as where their API will be called from. Not for writing the snippet itself: this returns the prompt to generate it from, and the generating is yours. Examples: "Put this form on my WordPress site", "Show submissions on a page of my blog", "How do I use this with WordPress?" The 3Min API Connector plugin drops an endpoint into any post or page through a [3minapi] shortcode. Call with no section for an index and the code-generation workflow; section "overview" for the plugin and its URL, "usage" for the user guide, and "ai_codegen_prompt" for the system prompt that generates snippet code — a verbatim mirror of the plugin's own "Copy AI prompt" output, so generated code follows the same rules. Snippets come in three shapes, set by method: get_record, get_list and post. PUT and DELETE are not shapes of their own; they are JavaScript helpers available inside a get_record or get_list snippet. The plugin needs the raw API key value, which every MCP response masks. The user copies it from the endpoint's dashboard page — a masked value fails authentication.

wordpress_plugin