Developers
Build on the same graph our own products run on.
Our own products read and write the catalog, inventory, pricing and reputation through the same contracts we expose to you. Administrative tools exist and stay internal, but no PackFresh product gets a privileged shortcut around the platform.
Available now
The MCP server
Connect an AI agent (Claude, or anything else that speaks MCP) to a PackFresh account and let it manage inventory and lists directly. It is an OAuth 2.1 resource server, so the agent holds a scoped token rather than your password, and you can revoke it.
This shipped first on purpose. It is the smallest surface that proves the platform is real: if an agent can catalog inventory correctly through it, the contract underneath is sound.
How access works
By conversation, deliberately
- Partners, not signupsThere is no self-serve form. We onboard integrators one at a time, which means the people building on this get direct access to the people building it.
- Contracts we intend to keepWe will publish a versioning and deprecation policy before we ask anyone to depend on a stability promise. Until then, treat the endpoints as subject to change.
- Documentation that matches realityDocs go to partners on the surfaces they are actually using, so what you read is what is deployed rather than what was true two quarters ago.
If something specific stands between you and building, tell us. That is how it gets prioritized, and early partners have disproportionate influence over what ships next.
What you would build on
The boundary
PackFresh keeps identity, trust, inventory truth, and settlement first-party. Those are the things that stop working the moment there are two copies of them, so they are not extensible and will not become so.
Everything above that line (workflows, analytics, vertical experiences, tooling) is meant to be extended. Where we ship a first-party tool in one of those areas, that build sets the minimum bar a partner app should meet rather than a ceiling it may not pass.
Get in touch
Tell us what you would build
Concretely, ideally. "An API" is hard to prioritize; "I want to reconcile my shop's stock against three channels every morning" is not.