Skip to main content
A connector is a read-only connection to a destination: GitHub, GitLab, a Facebook Page, an Instagram account, a Meta ad account, a Slack workspace, or an X account. Connecting one lets QED Proof read the facts a verifier needs — it never lets QED Proof write, post, edit or delete anything there. Not every connected destination can be checked yet. Two things are true at once for most connectors today:
  • You can connect it now, read-only, and see what QED Proof would read.
  • Verification isn’t built for it yet. No claim against that destination can be decided until a verifier for it ships.
GitHub, Slack and X have live verifiers today. GitLab, Facebook Pages, Instagram and Meta Ads can be connected, but claims against them aren’t checked yet. WhatsApp and Gmail aren’t connectable at all — see coming soon.

​
Status today

One action needs no connector at all: http.url.status checks a public URL directly.

GitHub

Verify commits, pull requests and CI checks.

Slack and X

Verify messages and posts.

http.url.status

Check that a URL returns the status — and optionally the content — you claimed.

GitLab, Facebook Pages, Instagram, Meta Ads

Connect them today; verification is coming.

​
Planned: more ways to connect

Planned, not built. This describes a proposed design, with no timeline to share.
Today, every connector is QED Proof’s own one-click OAuth app. A proposed design would add three more kinds of connection: pasting an API key for a provider that doesn’t do OAuth well for server-side reads, defining a custom API check against your own systems (a base URL plus declarative assertions, so you can prove an outcome in software QED Proof doesn’t know about), and connecting through your own OAuth app for providers that gate their app review, rather than waiting on QED Proof’s. All three would keep the same rule every connector follows today: evidence comes from reading the destination, never from trusting what an agent reports about itself.