Introducing the new Apideck developer docs

The new Apideck developer docs are live at developers.apideck.com. They start from the integration you are building instead of from a list of APIs, and they are written for two readers: you, and the coding agent you hand part of the work to.

Most teams don't come to an API reference wanting an endpoint. They come wanting to sync invoices into their customers' QuickBooks, or to read employees from an HRIS. The old docs made you translate that job into resources yourself. The new docs do that translation for you.

Start from what you're building

The use-case catalog lists 37 use cases across 6 APIs, 22 of them in ERP and accounting. Pick the one closest to your product. 26 have an implementation guide that walks through the calls in order, and 14 link to a demo app that runs on sample data, so you can see the requests and responses before you write any code.

From a use case, the API reference opens filtered to the operations that job needs. For accounts payable, the Accounting API's 186 operations across 43 resources narrow to 36 operations across 9, with a link back to the full list when you need it.

When you are ready to write code, the first API call page walks through one read in eight languages, cURL included, and covers the usual reasons a first call fails, such as an access error or an empty result.

Know the connector before you commit

A connector's overview page opens with an At a Glance table: how auth works, whether the vendor needs a partnership or an app review, and whether there is a sandbox. Next to it, a gotchas page lists the connector-specific behaviour and limits to plan for, so you don't find them in production. The QuickBooks gotchas page has 75 of them across 37 resources. One example: QuickBooks returns a bill line's class as "Fruit:Apple", and Apideck splits it into the name "Apple" and the parent "Fruit".

The gotchas come from the same OpenAPI specs that drive the API, so the page and the API say the same thing. Bernard Willems wrote about these pages when they first shipped, in new connector documentation: the answers you need before you build.

Try a call before you write one

The API Explorer has long been a favorite with developers. Pick a Unified API and an operation, fill in the parameters with schema validation, and send a real request against a consumer's connection. It also takes a link to one operation, so the reference can open, say, Accounting's List Invoices with the form ready.

The MCP Explorer does the same for agents. Pick a server mode, find a tool, read its input schema, and see the exact JSON-RPC an agent sends. Browsing needs no API key. Running a tool is read-only by default, so write and destructive tools stay off until you switch them on, and destructive tools ask a second time. Every operation in the API reference links to its MCP tool.

The Explorer also shows what each server mode costs an agent's context. Dynamic mode, the default, starts with four meta-tools and about 1,300 tokens, against 35,000 to 55,000 tokens for static mode, which registers every tool up front. We wrote about why that matters in your MCP server is eating your context window.

Docs your coding agent can read

If an agent writes part of your integration, it now reads the same docs you do, without a browser:

• Add .md to any docs URL, or send Accept: text/markdown, and the page comes back as Markdown. "Copy page" puts it on your clipboard.
• llms.txt indexes the docs and tells agents what to do first, such as using the current SDKs and checking connector coverage before assuming an operation is supported.
• Each use case has its own Markdown index of the operations it needs, with links to the guide and to coverage.
• The docs run their own MCP server. It needs no API key and only reads documentation, through tools such as search_docs and get_operation_context.

Adding the Docs MCP server to Claude Code takes one command:

claude mcp add --transport http apideck-docs https://developers.apideck.com/mcp

We tested this the way it will be used: we gave coding agents bounded tasks against the docs, such as reading one employee record or a page of orders, and read the traces. They caught things a page review misses. One operation's Markdown left out the bearer authentication it inherited from the API, so the agent went searching other pages before it could make the call. Authentication now travels with every operation. Full operation pages also expanded nested response schemas that a simple read doesn't need, which is why get_operation_context returns just the auth and request requirements with a short response summary. So far the tests cover known read tasks; writes and error recovery haven't been tested yet.

This builds on the API design principles for the agentic era we published in February, and on the Apideck MCP server, which is generated from the OpenAPI spec.

Faster, and easier to read

The docs also moved to a new foundation and a new look. Pages load less JavaScript, guides and the API reference fit a phone screen, lines are a comfortable length to read, and dark mode works on every page. Old reference links still redirect to the right page and keep your chosen code language.

Get started with the Apideck developer docs

Open the use-case catalog, pick the job closest to yours, and follow its guide into the filtered reference before you open a connector page. If an agent writes part of your code, add the Docs MCP server before the first prompt.