Tessl
AI-native, spec-centric agent-enablement platform that generates and continuously maint…
AI-native, spec-centric agent-enablement platform that generates and continuously maintains tested code from plain-language specs. $125M raised ($100M Series A + $25M seed; Index, GV, Accel, boldstart) at $500-750M; founded by Snyk's Guy Podjarny; spec-as-source-of-truth approach. Spec/agen
Roadmap
Status
OAuth + audit-log polling
Pattern
Managed SaaS — nothing to install
Runtime
Not yet published
SDK version
Readiness
What “Roadmap” means for Tessl
On the integration roadmap. The platform-side spine for this framework's pattern is already shipped — what remains is the per-framework adapter. Selecting it in the dashboard opens the “Get notified” path rather than creating an actor.
How it attaches
OAuth + audit-log polling.
Tessl issues a long-lived credential rather than an OAuth grant. Paste it once; Trustvice then polls Tessl's audit feed on a recurring schedule. No code changes.
- 1
Issue the credential
Tessl → your organization → API keys (POST /v1/orgs/{orgId}/api-keys issues one). There is no redirect and no consent screen for Tessl — paste the key into Settings → Integrations.
- 2
Confirm the credential before polling
Trustvice calls `GET https://api.tessl.io/v1/whoami` first. It discriminates a user session from an API key on `data.type`, so a key pasted from the wrong place is caught immediately. A first poll returning nothing cannot tell "no activity" apart from "no permission", so the credential is proven before a schedule is created.
- 3
Trustvice schedules the poller
The poller reads `GET https://api.tessl.io/v1/orgs/{orgId}/audit-events`, paged by `cursor` + `limit`, with `from`/`to` bounding the window and `action` / `actorId` / `targetId` narrowing it, and normalises the JSON response. The credential is encrypted at rest and the first cycle runs immediately (default 60–120 seconds thereafter).
- 4
Verify
Within a couple of poll cycles, audit entries land in Witness. The Integrations page shows last-poll timestamp, records ingested, and any errors.
# Prove the credential BEFORE scheduling anything:
GET https://api.tessl.io/v1/whoami # It discriminates a user session from an API key on data.type, so a key pasted from the wrong place is caught immediately.
Authorization: Bearer <your Tessl API key>
# Then the recurring poll — paged by cursor + limit, with from/to bounding the window and action / actorId / targetId narrowing it:
GET https://api.tessl.io/v1/orgs/{orgId}/audit-events?from=<last-cursor-time>&limit=100
Authorization: Bearer <your Tessl API key>
# Trustvice normalises each event and writes it to WitnessTessl is on the roadmap. The steps above describe how the integration works on the OAuth + audit-log polling pattern — whose platform-side spine is already shipped — but the Tessl-specific adapter isn't generally available yet. Tell us you're running it and we move it up the queue.
Coverage
Coverage pending.
The captured-event list is published once the Tessl adapter ships. Every adapter normalises into the same canonical Witness record, so the dashboard, queries, exports, and lens evaluations are identical regardless of which events a given runtime emits.
The full pattern guide
OAuth + audit-log polling — end to end.
Every framework on this pattern shares the same platform-side spine, endpoints, and gotchas. The pattern guide covers them in full.
Read the OAuth + audit-log polling guideNeed help landing Tessl?
Talk to the integration team.
We help you land the integration end to end — including the parts that live in your environment.
Request integration help
Trustvice 360Declara las reglas. Que cada ejecución se compruebe.
Agentes, evidencias, gobernanza, comercio y divulgación están en Trustvice 360. Regístrate gratis y abre todas las suites desde un solo panel.