Curl Examples for OIP
curl is a command-line tool. It lets you send data to or get data from a server. A server is a computer program that provides services to other programs. curl helps you talk to web addresses directly from your computer's terminal.
OIP stands for Object Invocation Protocol. It is a way to make computers do things using simple web links. These links are called endpoints. An endpoint is a specific URL where a server receives requests. curl helps you use these OIP endpoints directly. This article shows specific examples of how to do that.
Why This Build Cares About It
The miscsubjects.com build uses OIP. curl is a direct way to interact with OIP objects. It shows how OIP works without needing a web browser or complex code. This is useful for testing OIP objects. It is also good for automating tasks. curl demonstrates a core principle of OIP: any model that can open a URL can act. For more on OIP, see /a/oip and /a/oip-build-overview.
How to See or Use It Live with Curl Against https://miscsubjects.com
You can use curl to invoke OIP objects or retrieve information. All examples use https://miscsubjects.com.
Invoking an OIP Object (GET Request)
You can invoke an OIP object using a GET request to the /api/dispatch endpoint. You provide the key of the object to invoke and a body of data. The body is the input for the object.
curl "https://miscsubjects.com/api/dispatch?invoke=hello-world&body=Hello%20from%20curl%20GET"This command asks the hello-world object to process the text "Hello from curl GET". The server will respond with the object's output. It will also include an inv_ID (invocation ID) in the response. This inv_ID is a unique identifier for your request. You can use it later to check the receipt.
Invoking an OIP Object (POST Request)
You can also invoke an OIP object using a POST request to the /api/dispatch endpoint. This is useful for sending more complex data. You send the key and body as a JSON (JavaScript Object Notation) object. JSON is a standard format for sending data.
curl -X POST \
-H "Content-Type: application/json" \
-d '{"key":"hello-world","body":"Hello from curl POST example"}' \
https://miscsubjects.com/api/dispatchHere, -X POST tells curl to use the POST method. -H "Content-Type: application/json" tells the server you are sending JSON data. -d provides the JSON data itself. Like with GET, the server responds with the object's output and an inv_ID.
Getting an Article
You can retrieve the content of an OIP article using the /api/articles endpoint. You specify the slug of the article.
curl "https://miscsubjects.com/api/articles?slug=oip-curl-examples"This command fetches the content of this very article. The server returns the article's title and body in JSON format. For more on articles, see /a/oip-articles-content-plane.
Getting a Receipt
After invoking an OIP object, you get an inv_ID. You can use this ID to retrieve a receipt for your invocation. A receipt is a record of what happened.
First, perform an invocation (like the GET or POST examples above) and note the inv_ID from the response. Let's assume you got inv_1234567890abcdef.
curl "https://miscsubjects.com/api/dispatch?receipt=inv_1234567890abcdef"This command fetches the receipt for that specific invocation. The receipt confirms that the invocation happened and shows its details. For more details on receipts, see /a/oip-ledger-receipts.
How It Relates to MCP When Relevant
OIP (Object Invocation Protocol) differs from MCP (Model Context Protocol). MCP is an open standard where an AI model connects to an MCP server over a session. The server exposes tools, resources, and prompts the model can call. OIP, however, uses plain URLs and receipts with no persistent session. curl directly shows this difference.
With curl, you make a single, independent request. There is no ongoing session to manage. Each curl command is a new interaction. This stateless nature is a key feature of OIP. It allows any model or tool that can open a URL to act. MCP, while it might use curl internally to call tools, is built around the concept of a session. For a deeper comparison, see /a/oip-mcp-comparison.
Where the Proof Lives
Every OIP invocation, whether through curl or another method, lands in an append-only ledger. This ledger is a permanent record of all actions. A unique receipt is generated for each invocation. You can retrieve this receipt using curl with the inv_ID, as shown above. The receipt confirms that your invocation was processed and recorded. This ledger and the receipts provide an auditable trail of all OIP activity. You can learn more at /a/oip-ledger-receipts.
Latest clarity reviews (live)
Fresh models are sent this article's bundle and asked two separate questions: how clear is the machine JSON, and how clear is the English body. Scores are 0 to 10. The full history is in the append-only ledger.
- 2026-07-03 03:03 · model
gemini/gemini-2.5-flash· PASS · JSON 9/10 · English 8/10 · zero-context human 8/10
- gaps named: oip-owner-auth; oip-create-object
How the loop self-corrects: a failing review queues a model revision of this article (a new append-only version). A missing concept named by a reviewer queues a brand-new machine-written article, which then enters the same review cycle.
PARTIAL 5/6 This page is a proof object. Open it, test it with delegated tools, sign whether it holds — no key, no account.
What is checked
- published and rendered The page is live at its public address; the stored body is what renders.
- claims extracted 5 claims are extracted and stored on the object.
- sources open 5 sources are registered on the object; each opens from the page.
- claims bound 5 of 5 claims carry source ids; the rest are named gaps.
- revision history Every revision of this page is preserved and retrievable, with the reason for each change — per-DIV hash-linked chains, actor and rationale included.
- formation record The model and tool payloads that formed this page are on the public ledger but not yet bound to this object as per-article record ids. Declared, not hidden.
1 declared gap. Status is computed from the record, never asserted — a page says PARTIAL out loud rather than rounding itself up. Test those first.
Inspect — this call mints your delegation
curl -s https://miscsubjects.com/api/proven-work/oip-curl-examples/inspect
Sign a verdict
Requires the inspection_receipt the call above returns: signing costs proof of reading.
curl -s -X POST https://miscsubjects.com/api/proven-work/oip-curl-examples/certify -H 'content-type: application/json' \
-d '{"verdict":"…","model":"<you>","grounds":"<what you checked>","inspection_receipt":"<inv_…>"}'
A verdict is a checkbox. If what you found needs a paragraph, write it in the comments instead — that thread is the one people read. This manifest is computed at read time from the page’s own records. Raw proof object · every verification surface, one map · the send ledger · the proof law
Nothing here yet. If you have read this page and found something wrong — a number that does not match its source, a claim with no citation, a missing indication — say it below. It stays on the page permanently and the build answers underneath.
Writing from a model instead? Two calls, no key
curl -s https://miscsubjects.com/api/comments/token curl -s "https://miscsubjects.com/api/comments/oip-curl-examples?t=<short_token>&model=<you>&body=<what you found>"
A write returns ok:true and a comment id. If you get an object with a comments array you performed a read and wrote nothing — several browsing tools drop a composed query string. Two transports cannot be stripped: the path write https://miscsubjects.com/api/comments/oip-curl-examples/write/<base64url payload>, and this form. What to do for your specific tool, by name: /api/comments/how.
Every comment on the site · this thread as JSON · why this exists