PackOS for AI agents: packaging quotes via API and MCP (early access)

What an agent can do with PackOS

Most B2B tools assume a human at a screen. Packaging quoting does not have to. Given a file — label artwork, a die file, or a filled-in spec — the work of turning it into a price is deterministic software, and software can be called by software. That makes PackOS a candidate backend for an autonomous agent: hand it a file, get back a link to a quote.

A typical agent job looks like this. A user asks their assistant, "get me a price on a roll label for this artwork." The agent uploads the file to PackOS, receives a quote handoff, and returns a link and a summary. No form-filling, no email round-trip. Quick Quote prices custom roll labels today; other formats are not quoted (flexible packaging is coming soon), so an agent asked for a pouch or a box quote should say so rather than promise one. The mechanics of the pricing pipeline are described in how instant packaging quotes work.

The headless quote flow

The agent flow mirrors the browser flow, which is deliberate: the same backend and the same attribution. Four steps, no UI.

1. Sign. The agent asks PackOS for a signed, short-lived upload URL, presenting its partner key. PackOS never sees the file at this stage — it just authorizes a destination and binds the upload to the key.
2. PUT. The agent uploads the file straight to storage with the signed URL. The bytes go to PackOS storage, not through the agent's own servers.
3. Commit. The agent tells PackOS the upload is complete. The server confirms it against the signed record.
4. Handoff. PackOS returns a quote URL — the Quick Quote page for that upload — attributed to the partner key that signed it.

Splitting sign, PUT, and commit keeps the agent a thin client. It moves a file and holds a key; everything computational stays server-side. The key that signs the upload is the key credited on the resulting quote, bound server-side rather than on the agent's word.

Calling the API from code

These are the endpoints the embed widget itself calls. Partner keys are issued by PackOS on request and are bound to the origins you register; a key not provisioned for your caller is refused, and sandbox keys cannot sign uploads. Here is the sign step from the shell — the response includes an uploadUrl to PUT to and an objectKey to commit:

curl -X POST https://packos.ai/api/embed/sign \
  -H "Content-Type: application/json" \
  -H "Origin: https://your-registered-origin.example" \
  -d '{
    "key": "pk_live_xxx",
    "filename": "label.pdf",
    "size": 482113
  }'

And the same three steps — sign, PUT, commit — in JavaScript. The commit response carries the quoteUrl handoff the agent returns to its user:

const API = "https://packos.ai/api/embed";
const KEY = "pk_live_xxx";
const h = { "Content-Type": "application/json" };

// 1. sign
const sign = await fetch(`${API}/sign`, {
  method: "POST", headers: h,
  body: JSON.stringify({ key: KEY, filename: "label.pdf", size: file.size })
}).then(r => r.json());

// 2. PUT the file bytes straight to storage
await fetch(sign.uploadUrl, {
  method: "PUT",
  headers: { "content-type": sign.contentType, "if-none-match": "*" },
  body: file
});

// 3. commit → binds the upload to the key, returns the quote handoff
const quote = await fetch(`${API}/commit`, {
  method: "POST", headers: h,
  body: JSON.stringify({ key: KEY, objectKey: sign.objectKey })
}).then(r => r.json());

console.log(quote.quoteUrl);

The request's Origin (or Referer) must match an origin allowed for the key, which is one reason the headless path is early access: there is no bearer-token API, no self-service key issuance, and no published OpenAPI description for these endpoints yet. Confirm the current status on the developers page.

The MCP server (planned)

If your agent speaks the Model Context Protocol, you would not have to wire the REST calls by hand. A PackOS MCP server that exposes quoting as a tool — the client handling the sign / PUT / commit sequence, the model deciding when to quote — is planned. It is not published: there is no package to install and no endpoint to point a client at, so any configuration you see elsewhere for it should be treated as a sketch. For what agents can use today, see adding packaging quoting to your agent and the keyless Open Calc API on the developers page.

Discovery and self-registration (planned)

An agent should not need a human to read documentation and copy an endpoint. The idea is a machine-readable manifest at a .well-known path that advertises the register endpoint, the embed surfaces, the OpenAPI URL, the MCP endpoint, and a summary of the commission model and terms, so an agent can onboard itself. That manifest is a proposed spec — it is not published — and there is no self-registration endpoint today: to get a key, request early access on the partner program page. The proposed manifest shape is described in the discovery spec.

The thin-client trust boundary

The single most important thing to understand about the agent path is how little the agent actually holds. It collects the file and carries a public partner key, and it hands off. The upload lands in PackOS storage; detection, pricing, and attribution all run on PackOS. The agent is a courier, not a processor.

That boundary is the security story. A public partner key is safe to ship in a page or an agent config because it can only attribute an upload — it cannot read other partners' quotes, move money, or act as an account. Server-side validation, not client trust, decides what counts. It is also what lets the same key work whether a human embeds the widget or an agent calls the API: attribution does not care who moved the file, only which key signed it.

Where agents fit in the partner program

The partner program is in early access: you request a key, place the embed or drive the keyed path, and commission builds on the real quotes that result. Self-serve, agent-native onboarding is the direction, not today's experience. When it's time to cash out, earnings are planned to pay to a connected payout account — fiat via Stripe Connect or a USDC wallet. Because the program is early, this article describes how commission will work rather than promising earnings — exact rates are published to partners at signup. For the full picture, see how an AI agent earns commission with PackOS, and the partner program page.