Skip to content
ESEN

Cord Workbench

Build, test and debug your integration without leaving Cord: every request, every error, every event and every delivery in one panel.

What is it?

The Workbench is Cord’s developer console. It lives at the bottom of the app as a Developers pill and, when you open it, expands into a panel with eight tabs: Overview, Logs, Errors, Events, Webhooks, Shell, API keys and Health. The panel’s top bar holds the Inspector, which finds any ID.

API keys, webhooks, logs and events live here. MCP, Artificial intelligence and Embeddable quote builder are still in Settings, under the Developers section of the index, because they’re one-time configuration.

Requirements

  • Settings permission on your role. Without it, the Workbench doesn’t show up.
  • Developer mode turned on. It’s a preference of your account, not of the organization.
  • It’s on every plan. Webhook delivery history, Retry and Resend require the Professional plan or higher.

Turning it on

  1. Go to Settings and scroll to the bottom of the category index.
  2. Turn on the Developer mode switch.
  3. The Developers pill appears in the bottom-right corner, across the whole app. Click it, drag it upward or press W.

Developer mode follows you on any computer where you sign in with your account. You can also change it in Your preferences. A link with ?wb= or ?wbi= (see Direct links) also turns it on.

The panel

The Workbench open at half height over Quotes, on the Overview tab for the last 7 days in live mode: 2,523 API requests with a 1.9% error rate, 412 ms p95 latency and 99.5% of webhook deliveries succeeded; the top errors by code, where requests come from, recent activity, no active alerts and 3,412 of 5,000 requests used this month.
  • Size. Drag the top handle to make the panel taller or shorter; drop it near the bottom to close it.
  • Full screen. The button next to Close expands the panel to the whole window. Exit with the same button, with ⇧W or with Esc.
  • Options (⋯). Show times in UTC switches every date in the panel instantly without touching your account’s time zone. The menu also lists the keyboard shortcuts and links to this guide and to the OpenAPI spec.
  • Environment. The Workbench shows the environment the app is in. In the test environment you see what your sk_test_ keys and the Shell in Test did; in live mode, what your live keys did. Overview marks it with a Test or Live label.
  • The panel remembers, in this browser, whether it was open, the tab, the height, full screen and the UTC option.

Keyboard shortcuts

Key What it does
W Opens or closes the Workbench.
⇧W Full screen.
/ Puts the cursor in the Inspector.
1 to 8 Goes to the tab with that number, in the order of the bar.
J / K Next or previous row in Logs and Events.
⌘↵ (Ctrl+↵ on Windows) Sends the Shell request.
Esc Closes whatever is open: menu, dialog, Inspector, full screen and, last, the panel.

Single-letter and number shortcuts don’t fire while you’re typing in a field. On screens narrower than 880 px there are no single-key shortcuts and the panel opens as an edge-to-edge sheet; on the narrowest ones, the Inspector is an icon in the top bar that expands when you tap it.

The tabs

Overview

The landing view, with a period of 24 hours, 7 days or 30 days:

  • Indicators: API requests, error rate, p95 latency (with p50 below) and the share of webhook deliveries that succeeded.
  • Requests over time: bars of succeeded and failed requests.
  • Top errors: the five most frequent codes. A click opens Logs filtered by that code.
  • Where they come from: requests by source. A click opens Logs filtered by that source.
  • Recent activity: the last six requests.
  • On the right: the health card (it takes you to Health), API usage this month against what your plan includes, getting started steps while there are no requests in the period, and developer resources.

Only calls made with live keys count toward this month’s usage: test and Workbench calls don’t use your quota.

Each request’s source comes from the client that made it:

Source When
Node SDK, Python SDK, PHP SDK, CLI Cord’s SDK or CLI identified itself in the request.
cURL The request came from curl.
MCP A call to the MCP server.
Cord Elements A publishable key (pk_), like the one Cord Elements uses.
Connected app An app authorized through OAuth, like Zapier or Make.
Workbench The Shell.
HTTP Any other client.

Logs

Every request that reached /api/v1 and the MCP server, in a list with its detail on the right. MCP calls show the tool, for example /mcp/tools/call:listar_productos.

The Workbench in the test environment, on the Logs tab: the quickstart requests made with cURL and the test key, one with the invalid_request error and one from the Workbench Shell, and the detail of POST /v1/cotizaciones (201, 184 ms) with its request id, version 2026-10-01, Test mode and the Copy as cURL and Open in Shell buttons.
  • Search by route, by request id (req_…), by error code or by an exact Idempotency-Key. A request id is searched across the whole history, regardless of the period.
  • Filter by method (GET, POST, PATCH, DELETE), by status class (2xx, 4xx, 5xx), by key (or only the Workbench’s), by source and by period (1 hour, 24 hours, 7 days or 30 days).
  • Live adds new requests at the top every few seconds while the tab is in view. Load more brings the next 50.

A request’s detail shows the status, the error code with its message and a How to fix it link to Errors, the request id, the date, the latency, the key, the source, the API version, the mode, the IP and the Idempotency-Key. If Cord returned the stored response of a repeated request, it’s marked as Replayed response, and below it lists the other requests with the same Idempotency-Key.

  • Copy as cURL copies the request ready to paste into your terminal: the Authorization header reads your key from the $CORD_SECRET_KEY environment variable. The body isn’t included because it isn’t stored.
  • Open in Shell loads it in the Shell with its parameters. In live mode it only appears for GET requests.
  • Inspect the resource opens the ID in the route in the Inspector.

Cord doesn’t store the body of API requests or responses, only their metadata. Storing them would mean keeping your customers’ data (tax IDs, emails, amounts) on every call. To see a full response, repeat the operation in the Shell or check your own server’s log.

Each request is kept for 30 days. A daily job deletes anything older, so the longest period in Logs, Errors and Overview is 30 days. The deletion runs through a database function that only removes records older than 30 days; not even Cord can use it to delete anything more recent.

Errors

Failed requests grouped by code, method and route, with the IDs in the route replaced by {id}, so you see the cause and not every row. Period of 1 hour, 24 hours, 7 days or 30 days. A request without its own code shows up as http_ plus its status.

Each group shows how many times it happened and when it last did. Opening it shows the last error message, the path, the first and last time, how many keys caused it and three actions: View requests (Logs filtered by that code), View an example (the most recent request in the Inspector) and How to fix it.

Events

Your business’s event history: the same one GET /api/v1/events returns, even if you don’t have any webhook.

  • Filter by event type, by delivery status (Failed, Queued, Delivered) and by the object’s ID. Live and Load more work the same as in Logs.
  • Each row shows the status of its deliveries, the type, the object, who triggered it (API, MCP, Dashboard, Workflow, Workbench, Integration or System) and the date.
  • The detail shows the event ID, the date, the object (a click opens it in the Inspector), who triggered it with the name of the key or person, the event data and one delivery per subscribed endpoint: URL, status, attempts, next attempt, the evt_… that endpoint received and the last error.
  • Resend sends a delivery again with the same payload and the same evt_…, so your server can deduplicate it. With more than one failed delivery, Resend failed ones appears. Both require the Professional plan or higher.
  • The event’s status comes from the latest delivery to each endpoint: a successful resend replaces the failure. A delivery Cord canceled because it disabled the endpoint shows as Canceled, not as delivered.

Internal events, like quote.expiring or invoice.due_soon, carry the Internal label: workflows use them and they aren’t sent through webhooks. Test deliveries (an endpoint’s Test button or the simulator without objeto_id) aren’t events of your business: they don’t show up here, only in the endpoint’s deliveries.

Webhooks

Your endpoints, with your plan’s allowance. Add endpoint opens a full-screen wizard:

  1. Choose events. The 42 catalog events, grouped by family, with search and a checkbox to select a whole family. All events also includes the ones Cord adds later; if you select none, you receive all of them.
  2. Configure the destination. A public https:// URL.
  3. Save the secret. The signing secret (whsec_…) is shown only once. From there you can also Send test event.
The Workbench Webhooks tab in full screen: the ERP endpoint with 93.1% successful deliveries in 7 days, expanded into its deliveries; the latest one, quote.approved on its second attempt, failed with a 500 and shows the exact payload Cord sent, what the server answered and the Retry and View the event buttons.

Each endpoint shows its masked secret, how many events it receives, its last delivery and the last 7 days: deliveries per day, success rate and p95 latency. Its actions:

  • Test sends ping or any of its subscribed events with sample data, in the API version the endpoint is pinned to. The payload carries "test": true at the top level so your server can tell a test apart from a real event.
  • Edit, Rotate secret (with a 1, 24 or 72 hour window in which both secrets stay valid), enable or pause, and Delete.
  • Reactivate or Reactivate & retry when Cord disabled the endpoint after a failure streak. The second one requeues what failed in the last 24 hours.
  • Expanding the row shows its last 50 deliveries. Each one opens what Cord sent (the exact payload) and what your server answered (up to 2,000 characters), with Retry and, if it came from an event, View the event.

The full guide (payload, signatures, catalog and retries) is in Webhooks.

Shell

Runs any public API operation with your session, without creating a key.

  • Test runs on your test environment: you can create and change things without touching real data, and use the test simulators.
  • Live · read only reads your real data: it only lets you send GET operations.
  • Operations tied to a key (webhook endpoints through the API and cord listen sessions) and the ones that stream their response or upload files don’t run in the Shell.

Pick an operation from the list (with search), fill in its parameters and its JSON body, which comes with an example, and send it with Send or ⌘↵. Under Optional headers you choose the API version (Cord-Version). The response shows the status, the latency and the request id, and has three views: Response (up to 200 KB), Headers and Code, with the same request in cURL, Node SDK, JavaScript (fetch) and Python, using your key as $CORD_SECRET_KEY. Recent keeps your last 15 calls for this organization in this browser.

Every Shell call shows up in Logs with the Workbench source and doesn’t use your plan’s API quota. A click on the request id opens it in the Inspector. If you ran it in a different environment than the app’s (for example, in Test with the app in live mode), the request id is only copied: switch the app’s test mode to see it in Logs.

API keys

The Workbench API keys tab in full screen: at the top, 3,412 of 5,000 API requests used this month and version 2026-10-01; below, secret, restricted and publishable keys in live and test mode, each with its masked token and last 4 characters, permissions, last use, creation and expiration date, plus an OAuth connection and a revoked key.
  • API usage this month against what your plan includes, and the current API version. Every key and webhook is pinned to the version of the day it’s created; the Cord-Version header overrides it per request. See Versions.
  • API keys: generate, edit, roll and revoke secret (sk_), restricted (rk_) and publishable (pk_) keys, in test or live mode. Each key has a Logs button that opens its requests from the last 7 days. Apps authorized through OAuth show up as an Authorized connection. See API Keys.
  • API reference: every operation, grouped, with a curl example, a Try it button on the ones that can run in the Shell and the button that generates an integration prompt for ChatGPT or Cursor.

Health

A list of active alerts, each with a link to the tab where you fix it:

  • an endpoint that’s disabled or has 3 or more failures in a row;
  • events that ran out of retries and overdue retries in the queue;
  • an error rate of 5% or more with at least 20 requests in 24 hours;
  • 5xx errors in the last 24 hours;
  • a key that expires, or a rolled key that stops working, in the next 7 days.

Below, three cards: the status of each endpoint (active with its success rate and p95, paused, disabled or with failures in a row), the event queue (queued, overdue retries, exhausted and p95 delivery) and API in the last 24 hours (requests, error rate, 4xx, 5xx and p95 latency).

Inspector

Paste an ID into the search box in the panel’s top bar, or press /:

  • a request id (req_…) opens that request;
  • an event id (evt_…) opens the event behind it, or tells you it was a test delivery;
  • the ID of a quote, invoice, client, product, key, webhook endpoint or event.

For an object you see its type, its name or folio, the events that mention it and the requests from the last 30 days that touched it (or that the key made). Open in Cord takes you to its page when it has one, and on a quote, invoice or client, See it as the API returns it opens it in the Shell. Back or Esc return to the tab.

  • /app?wb=registros opens the Workbench on that tab. The names are resumen (Overview), registros (Logs), errores (Errors), eventos (Events), webhooks, shell, api (API keys) and salud (Health).
  • /app?wbi=<id> opens the Inspector with that ID.

Both turn on Developer mode if it was off.

FAQ

Why don’t I see a request I made with a test key? The Workbench shows the environment the app is in. Switch to the test environment to see what your sk_test_ keys did.

Does the Workbench count against my API quota? No. Browsing the panel doesn’t call your API, and Shell calls don’t count either. Only requests made with live keys count.

Why does Events show events even though I have no webhooks? Because it reads your business’s event history, not the deliveries. Without endpoints, each event shows up as No endpoints.

Why can’t I see an endpoint’s deliveries? Delivery history, Retry and Resend require the Professional plan or higher. Creating endpoints, receiving events, Test, Rotate secret and Reactivate are on every plan.

How long are logs kept? 30 days from each request. If you need a longer history, store the request id (Cord-Request-Id) and the response in your own system.

Does my team see the same thing I do? Yes. Any member with the Settings permission sees the organization’s data. What’s personal is Developer mode, which goes with your account, and, in each browser, the panel’s size and the UTC option. The Shell’s recent calls are kept in each browser per organization.