Release Notes

Monthly call limits are a lot higher

You asked for higher call limits far more often than for longer retention. So we tightened the data retention policy and moved that headroom into the limits. Basic and Pro both more than triple.

• Basic 30,000 → 100,000 calls a month, Pro 300,000 → 1,000,000
• Production records are kept for at least 60 days (sandbox stays at 30 days, unchanged)
• Usage statistics are kept as they are, so your dashboard charts stay intact
• Archive download is retired. Records inside the retention window are still readable in Logs
• To keep data longer, take it as it arrives — set a webhook, or poll GET /api/v1/data/<your-slug>/poll

Polling now has an endpoint built for it

Clients that wanted new records kept re-reading the first page of the list endpoint — newest first, with no way to say "since when" — so every poll refetched the same records and threw most of them away. There is now a dedicated polling endpoint that returns only what arrived since your last call, oldest first, and remembers where you left off.

• A new endpoint, GET /api/v1/data/<your-slug>/poll — records created since your last call, oldest first, up to 100 per page
• Send the cursor from the previous response back and you never track timestamps yourself. The first call takes since (always UTC) or nothing at all, which subscribes from that moment on
• Every response carries exactly one of two cursors: next_cursor means a backlog remains, so call again right away — poll_cursor means you are caught up, so save it and wait for the next cycle
• The newest ~60 seconds are held back while the queue catches up, so a record is deferred to a later poll rather than skipped
• Retries and restarts can redeliver a record, so process idempotently on the record id
• Covered in the API reference, the sandbox console code samples, and the integration docs

Webhook retries now counted the same way everywhere

Our docs described webhook retries two different ways — some pages counted retries, others counted total attempts — so the same policy looked like 5 or 6 depending on which page you opened. Every surface now says the same number. The receiver contract also spells out what to answer when your own processing fails.

• Production is 6 attempts in total — the first delivery plus 5 retries at 30s, 2m, 10m, 1h, 4h. Sandbox is 4 in total over about 12 minutes
• A 2xx means "I received it", not "it succeeded" — return it even when your own processing fails, and record that failure in your own system
• Keep 5xx for what it actually means: your receiver, or something it depends on, is temporarily down and a later delivery of the same record could succeed
• The retry badge on the logs screen now reads 3/6 instead of 2/5 — the same delivery, counted the way the docs count it
• Nothing about how we deliver or retry has changed — only how we describe it

We now email you when your webhook stops working

A webhook that stops being delivered is silent by design — the data is still stored, so nothing looks broken until someone goes looking at the logs. Now, when every retry is used up, we tell you.

• The email names the endpoint, the response code, the reason, and the body your server returned — the one thing that separates a firewall block from your app rejecting the request
• It arrives when we give up on a delivery — after about five hours of retries in production, or right away when the response is permanent and never retried
• At most one message per endpoint per day, no matter how many calls fail. It says your data is safe, because it is
• Every plan gets this, Free included — production and your own webhook only. Collaborator webhooks are not covered because you cannot change that URL
• There is no recovery notice and no follow-up — fix the receiver and the next call goes through

Event alerts have been removed

The feature that pushed events like webhook failures and usage thresholds to Discord, Slack, or Telegram has been removed. The alerts that matter already go out by email, so there is nothing you need to do.

• The notification card is gone from the endpoint detail page, and the AI tools no longer accept notification settings
• Usage warnings, usage-limit alerts, and deployment request and completion notices still arrive by email — nothing changes there

Failed webhooks now show up in Logs

The Logs screen only ever showed whether we accepted and stored your request. A webhook that never reached your server still read as success, so data could go missing without a trace. Failed deliveries now appear on the same screen.

• A Webhook column marks calls whose delivery failed or is still retrying, with the response code
• A Webhook failed filter narrows the list to calls that have not reached your server yet
• The log detail shows the response body your server returned — the one thing that separates a firewall block from your app rejecting the request
• Every attempt is listed with its time and duration, including automatic retries
• Only failed deliveries are recorded, so a blank cell is not a guarantee of success — the column stays hidden entirely when no webhook is configured

Every webhook now arrives signed

Until now the only way to tell a genuine webhook from a forged one was a fixed auth header — optional to set up, identical on every request, and blind to a tampered body. Deliveries now carry an HMAC-SHA256 signature you can verify.

• Signatures follow the Standard Webhooks spec, so official libraries for 9 languages verify them in about three lines
• Verification is optional — if you already receive webhooks, nothing changes until you turn it on
• Find the secret under Webhook Signing Secret on the endpoint detail screen; sandbox and production are separate
• Reissuing a secret keeps the previous one valid for 24 hours, so you can update your server without dropping a delivery
• Webhooks you receive through your own callback URL are signed too

Webhooks now retry for hours instead of seconds

Webhook retries used to live inside a single request, so all three attempts finished within 24 seconds — a receiver that was down almost never recovered in that window. Retries have moved to a queue.

• Timeout raised from 7 to 15 seconds
• Production retries 5 times over about 5 hours; sandbox 3 times over about 12 minutes
• New X-3minapi-Record-Id header stays the same across attempts — use it to detect duplicates
• A 4xx other than 429 is no longer retried, including 409, which we read as "already received"
• Failed deliveries are now recorded — they will show up in Logs in an upcoming release

Google Sheets integration retired

We removed the built-in Google Sheets integration to keep the service focused on what it does best: receiving, storing, and forwarding your API data.

• Existing spreadsheets stay in your Google Drive — nothing was deleted
• All API records remain fully available in Logs, Stats, and Archives
• CSV export from Archives covers spreadsheet workflows
• The Google Drive permission granted to 3Min API has been released

Search endpoint added

A new API endpoint to find records by text inside the payload.

• Case-insensitive substring matching, min 3 characters
• Optional date range — defaults to the last 30 days
• Cursor pagination (1–30 per page, default 10)

WordPress plugin available (zip install)

Build input forms and data views inside WordPress pages — no code — and wire them directly to 3Min API.

• Distributed as a downloadable zip (manual install)
• Auto-generated snippets for forms, lists, and single-record views

• Explore the WordPress plugin →

List endpoint added

GET without a record_id returns recent records.

• Sorted by created_at DESC
• Cursor pagination (1–30 per page, default 10)

MCP support and ChatGPT Plugins listing

AI agents can call your APIs directly using natural language.

• MCP server auto-provided for every endpoint
• Works with Claude / Cursor / ChatGPT Plugins

• Search "3Min API" on ChatGPT Plugins →

General availability

3Min API is now publicly available with free and paid plans plus full documentation.

Closed beta

Started as an invite-only beta with a hand-picked group of early users.