Obvious/Help Center

Developer API Overview

Published February 27, 2026 · Last updated March 5, 2026 · 3 min read

The Obvious External API lets you create projects and start agent sessions programmatically. If you're building a product that uses Obvious under the hood — spinning up workspaces for your customers, kicking off analysis jobs from your backend, or embedding AI-powered workflows into your own app — this is how you do it.

Think of it as a remote control for Obvious. Your code tells Obvious what to build and what to work on. Obvious handles the rest — creating the project, running the agent, and delivering results.

Who this is for

The API is designed for developers integrating Obvious into their own products or internal tools. Common use cases:

  • SaaS platforms that create Obvious projects on behalf of their users — onboarding flows, automated analysis, report generation.
  • Internal tools that trigger agent sessions from a backend service — a Slack bot that spins up a research project, a CI pipeline that generates a data quality report.
  • Custom workflows where you need Obvious to do work without someone manually opening the app.

You don't need the API to use Obvious day-to-day. It's for when you want Obvious to work as part of a larger system you're building.

Base URL

All API requests go to:

https://api.app.obvious.ai/api/v1/

Authentication

Every request requires an API key passed as a Bearer token:

Authorization: Bearer obv_your_api_key_here

API keys are created in Settings → External Access. Each key is scoped to a workspace and inherits the permissions of the user who created it. See Authentication for the full setup guide.

The three endpoints

The API has three endpoints. Together they cover the full lifecycle: discover what's available, create something from it, and run additional work on it.

List Templates

GET /api/v1/templates

Returns the templates accessible to your API key — public, workspace, team, and private. Use this to discover template IDs programmatically before creating projects.

This is your starting point. Templates define what a project looks like when it's created — the artifacts, sheets, instructions, and context that the agent works with. Listing them tells you what's available to build from.

Create Project from Template

POST /api/v1/templates/{id}/project

Creates a new project from a template and immediately starts an autonomous agent session. You pass a starterPrompt with the agent's instructions, and optionally a successPrompt and failurePrompt to control what happens when the agent finishes or hits a blocker.

This is the core endpoint. One API call gives you a fully provisioned project with an agent already working on your task.

Create Thread in Project

POST /api/v1/projects/{id}/thread

Creates a new thread in an existing project and starts an agent session. Use this when you want to run additional work on a project that already exists — a follow-up analysis, a new report from the same data, a different task using the same context.

Same parameters as Create Project (starterPrompt, successPrompt, failurePrompt), but instead of creating a new project, it adds a thread to one you've already got.

How the pieces fit together

A typical integration follows this pattern:

  1. List templates to find the right starting point for your use case.
  2. Create a project from that template with a specific task in the starterPrompt.
  3. Create additional threads on that project as you need more work done.

The agent runs autonomously in each case. When it finishes (or gets stuck), it follows whatever instructions you put in the successPrompt or failurePrompt — typically a webhook call back to your system.

Next steps

Was this helpful?