Changelog

Read what changed for users and integrations. Breaking marks an update you must make. For setup and field details, follow the linked guides.

Support revision: envoy@2026-10. Last updated: 3 November 2026.

3 November 2026 · Checkout progress and skills 0.4.15

Changes

• Agent checkout can report reached steps with report_checkout_step, when the connected server offers it. Reporting a step does not replace the result report.
• Installation guides describe thirteen default tools, nine for Claude connectors and eight for ChatGPT. Skills and plugins are prepared as version 0.4.15.

1 November 2026 · Follow gift cards without guessing

Changes

• The gift-card guide separates six facts: purchase identity, money, voucher progress, next actor, permitted action and checking time.
• Discovery guidance uses returned denominations, amount ranges and redemption location. Funding guidance covers balance approval, payment links and in-app payment.

Fixes

• Missing captured/refund amounts, funding sources, voucher phases and escalation times are reported as unknown. Face value and payment-link price are not treated as settled money.
• Agent-page app tasks identify the gift-card value separately from the amount the app asks the user to pay.

28 October 2026 · Current purchase and recovery guidance

Changes

• The purchase walkthrough now explains gift-card payment links, voucher redemption and product discovery when available. It distinguishes the voucher's value from the amount the user pays.
• Checkout recovery explains the linked replacement and the card closure and refund it waits for. Follow the server's recovery instruction before another payment.

Fixes

• Vault guidance identifies this purchase's exact saved card and explains the missing-entry fallback before any payment attempt.
• Account reads, ready credential releases, merchant orders and refunds have separate explanations. The guides no longer promise a refund date from a failed checkout alone.

26 October 2026 · Money held in open purchases

get_account now returns held_purchases by default. It reports the money in open agent purchases, which has been taken from the balance but not yet spent at the merchant, separately from the bank-held held amount. Items show an exact amount, an upper bound, or an unknown amount. An unsupported read is reported as unavailable, never zero. Refresh closed-schema clients before relying on the new field. See Account and transactions.

25 October 2026 · Instinct connection setup

Changes

• Instinct setup uses a short browser sign-in request, user approval in the Envoy app and confirmation of account access. Setup stops before a purchase or card save.
• Agent setup and reconnect links retain the host in the URL path, so host attribution does not depend on a query parameter surviving.

Features

• Agents can report a blocked connection without signing in when support reporting is configured. Reports contain fixed choices only and confirm queue acceptance separately from connection success.

15 October 2026 · Easier documentation navigation

Changes

• Choose Use Envoy, Build with the API, Reference or Help in the sidebar. Each section has a short tree for its audience. Existing page links still work.
• Find skills and downloads together under For AI agents. The FAQ links to credential rules, eligibility and the glossary.

Fixes

• Shared documentation links include the Envoy preview image.

14 October 2026 · Credential rules and skills 0.4.8

Changes

• Update to skills 0.4.8. The skills no longer collect a merchant password or a bank OTP in chat.
• No merchant passwords through chat. Envoy never asks for a merchant password. When Envoy's checkout reaches one, the reply stops and says so; the user can cancel and buy on the merchant site. A merchant sign-in code (otp) still goes through submit_answer.
• Bank OTPs stay with the user. An agent no longer asks the user to type a bank OTP. The user completes the bank step, or enters the code in the Envoy app. The earlier Instinct vault exception is superseded by the 15 October guidance below.

14 October 2026 · Checkout identity and code windows

Additive. A card handout can include checkout_attempt_id. Include that exact value when reporting its checkout result. When a code expiry is supplied, refresh it on the same purchase before submitting a payment. Refreshing a code does not extend spending access. An uncertain payment still stops another attempt. Skills and plugins 0.4.7 teach these rules and no longer collect bank OTPs in chat.

Fixes

• Approval polling and checkout reports continue correctly. MCP replies preserve the requested delay between status calls. Checkout reports return a valid status continuation when reads do not hold. If a report reply fails, the agent checks the same purchase before any retry. See Replies and next steps and Recover a purchase.

Current versions

• Tools: envoy@2026-10, available over MCP and HTTP.
• Skills and plugins: 0.4.15. Install or update from Host connections and Downloads.

15 October 2026 · Checkout reports and skills 0.4.11

• Report paid or failed only. If the merchant outcome is unclear, report failed with failure_reason: other. Envoy reconciles the payment before another attempt.
• No cancellation after a checkout report. Envoy refuses cancel_purchase after any report. Follow status until money is settled and the previous card is terminal before a retry.
• Vault sign-in follows the reply. For an open otp question, the agent relays the user's Instinct vault sign-in code once through submit_answer. For an enter_otp user task, the user enters it in the Envoy app. Bank and payment OTPs stay with the user on the merchant page or in the Envoy app.

15 October 2026 · Clearer purchase tools and skills 0.4.10

• The purchase tool and skill describe when to use Envoy. Tool hints now flag purchase and checkout-report effects. Briefings give the next action without directing the assistant to keep a conversation turn open.
• Card checkout guidance covers retry_of and checkout_attempt_id, and explains that a failed report does not itself close the card. An uncertain checkout is reported as failed with failure_reason: other. Check status before another payment.
• Bank and payment OTPs stay with the user, including when saving a card to the Instinct vault. The user enters them on the merchant page or in the Envoy app as instructed. Public contract downloads omit internal launch notes.

14 October 2026 · Account reads and skills 0.4.6

Changes

• Report only paid or failed. If you cannot tell whether checkout completed, report failed with failure_reason: other. Envoy checks the payment outcome before it allows another attempt. Agents cannot cancel a purchase after any checkout report. See Report the result.

Fixes

• An unreadable purchase no longer hides the balance. When Envoy can't read the purchase in progress, get_account still returns the balance, leaves out active_purchase and lists it in unavailable. Read that as unknown, not as no purchase: don't start a new purchase until a later read shows it. See Account. Skills 0.4.6 say the same.

October 2026 · Envoy tools and skills 0.4.5

Features

• Start with a read-only success check. The docs home now leads with host, browser-agent and custom integration paths, followed by a short guide to a successful get_account call.
• Browser agents can use Envoy. Agents with browser access can connect and manage purchases through Envoy's agent pages.
• Envoy can complete checkout. Each purchase identifies who pays through checkout_by. Follow the payment walkthrough.
• Questions and feedback use one tool. submit_answer sends the user's reply to Envoy. Purchases can ask for missing details or an answer; completed purchases can request optional feedback.

Changes

• Breaking — refresh your tools and skills. submit_answer replaces add_purchase_details, answer_purchase_question and submit_feedback. Refresh the host's tool list and install skills 0.4.5. Custom integrations must handle needs_answer and send answers through submit_answer.
• Breaking — use the current addresses. Connect MCP at https://api.envoy.money/mcp; send HTTP calls to https://api.envoy.money/tools/{tool}. Browser agents use https://agent.envoy.money/agent-interactions and must reconnect there once.
• Breaking — update browser page readers. Agent pages now show one next step, one deadline and compact pre#page-data. The old pre#envoy-reply and pre#page-actions are removed. Update selectors using the browser guide; ?format=json still returns the full reply.
• Breaking — migrate older integrations. Contract 1 endpoints and packages are retired. Follow Migrate from contract 1.
• Clearer MCP replies. Results give a user-facing briefing, the next action and only the JSON needed to continue. Skills follow that action and keep codes and identifiers out of user-facing messages.
• Personal data has its own marker. In the MCP tool list, get_account's data.account.profile and data.account.addresses moved from _meta.secretPaths to _meta.personalPaths (OpenAPI: x-envoy-personal-paths). secretPaths now lists only one-time card details. If your host reads secretPaths to redact logs, also read personalPaths.

Fixes

• Approval polling and checkout reports continue correctly. MCP replies preserve the requested delay between status calls. Checkout reports return a valid status continuation when reads do not hold. If a report reply fails, the agent checks the same purchase before any retry. See Replies and next steps and Recover a purchase.

• Checkout-code delays no longer look like a failed purchase. Envoy tells the agent to wait while the issuer prepares the code.

September 2026 · Earlier releases

These changes describe the retired contract 1 integration. Use the migration guide above for current setup.

Changes

• Purchases use per-purchase cards, explicit connection consent and user approval. Older reusable-card and voucher guidance was removed.
• Bank OTP steps belong to the user. An uncertain checkout requires recovery before another payment.

Fixes

• Card delivery can recover from a slow or unavailable checkout-code read while preserving authorization checks.
• Recovery keeps the original purchase and request identifiers after lost replies, replacement attempts and late reports.
• Errors give clearer reasons and next steps. Reusing a request key with different inputs reports a conflict.