For developers and AI agents

Run the work from your own systems — and your agents.

Every operation the product runs on is in the API: properties, jobs, bids, contracts, payments, assessments, visits. The same operations are MCP tools, so an AI agent can do the work as you.

  • The same operations our own app uses
  • Your permissions, never more
  • A generated OpenAPI reference

Request early access

We call you back within a business day.

What you're building
Create a jobExample
POST /api/v1/jobs
Authorization: Bearer tod_…

{ "propertyId": "…",
  "description": "Leak over the kitchen",
  "workDriver": "leak",
  "trades": [{ "trade": "roofing",
               "workType": "repair" }] }

201 CreatedSame rules as the app

Work on property still runs on email and portals

Re-typing between systems

The request is in your system; the job is in someone else's portal.

No way in for agents

An AI assistant can read your inbox, but can't hire a pro or approve a bid.

APIs that do half the job

Read-only endpoints, and the real work still happens in a UI.

Different rules for the API

What the API allows drifts from what a person is allowed to do.

One set of operations, three ways in

01

A REST API for everything

Create and submit jobs, collect bids, accept one, sign the contract, start and finish the work, approve and pay out — the whole loop.

  • The full job lifecycle
  • Properties, assessments, visits and payments
  • An OpenAPI spec generated from the code
Create a jobExample
POST /api/v1/jobs
Authorization: Bearer tod_…

{ "propertyId": "…",
  "description": "Leak over the kitchen",
  "workDriver": "leak",
  "trades": [{ "trade": "roofing",
               "workType": "repair" }] }
02

MCP for AI agents

Every operation is a tool on our MCP server, with its input as a JSON schema. Point an agent at it and it works as you.

  • Every operation is a tool
  • Narrow the tools to what an agent needs
  • Same key, same permissions
An agent submits a jobExample
→ tools/call  jobs_submit
  { "jobId": "…" }

← { "phase": "INTAKE",
    "substatus": "SUBMITTED" }
03

Keys that can only narrow

An API key acts as the person who made it, with scopes that can only take permissions away. Every key is audited.

  • Acts as a real person
  • Scopes narrow, never widen
  • Every use audited
API key · reporting agentExample
Acts as
You · your company
Scopes
jobs:read
Last used
Today, 9:14 AM

Can't sign or payRead only

04

The app's rules, not the API's

The API and the app run the same operations through the same permission checks, so an integration can never do what its person couldn't.

  • One policy for app and API
  • Rate limits per key
  • Errors in plain words
jobs.acceptQuoteExample
  • Key scope covers it
  • This person may accept on this job
  • The bid is still open
  • Contract drawn up

What changes

TodayWith Hire Tod
Your system to the workCopy and paste into a portalOne API call
AI agentsRead-only, at bestEvery operation, as a tool
PermissionsA separate API roleThe same rules as the person
DocsWritten by hand, out of dateGenerated from the code

Early access

  1. 01

    Tell us what you're building

    Your system, your use case, the operations you need.

  2. 02

    Get a key

    Scoped to what you need, with the reference and the MCP server.

  3. 03

    Build with us

    A direct line to the team while the API is in early access.

Questions

Is the API open to everyone?
Not yet. It's in early access while we harden it; tell us what you're building and we'll set you up.
What can it do?
What the app does: properties, jobs, bids, contracts, payments, assessments, home watch visits and more.
How do AI agents use it?
Through our MCP server: every operation is a tool, run as the key's person, behind the same permission checks.
How is access controlled?
A key acts as the person who made it; its scopes can only narrow what that person may do. Every key is audited.

Build on the work, not around it.

Request early access

We call you back within a business day.

What you're building
Request API access