oddly
Developers and partners

Build on the proof layer.

The primitive under everything oddly ships is the receipt: a timestamped, checkable record of what was observed, what was concluded from it, and the evidence that would prove it wrong. Commerce verdicts are the first thing we pointed it at. What is open today is the reading side, a deterministic API and a public server with no key, where every response is traceable to the exact rule that produced it. What opens next is the object itself.

Read the API reference Talk to us

First call, no key: ask the observed commerce corpus what it covers.
Request 
curl https://myoddly.com/api/public/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"benchmark_categories","arguments":{}}}'
Response 
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{ "type": "text",
      "text": "oddly's corpus covers <N> categories,
               <M> observed listings in total. All
               figures are observed public storefront
               data. ..." }],
    "structuredContent": {
      "categories": [ ... ],
      "total_observations": <M>
    }
  }
}
The object

What a receipt is.

Four fields, each answering a question a claim on its own cannot. Strip any one of them out and what is left is an opinion with a date on it.

  • observed
    What was seen

    The raw figures, and when they were read. Observation time travels with the record, so a consumer can decide for itself whether the answer is still current.

  • concluded
    What we decided

    The verdict, and the named rule and version that reached it. Same inputs, same outputs, no model in the hot path, so it reproduces.

  • evidence
    Why it holds

    The inputs the conclusion was computed from, addressable rather than described, so the step where we were wrong is findable.

  • actor
    Who did it

    Human or agent, and whether a change was approved before it happened. No path can raise spend without that field naming a person.

What a receipt does not carry yet, stated plainly because this is the page where it matters most: it is not cryptographically signed, and it carries no expiry or disclosure semantics. Those are the next three fields, and they are specified before they are claimed. Today the record is timestamped, traceable and checkable, which is enough to falsify a verdict and not enough to hand one to a stranger who trusts nothing about us.

One object, many questions

The products are views.

A receipt does not know what domain it is in. Point it at a storefront and the conclusion is a commerce verdict. Point it at a vendor and the conclusion is a trust claim. The object is identical, so the surfaces below are three renderings of one thing rather than three products that happen to share a login.

Commerce verdicts

Live

What to do about a store this week, what it is worth, and the figures behind it. This is the view that has been running longest, and the one the public corpus and the storefront grader are read from.

The merchant product

Trust claims

Not shipped

The same record answering "is this vendor what it says it is", with the evidence attached instead of a badge. Being built now. There is nothing to call yet, and this card will say Live on the day there is.

Security posture

Not shipped

Posture answers carrying their own evidence and observation time, so an answer that has gone stale reads as stale rather than as reassurance. Specified, not built.

There is a fourth view already public, and it is the one we did not have to be asked for: oddly's own build and decision ledger, at the build ledger and the receipts page. Every number on those pages carries the date it was observed and goes dark rather than showing you a figure that has stopped being true.

How to reach it

Reading it today.

Three surfaces are live and callable right now, all of them read-only. Two more are named below with no ship date attached, because a roadmap item with a date on it is the first receipt we would break.

Platform API

Live

The v1 REST API over the deterministic primitives. Verify whether a proposed change would be blocked before it is made, read observed category benchmarks, and preview an action or a prescription through the dry-run ceiling. Bearer key, read-only, OpenAPI described.

API reference

Public MCP server

Live, no key

An unauthenticated MCP server over oddly's observed commerce corpus and the free storefront grader. Add it by URL in any MCP-capable agent or assistant, with no account. Three tools: list covered categories, look up observed price and assortment benchmarks, and audit a public storefront.

https://myoddly.com/api/public/mcp

Server descriptor Setup docs

Partner path

Open

For a tool that acts on a merchant's connected accounts, put oddly's deterministic guardrail in the path so every change is verified, decrease-only, reversible, and recorded. Acting on Meta or Google ad accounts is one such application; the same path fits any system that mutates commerce on a merchant's behalf. Talk to us about a partnership.

Become a partner The platform

Receipts API

Not shipped

Issue, verify and query receipts directly, rather than reading the commerce view of them. This is the surface that turns the object into something another system can emit and check, including an agent recording work it did. It does not exist yet. There is no endpoint, no preview key, and no date here.

The receipt spec

Not written

A receipt that only oddly can verify is a log line. The field definitions, the signing scheme, and the expiry and disclosure rules are meant to be published and implementable by someone who does not use oddly at all. When that document exists it will be linked from here, and until it does this card says so.

Want a say in it

Open now

The spec is unwritten, which is the only period in which an outside opinion can still change its shape. If you would consume receipts, or emit them from a system of your own, the constraints you need are worth more to us now than after the first version ships.

Tell us what it has to carry
Who builds on oddly

One capability, many applications.

  • Agent and orchestrator builders who need a deterministic check before anything is applied, and a response they can trace back to the rule that produced it.
  • Internal platform teams wiring approval-gated automation into an existing stack, who want a verifiable record of every change.
  • Risk and finance teams that need a spend constraint they can prove: a system structurally incapable of increasing spend without a human.
  • Partners and integrators building tools that act on a merchant's Meta or Google ad accounts, one application of the same guardrail.
  • Agent and assistant users who want observed commerce benchmarks and a free storefront audit, added by URL with no account.

The merchant who runs oddly on their own store is still the primary customer. The developer surface opens the same deterministic rules to the systems and partners that act on commerce on a merchant's behalf.

Want the full product story behind these primitives? See the platform overview, or read the API reference.

Running a Shopify store and looking for the merchant product?

Back to oddly for merchants