Connector validation
Prove a connector against your own sandbox or authorised account, see exactly what "validated" means and keep the result as evidence.
Updated 09/10/2026
On this page
What "validated" means
A validated connector has been proven against a real provider account with real credentials, not only against recorded responses. Nexra reports four levels, each with its own evidence, and never merges them:
| Level | What it proves |
|---|---|
| Implemented | The adapter is registered and can be connected. |
| Fixture tested | It passes Nexra's conformance suite against provider-shaped responses for every operation, including pagination, authentication failures, rate limits, write gating and duplicate safety. |
| Sandbox validated | A credential-backed run passed against a connection marked sandbox within the last 90 days. |
| Authorised-account validated | A credential-backed run passed against a connection marked production within the last 90 days. |
Validation stays current: a pass counts for 90 days. After that the connector is shown as due for a re-run, keeps its full history, and returns to validated as soon as a new run passes. Each operation also earns its own level, so an operation that passed is validated even when another part of the plan needs attention.
Only runs on connections marked sandbox or production count. Demo and sample connections are recorded separately and never count towards a level.
What a pass proves
A run passes when:
The health check passes. The connector's health operation, or the connection test, makes a real call to the provider.
One read per data type passes. For each data type in the plan, a list (or search, or get) succeeds and the records match the connector's declared shape: required fields present and declared fields of the declared type.
Every data type is covered. A data type the connector deliberately skips carries a documented reason, and skips can cover at most half of a connector's data types.
Reads use safe default inputs and read at most two pages of five records. When a read needs an identifier that only exists in your account, for example a channel inside a team, the plan takes it from the first record of another read in the same run. The value stays in memory for that run only and is never stored.
A data type whose read succeeded but returned no records is flagged: the call works, and adding a few records to the sandbox lets the next run check their shape too.
Sandbox writes, only if you opt in
Some connectors list safe writes that prove the write path, such as creating a draft invoice or a test contact with synthetic data. They run only when all of these hold:
the connection is credential-backed and marked sandbox;
the write is switched on for the connection;
you opt in and confirm the run by typing the connection name (over the API, by sending the connection ID).
Validation writes are never R3 or R4, never billable, never send a message to a person, never delete, cancel, refund, pay or transfer, and never upload files. Each write runs once through the governed-action gate, so your policies and approvals apply, and is never retried.
Run it in the console
Open Connect → Connections and make sure the connection is active (test it first).
Choose Validate. Review the plan: the health check, the data types it will read and any sandbox writes on offer.
Choose Run validation.
The result shows the health check, reads by data type with latency, record counts and shape, and What a pass proves for that run. Each run is written to the evidence chain and appears in the connection's run history and on Prove → Overview.
Runs are paced so they never crowd out real work: one at a time per connection, at least 10 minutes apart on one connection, and up to 50 per workspace in 24 hours. When a run is refused, the console says when the next one is available.
What Nexra keeps
For each step Nexra stores the status, latency, HTTP status class, record count, pages read and the field names and types it saw. Errors keep a category, a safe code and a redacted message. Record contents are never stored, and finished runs cannot be changed.
| Step status | Meaning |
|---|---|
passed | The call succeeded and the records matched the shape. |
shape_mismatch | The call succeeded but a record did not match the shape. |
failed | The call failed. |
skipped | The step did not run, with the reason. |
approval_required | A sandbox write needs approval under your policies. |
denied | A sandbox write was refused by your policies. |
Run it over the API
| Method | Path | Permission |
|---|---|---|
GET | /api/console/connect/connections/:id/validation-plan | connect.connection.read |
POST | /api/console/connect/connections/:id/validation-runs | connect.connection.test, plus connect.connection.update for sandbox writes |
GET | /api/console/connect/connections/:id/validation-runs | connect.connection.read |
GET | /api/console/connect/connections/:id/validation-runs/:runId | connect.connection.read |
GET | /api/console/connect/validation/runs?limit=&cursor= | connect.connection.read |
GET | /api/console/connect/validation/levels | connect.connection.read |
A read-only run:
POST /api/console/connect/connections/<connection id>/validation-runs
Content-Type: application/json
{}A run with sandbox writes:
{ "includeSandboxWrites": true, "confirm": "<connection id>" }The workspace runs list returns {runs, nextCursor}, newest first, 25 per page by default (up to 100).
Next
Connections: create and test the connection you validate.
Prove overview: verify and export the evidence each run leaves.