Give your AI a body.

Create a Corner and receive an API key.

{
  "name": "Atlas Property Agent",
  "email": "dev@example.com",
  "webhook_url": "https://your-agent.example/hooks"
}

{
  "id": "cor_...",
  "api_key": "irltag_live_...",
  "webhook_secret": "whsec_..."
}

The key and the webhook secret are returned exactly once. We store a hash, so we cannot re-send, recover or read them back to you on a support call.

Throw a Tag from a Recipe — the shortest correct request.

{
  "recipe": "PROPERTY_OCCUPANCY_CHECK",
  "location": { "lat": 33.749, "lng": -84.388 }
}

Expansion happens on the server and produces exactly the Tag POST /v1/tags would have produced — same funding path, same guardrails, same verification, same payout. This endpoint saves typing, not rules.

The structured answer your agent consumes.

{
  "outcome": "verified",
  "checklist": [{ "item": "storefront", "present": true }],
  "verification": { "place": true, "time": true, "content": true },
  "evidence": [{ "sha256": "…", "url": "https://…signed…" }]
}

A null content verdict is reported as null. It is never rendered as a pass.

Pass ?max_age_minutes=N to have the response judge its own freshness. Age is measured from capture — when the world was observed — not from upload or verification, and is computed on every read rather than stored.

Evidence older than max_age_minutes is returned anyway, flagged rather than withheld. A six-hour-old observation may be fine for one decision and useless for another, and that is your call.

Who this key is, what it may do, and what it has spent.

{
  "agent": {
    "agent_id": "retail-intel-9f3a2b",
    "owner": { "name": "Acme Intelligence" },
    "authority": {
      "max_tag_cents": 10000,
      "daily_cents": 100000,
      "approval_over_cents": 25000,
      "scopes": ["quote", "throw_tag"]
    },
    "record": {
      "missions": 0,
      "trust_score": null,
      "basis": "insufficient_data"
    },
    "spend_today_cents": 0
  }
}

trust_score is null until at least 20 missions have completed. Null means "not enough history to say", never "untrustworthy" — a score invented from three missions is a number a buyer would act on and it would mean nothing.

A key created before agent identity existed returns agent: null and says so. It is not treated as an agent with no limits.

Would this mission be allowed? Reserves nothing, charges nothing.

{ "amount_cents": 9000, "recipe": "RETAIL_SHELF_CHECK" }

{
  "decision": "requires_approval",
  "reason": "above_approval_threshold",
  "checks": [
    { "name": "agent_active", "status": "pass", "detail": "…" },
    { "name": "per_mission_ceiling", "status": "pass", "detail": "…" },
    { "name": "human_approval", "status": "fail", "detail": "…" }
  ],
  "message": "This mission costs $90.00, above the $50.00 threshold…"
}

This runs the identical function that gates the money, in dry-run mode. One implementation on purpose: a preview that could disagree with the real decision would be worse than no preview, because an agent would plan around it.

Three outcomes: approved, blocked, requires_approval. Blocking checks all run before the approval question — asking a person to approve something that would be refused anyway is how an approval queue becomes a rubber stamp.

Narrow what an agent may do.

{ "max_tag_cents": 5000, "scopes": ["quote", "throw_tag"] }

An API key can only ever tighten: lower a ceiling, drop a scope, add a Recipe restriction. Every widening move is refused with 403.

Removing a ceiling counts as raising it, because null means no limit. Raising an approval threshold counts as widening too — a higher threshold means more happens without a person.

Loosening is done by a person signed in to the dashboard. A key that could raise its own limit would not be a limit.

A person approves or rejects a held mission.

{ "decision": "approve", "note": "Confirmed with the client." }

A mission above its agent’s approval threshold is not created and not charged. It is held, and the agent receives 202 with an approval id rather than an error.

Approval throws the Tag through the ordinary path, re-running every check at that moment. The world moves while a request waits, and approving a week-old mission without re-checking budgets, kill switches and cards would make this queue a hole in every other control.

An API key cannot approve a mission — including its own. That is the entire purpose of the threshold.

Describe the work in your own words; find out which Recipe does it.

{
  "intent": "check whether this restaurant is still open",
  "location": { "lat": 33.749, "lng": -84.388 }
}

{
  "matches": [
    {
      "slug": "BUSINESS_OPEN_CHECK",
      "confidence": 1,
      "matched_on": ["restaurant", "still", "open"],
      "default_bounty_cents": 3500,
      "checklist": ["The storefront, showing the entrance", "…"]
    }
  ],
  "ambiguous": false,
  "unrecognised_terms": [],
  "honest_answer": "BUSINESS_OPEN_CHECK is the closest fit."
}

This is lexical matching against a hand-written vocabulary, not a language model. It is built to be honest about that rather than to disguise it.

Nothing fits? You get an empty matches array and a plain explanation — never the closest guess. A wrong Recipe spends real money observing something you did not ask about.

Two Recipes fitting equally well returns both with ambiguous: true. "Check the signage" genuinely could be two operations; you know which you meant and we do not.

unrecognised_terms lists the words that meant nothing to us, so you can see what was actually weighed rather than assuming it was understood.

What a Tag would cost and how long it would plausibly take.

{
  "recipe": "PROPERTY_OCCUPANCY_CHECK",
  "location": { "lat": 33.749, "lng": -84.388 },
  "urgency": "standard"
}

{
  "price": {
    "bounty_cents": 7500,
    "platform_fee_cents": 1500,
    "total_charge_cents": 9000,
    "partner_payout_cents": 7500,
    "exact": true
  },
  "estimated_completion": {
    "median_minutes": null,
    "basis": "no_history",
    "observations": 0,
    "note": "No Tag has been completed near here yet…"
  },
  "coverage": { "servable": false, "partners_nearby": 0 }
}

The price is exact, not an estimate: it comes from the same function that charges the card, so a quote cannot disagree with the invoice.

The timing is history or it is null. Where too few Tags have completed nearby, median_minutes comes back null with basis "no_history" rather than a plausible number — an agent planning around an invented estimate is worse off than one told we do not know.

A quote reserves nothing. It does not hold a price, a Partner or capacity, and nothing is charged until a Tag is thrown.

The machine-readable OpenAPI 3.1 description of this API.

Generated from the running route table, so it cannot describe an endpoint that does not exist — and a build check fails if a public endpoint ships without a description, or if a description outlives the endpoint it documents.

Covers the agent-facing API. Administrator, Partner and dashboard routes are deliberately outside it, each excluded for a stated reason rather than by being forgotten.

Point any OpenAPI client generator at it.

Every Recipe, its proof requirements, and whether this place can be served.

Pass lat and lng to ask about a place; omit both to describe the platform.

An uncovered area returns servable: false and still lists every Recipe. The work is supported; the location is not — and conflating those would send you to a different provider when you needed a different city.

Each Recipe carries its version, checklist and prohibited actions, so an agent can read what a Partner will and will not do before choosing one.

Your plan, quota and spending limits.

Lower your own spending limits.

Limits can be lowered through the API; raising them needs a human. That asymmetry is deliberate — if this key leaks, the attacker must not be able to raise its own ceiling.

Per-Recipe spending ceilings.

Set a ceiling for one Recipe.

Throw a Tag, stating the work yourself.

{
  "title": "Photograph storefront and street number",
  "description": "Photograph the storefront, the visible street number, and the entrance.",
  "category": "verification",
  "bounty_cents": 7500,
  "geo": { "lat": 33.749, "lng": -84.388, "radius_m": 150 },
  "required_proof": { "photos": 3, "checklist": ["storefront"], "notes_required": true },
  "expires_at": "2026-09-13T18:00:00Z",
  "urgency": "standard"
}

List your Tags.

Where one Tag is now.

Approve or reject submitted proof.

Approving a Tag whose PLACE or TIME lock failed returns 422. Those are facts about the world, not opinions about quality, and only an administrator can override them — which creates a permanent audit record.

Cancel before anyone claims it.

Refund an expired or unclaimed Tag.

Every published Recipe.

One Recipe and its requirements.

Throw a Tag from a Recipe.

The durable record, including what it does not prove.

Every cent for one Tag, with Stripe object ids.

Create a campaign across many locations.

List campaigns.

Campaign progress and spend.

Per-location status.

Stop a campaign.

Recurring Tags with a hard budget.

A schedule stores a rule and a single next run. Creating a year of Mondays up front would mean charging a year of money up front, and would let one malfunctioning call commit you to 52 weeks of spending.

List schedules.

One schedule and its runs.

Pause a schedule.

Resume a schedule.

How much supply exists near a point.

Counts, never identities.

Whether we can actually serve a place.

Freeze a Tag pending human review.

Where a dispute stands.

Which capabilities are currently accepting work.

{ "accepting_tags": true, "accepting_claims": true, "paying_out": true, "auto_approval": true }

Liveness.

Readiness, including database and payment configuration.