One API for the whole operating layer behind a sale,catalog, orders, payments, customers, and delivery.
The Queek API reaches the same operating layer that runs live businesses on Queek OS, so a call resolves into a real, delivered order, not a checkout that stops. It is in early access today: talk to us and we will set you up directly.
Request
createorder
- merchant:"a Queek OS business"
- items:[ { sku, quantity } ]
- fulfillment:"delivery"
Returns
- order"placed"
- payment"confirmed"
- delivery"rider assigned"
Most commerce APIs hand you a checkout and stop. The Queek API reaches all the way to a delivered order.
The resource areas, each tied to a real Queek OS operation.
Every area below already runs for live businesses on Queek OS. The API is the early-access surface to read and act on them programmatically.
Catalog & products
Products, variants, and live stock as one source of truth.
Orders
Create and read orders across every channel in one queue.
Payments
Checkout and confirmed transactions, not a handoff to a dead end.
Customers
Profiles, order history, and a path to human support.
Delivery & fulfillment
Dispatch, riders, pickup, and live tracking to the door.
Events & webhooks
Order, payment, and status events pushed to your systems. On the roadmap.
What a call looks like, in spirit.
These are illustrative of the intent, reading a catalog and creating an order, not documented live endpoints. Real paths, fields, and auth land as the API moves from early access to general availability.
Read the catalog
listproducts
- in_stock:true
- channel:"any"
What comes back
- product"a real, in-stock item"
- price"live, from one source of truth"
- availabletrue
Illustrative of the direction. Names and fields will change before anything is documented.
Why a Queek API is different from a payments or storefront API.
A payments API stops at the charge. A storefront API stops at the page. The Queek API reaches catalog, checkout, payment, fulfillment, and delivery as one path, so what you build resolves into an order that gets picked, paid for, and delivered.
- 1
Catalog
Live products and stock.
- 2
Checkout
A real cart a call can complete.
- 3
Payment
Confirmed, not handed off.
- 4
Fulfillment
The business accepts the order.
- 5
Delivery
Dispatch and tracking to the door.
Real today, early access, and what we will not claim yet.
We would rather be clear than impressive. This is the real state of the API, with nothing dressed up as more finished than it is.
- Catalog, inventory & live stock on Queek OS
- Orders & checkout
- Payments & confirmed transactions
- Delivery, dispatch & live tracking
- Programmatic access to orders, catalog & payments
- Hands-on onboarding with our team
- Self-serve public API keys
- Published rate limits, SLAs & SDKs
- Webhooks for order, payment & status events
Building on the Queek API? Tell us what you need.
Early partners help decide what ships first. Tell us what you want to build and we will get you the right access directly, rather than point you at docs that are not public yet.
Straight answers about the Queek API.
What is real today, what is in early access, and what we will not pretend exists yet.
Can I get an API key today?
Not self-serve. The Queek API is in early access, so we set partners up directly. Tell us what you want to build and we will get you the right access, rather than point you at a public key flow that is not live yet.
What can the API actually reach?
The operations behind it, catalog, orders, payments, customers, and delivery, all run today on Queek OS. The API is the early-access surface to read and act on them. Anything you build resolves into a real order that gets picked, paid for, and delivered.
Where are the endpoint docs, SDKs, and rate limits?
Not published yet, and we will not invent them. Documented endpoints, SDKs, rate limits, and SLAs land as the API moves from early access to general availability. For now the honest answer is: talk to us about your use case and we will tell you exactly what is possible today.
Do you have webhooks for order or payment events?
Event delivery is on the roadmap, not shipped. If push events are critical to what you are building, tell us. Early partners shape the order we build things in.
Is the API stable enough to build on?
The operating layer it reaches is live and running real businesses. The API surface itself is early access, so shapes can still change. We work with each early partner directly so you always know what is safe to rely on.
One API for catalog, orders, payments, customers, and delivery.
Start with the operating layer that is live today, and build on the API as it moves from early access to general availability.