---
title: "Agent API Sandbox | Test Mode for Developers | VertoDigital"
description: "A test mode for the VertoDigital agent API: send a contact enquiry to the sandbox endpoint and get production's validation and response shape, with nothing delivered."
url: "https://vertodigital.com/sandbox"
image: "https://vertodigital.com/images/site/og-default.png"
---

> For AI agents: an index of every page on this site is at https://vertodigital.com/llms.txt

For developers & AI agents

# VertoDigital API sandbox.

A test mode for the VertoDigital agent API. Send the request you plan to send in production and get the same validation and the same response shape back. Nothing reaches our CRM or our inbox.

## One endpoint that sends nothing

Only one call in our API changes anything: `POST /agent/contact`, which delivers a real enquiry to the VertoDigital team. The sandbox is its test twin:

- `POST https://vertodigital.com/agent/sandbox/contact`

It takes the same JSON body, applies the same validation rules and returns the same fields. It creates no CRM record, sends no email and stores nothing. You need no API key and no sign-up.

## Send a test enquiry

**Example request**

```bash
curl -X POST https://vertodigital.com/agent/sandbox/contact \
  -H "Content-Type: application/json" \
  -d '{
    "fromName": "Jane Doe",
    "fromEmail": "jane@example.com",
    "organization": "Example Corp",
    "topic": "services",
    "message": "Testing our integration before we send a real enquiry."
  }'
```

A valid request returns `200 { "status": "accepted", "sandbox": true, "reference": "test_8609545381704c3c", "receivedAt": "2026-11-10T12:17:01.966Z" }`.

An invalid request returns the same field-level errors as production: `400 { "status": "invalid_request", "sandbox": true, "errors": [{ "field": "fromEmail", "message": "fromEmail must be a valid email address." }] }`.

## How to tell a sandbox response from a real one

- `"sandbox": true` in every response body.
- A `reference` that starts with `test_`. Production references start with `enq_`.
- An `X-Verto-Sandbox: true` response header.

## What differs from production

- The rate limit is 30 requests a minute per caller IP. It is counted separately from production (5 a minute and 50 a day), so testing never uses up your real allowance. Responses carry the same `RateLimit` headers.
- `Idempotency-Key` is accepted and ignored, because nothing is created to deduplicate.
- There is no `502`. In production that status means delivery failed upstream, and the sandbox has no upstream.

## Everything else is safe to call directly

The rest of the API only reads public content, so there is nothing to sandbox. Call these in production while you build:

- `GET /agent/health` - service health check.
- `GET /agent/case-studies` - the paginated case-study index.
- `POST /ask` - natural-language search over every page.
- The two read-only MCP tools at `https://mcp.vertodigital.com/mcp`.

Two calls do real work and have no test mode. `POST /agent/readiness/checks` starts a real scan of the domain you name, limited to 3 new checks a day. The MCP tool `vertodigital_send_enquiry` sends a real enquiry; it takes the same fields as the sandbox endpoint, so test the request here first.

## Going live

Change the path from `/agent/sandbox/contact` to `/agent/contact`. Nothing else changes.

Add an `Idempotency-Key` header, so a retry after a timeout cannot send the enquiry twice. Send a real enquiry only with the user's consent, using their real name and email.

Full request and response schemas are in the [OpenAPI spec](https://vertodigital.com/agent/openapi.json), under the `sandbox` tag. The rest of the developer surface is on the [Developers page](https://vertodigital.com/developers.md).