npx verifyport add notion Open · MIT-licensed · runs entirely on your machine Open a connector →
See what a connector can actually do.
Audited API connectors for Python, Go, and Node. Each one declares, tool by tool, which dangerous actions it can take and which fields you can constrain — and ships a dependency-free verifier so you can re-prove all of it offline, yourself.
Source lands in your repo Per-tool risk flags Offline verifier included Python · Go · Node
Anatomy
What lands in your repo.
A connector is a folder of plain source you own — the audited client in three languages, the risk map, and the verifier that re-proves it. Nothing to import at runtime, nothing that calls home.
stripe/
├── manifest.json tools + per-tool risk axes + per-field constrainability — the safety map
├── extractors/ canonical field extractors — normalize raw responses into stable fields
├── adapters/
│ ├── python/ provider adapter — makes the real calls (you wire your own key)
│ ├── go/ same surface, Go
│ └── node/ same surface, Node — all three are parity-checked
├── auditpack/
│ ├── verify_pack.py dependency-free, std-lib-only, offline verifier — exits 0 on PASS
│ └── recorded.json recorded baseline, SECRETS STRIPPED — what replay checks against
├── VERSION matches the GitHub tag/release
├── CHANGELOG.md
└── LICENSE MIT — the code is yours
No build tool, no gate code, no generator — you get the output and the means to check it.
Download & prove
Don't take our word. Download one and run the verifier.
Pull a single connector from the public repo and re-prove it on your own machine — offline, no keys, in about a minute. The pack on your disk is the same bytes everyone else gets.
~/connectors/stripe — verify
$ python verify_pack.py
verify_pack v1 (offline, std-lib only)
manifest schema .................. OK
extractors load .................. OK (14 fields)
adapters present ................. OK (python, go, node)
recorded baseline replay ........ OK (37/37 cases matched)
risk flags consistent ........... OK (6 tools, 3 risk-bearing)
secrets scan (recorded.json) .... OK (0 secrets found)
RESULT: PASS (exit 0)
✓ offline — no network calls
✓ no API keys
✓ std-lib only — no pip install
✓ secrets stripped from recordings
✓ same bytes as the public release
Honest caveat: this is a recorded / structural check — it proves the connector's shape, extractors, and risk map against a recorded baseline, not a live call to the API. A live credentialed replay is a separate, opt-in step (and a Flagship connector ships one).
1 · Download a connector — and prove it offline
git sparse-checkout — just one connector (recommended)
git clone --no-checkout --depth 1 https://github.com/verifyport/connectors.git
cd connectors
git sparse-checkout init --cone
git sparse-checkout set connectors/stripe
git checkout && cd connectors/stripe
release zip — no git
curl -L -o stripe.zip https://github.com/verifyport/connectors/releases/latest/download/stripe.zip
unzip stripe.zip -d stripe && cd stripe
convenience CLI — thin public wrapper, no factory logic
npx verifyport add stripe
cd verifyport-connectors/stripe
3 · Prove it ran offline
# pull the plug — turn off wifi, or sandbox with no network at all — and re-run:
unshare -rn python verify_pack.py # still exits 0
All connectors are public → github.com/verifyport/connectors
The risk map
Every tool says what it can do — before you wire it in.
For each tool, the connector declares which sensitive actions it can take and, per field, whether you can constrain it before the call goes out. Clamp a max amount, allow-list a currency — decide what an agent may touch.
risk axes: send pay refund grant deploy export
| Tool | Method | Irreversible? | Risk | Constrainable fields |
|---|---|---|---|---|
| create_charge | POST /v1/charges | ⚠ irreversible | pay | amount (max-cap) · currency (allow-list) |
| create_refund | POST /v1/refunds | ⚠ irreversible | refund | amount (max-cap) |
| create_payout | POST /v1/payouts | ⚠ irreversible | pay | amount (max-cap) · destination (allow-list) |
| get_balance | GET /v1/balance | reversible | read-only | — |
| list_charges | GET /v1/charges | reversible | read-only | — |
a representative slice — the full per-tool map ships inside every connector's manifest.json (machine-readable)
01 — Browse the connectors
Every connector, with its contract and its risks on the table.
Open any connector and read exactly what it covers, in which languages, what's verified and what's degraded — and, for each tool, which sensitive actions it can take. The popular APIs and the long tail alike.
4,000+ APIs watched
100 ready to install
Go · Python · Node more added weekly
| API | Languages | Tools | Spec status |
|---|---|---|---|
| Notion no official Go SDK — now you own one | py go node | 41 verified · 2 degraded | current |
| HubSpot one shape across all 6 hubs | py go node | 128 verified · 14 degraded | spec changed 3d ago |
| Linear no official Go SDK | py go node | 57 verified · 3 degraded | current |
| Twilio | py go node | 88 verified · 6 degraded | current |
| Stripe | py go node | 142 verified · 8 degraded | current |
| Shopify | py go node | 167 verified · 19 degraded | 4 tools newly degraded |
a representative slice — the full board lists every watched connector · green = a language we publish that the API has no official client for · see the full board →
04 — Marked honestly
When a spec leaves a gap, the connector says so.
A connector is only as good as the spec it's built from. When an API's own spec is incomplete, the connector doesn't paper over it — it's labelled, in the code and on the board, so you can decide with the gap in view.
Verified
The output contract is proven.
Inputs and outputs are validated, identically, across Python, Go, and Node — the connector produces exactly the shape it declares. Checked, not claimed.
Degraded
The API's spec left gaps.
When an upstream spec omits its response shape, the output can't be proven — so it's marked. The connector still ships and still works; it just never pretends to be more than it is.
What “verified” means — precisely
- the connector matches the upstream spec it was built from
- Python, Go, and Node expose the same tool contract
- error behavior is identical across languages
- each tool's risk flags reflect the actions it can actually take
- every shipped file matches its recorded hash
- the verifier passes offline, with 0 dependencies
What it does not claim: the API's uptime, latency, or how it behaves on a given day. We prove the connector we ship — not the service you call.
02 — What's inside a connector
An audited client, a risk map, and a verifier — in one folder.
A verifyport connector is plain source you own. Same contract in Python, Go, and Node; a declared list of the actions each tool can take; and a self-contained verifier that re-proves the whole thing offline. Nothing to import at runtime, nothing to call out to.
</>
The audited client
The same readable, idiomatic client in Python, Go, and Node — built from the API's own spec and checked against it. You read the code; it isn't a black box.
⚑
The risk map
For every tool, the connector declares which sensitive actions it can perform — send, pay, refund, grant, deploy, export — and, per field, whether you can constrain it before the call is made.
✓
The offline verifier
A dependency-free script that re-proves schemas, routes, error shapes, and credential handling — on your machine, with no network. You don't take our word; you run it.
05 — Three steps
Inspect it. Add it. Verify it.
01
Inspect
Open any connector and read what each tool does, which sensitive actions it can take, and which fields you can constrain — before you touch a thing.
02
Add
Run verifyport add <api>. The source for Python, Go, or Node lands in your repo — yours to read and keep, with nothing that calls home.
03
Verify
Run verify.py. Schemas, routes, error shapes, credential handling, and the declared risk flags are re-proven offline, in about a minute.
Know the moment a connector changes shape.
Subscribe to the connectors you use. When an upstream spec drifts or a tool degrades, you hear it — before it surprises you in production. Taking the fix is an ordinary git merge.
drift alerts · weekly editions · no spam — just the diffs that matter
06 — Questions
The honest answers.
What exactly is a connector here?
Plain source you own — the same audited client in Python, Go, and Node, a declared map of which sensitive actions each tool can take, and a dependency-free verifier that re-proves the whole thing offline. You read it, run it, and keep it.
What do the per-tool risk flags tell me?
For each tool, which sensitive actions it can perform — send, pay, refund, grant, deploy, export — and, per field, whether you can constrain it before the call goes out. So before you wire a tool into anything, you can see what it's capable of.
Can I use these as tools for an AI agent?
Yes — that's a primary use. Every connector exposes the same consistent shape, and each call runs with your own credentials. The risk flags let you decide which tools an agent may touch and which it may not.
How do I know the claims are true?
You don't have to trust them — every connector ships a verifier that re-proves its schemas, routes, error shapes, credential handling, and risk flags offline, in about a minute. Run it yourself; nothing leaves your machine.
Is it really free?
Yes. The connectors are MIT-licensed and the code is yours — copy it, fork it, ship it. No seat, no metered call, no upsell hiding in the install.
What does "degraded" mean?
The API's own published spec is missing something needed to fully prove the connector — usually its response shape. Rather than guess and hide it, the connector ships and is marked degraded, on the board and in the code. Honest beats convenient.
Where do my credentials go?
Into your environment, read from variables you control — and nowhere else. The code holds no key for you to hand over. That's the point of owning the source.