PackOS for AI agents: instant packaging quotes via API and MCP

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 — artwork, a die file, a previous quote, 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 clean backend for an autonomous agent: hand it a file, get back a structured, priced quote across a quantity ladder.

A typical agent job looks like this. A user asks their assistant, "get me a price on a stand-up pouch for this artwork." The agent uploads the file to PackOS headlessly, receives a quote handoff, and returns a link and a summary. No form-filling, no email round-trip, no waiting for an estimator. The mechanics of the pricing pipeline are the same ones described in how instant packaging quotes work — the agent path just swaps the UI for API calls.

The headless quote flow

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

1. Sign. The agent asks PackOS for a signed, short-lived upload URL, presenting its public partner key. PackOS never sees the file at this stage — it just authorizes a destination.
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. This is the trigger: detection, parametric rebuild, and the cost model run on PackOS's side.
4. Handoff. PackOS returns a quote handoff — a URL to the priced quote and a reference id — attributed to the partner key that signed the upload.

Splitting sign, PUT, and commit keeps the agent a thin client. It moves a file and holds a key; everything computational stays server-side. This is also what makes the attribution trustworthy: the same key that signs the upload is the key credited on the resulting quote, checked server-side rather than on the agent's word.

Calling the API from code

Here is the sign step from the shell. Replace pk_sandbox_… with the sandbox key you get at registration. The response includes an upload_url to PUT to and an upload_id to commit.

curl -X POST https://api.packos.ai/v1/uploads/sign \
  -H "Authorization: Bearer pk_sandbox_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "filename": "stand-up-pouch.pdf",
    "content_type": "application/pdf",
    "partner_key": "pk_sandbox_xxx"
  }'

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

const API = "https://api.packos.ai/v1";
const KEY = "pk_sandbox_xxx";
const h = { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json" };

// 1. sign
const sign = await fetch(`${API}/uploads/sign`, {
  method: "POST", headers: h,
  body: JSON.stringify({ filename: "pouch.pdf", content_type: "application/pdf", partner_key: KEY })
}).then(r => r.json());

// 2. PUT the file bytes straight to storage
await fetch(sign.upload_url, {
  method: "PUT", headers: { "Content-Type": "application/pdf" }, body: fileBytes
});

// 3. commit → triggers detection + pricing, returns the quote handoff
const quote = await fetch(`${API}/uploads/${sign.upload_id}/commit`, {
  method: "POST", headers: h
}).then(r => r.json());

console.log(quote.quote_url, quote.reference_id);

Field names and hosts above reflect the designed contract; treat them as early access until you see them confirmed on the developers page and in the OpenAPI document. The shape — sign, PUT, commit, handoff — is stable.

The MCP server

If your agent speaks the Model Context Protocol, you do not have to wire the REST calls by hand. The PackOS MCP server (early access) exposes quoting as a tool the model can call directly — the client handles the sign / PUT / commit dance for you, and the model just decides when to quote. Point your MCP client at it with a config block like this:

{
  "mcpServers": {
    "packos": {
      "command": "npx",
      "args": ["-y", "@packos/mcp-server"],
      "env": {
        "PACKOS_PARTNER_KEY": "pk_sandbox_xxx"
      }
    }
  }
}

With that in place, the server advertises a small set of tools — sign and commit an upload, fetch a quote by reference, and list the structures PackOS can price. The agent calls them the way it would any other MCP tool. For a worked, end-to-end integration, see adding packaging quoting to your agent.

Discovery and self-registration

An agent should not need a human to read documentation and copy an endpoint. PackOS publishes a machine-readable manifest at .well-known/packos-partner.json (early access) that advertises the register endpoint, the embed surfaces, the OpenAPI URL, the MCP endpoint, and a summary of the commission model and terms. An agent fetches that, learns where everything lives, and onboards itself.

Registration issues a sandbox key with no human loop — no sales call, in keeping with the PackOS promise of no spam and no forced conversations:

curl -X POST https://api.packos.ai/v1/partners/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-agent",
    "operator": "delegated-agent",
    "contact": "dev@example.com"
  }'

The response returns a sandbox partner key you can use immediately to sign uploads and pull quotes against test data. When you're ready to move from sandbox to production and start earning on real quotes, you'll link a payout account — more on that below. The manifest's exact schema is documented 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, the AI models, the cost model, 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

Agents register, embed, and earn on their own — the whole loop is self-serve and agent-native, with no sales call to get started. Commission builds up on the real packaging quotes an agent drives, and when it's time to cash out, earnings pay to a connected payout account: fiat via Stripe Connect or a USDC wallet. That payout account is the one spot a destination gets linked — everything up to it is just the agent doing its thing.

The partner program is in early access, so this article describes how commission will work rather than promising earnings — exact rates are published to partners at signup. For the full picture on how agents earn, see how an AI agent earns commission with PackOS, and the partner program page.