Sandbox: the demo store
CompuDime Demo Market is a store that does not exist. Its products, customers, stock, sales and invoices are invented, so you can try the API with a test key before you have a real store's key.
What it holds
- 327 products in 8 departments, from 40 brands: prices, units per case, sizes. Some are inactive and some are on sale.
- Stock on hand for every product, store totals only. Some quantities are zero or negative, as at real stores.
- 60 customers. A third have a house account (the
accountfield). Their phone numbers are in the 555-0100 to 555-0199 range kept for fiction, and their e-mail addresses are onexample.com. - 7 tenders, categories, brands, tags, discount and return reasons, and a store profile.
- The last 28 days of sales, by product and by day, and the orders of those days as invoices. The days move with the calendar (America/New_York). Invoices from the demo store's web shop carry the processor code
DEMOWEB.
The same data comes back every time you ask for the same day. Nothing you send changes it.
Get a demo key
Demo keys are test keys (cd_test_ or cc_test_) for the demo store, one per capability: catalog-feed, sales-data, customer-access or order-intake. Write to support@compudime.com and say which ones you want.
- A demo key reads at access level
all, with theaccountfield: all of it is invented. - Calls to the demo store are never billed. Answers carry no
billingblock and noX-Credits-*headers.estimate=trueanswers the endpoint's list price, what the call costs a store on the default price (see Pricing). - A live key for the demo store is refused:
403 test_key_required.
Try it
export PUBLIC_API_KEY='paste your demo key here'
curl -s https://api.compudime.com/v1/me -H "Authorization: Bearer $PUBLIC_API_KEY"
curl -s https://api.compudime.com/v1/products/lookup/080000003027 -H "Authorization: Bearer $PUBLIC_API_KEY"
With a customer-access key, read /v1/customers/C0001 or look up the phone 7185550100. With a sales-data key, read /v1/inventory/onhand and /v1/sales/movement for any days of the last four weeks.
What it answers
Your key
Who the key is and what it may do. The store object says "sandbox": true.
- GET
/v1/capabilities - GET
/v1/me
The catalog copy
The demo store's catalog, refreshed every 15 minutes.
Live reads
Answered the way a store's POS answers them, with the same paging, fields and errors.
- GET
/v1/products/lookup/{code} - GET
/v1/inventory/onhand - GET
/v1/invoices - GET
/v1/invoices/{posInvoiceId} - GET
/v1/invoices/external/{externalId} - GET
/v1/categories - GET
/v1/brands - GET
/v1/tags - GET
/v1/reasons - GET
/v1/store - GET
/v1/customers/lookup - GET
/v1/customers - GET
/v1/customers/{posCustomerId} - GET
/v1/tenders
Sales history
The last four weeks, day by day.
Orders
Checked like any order, then simulated, as for every test key: nothing reaches a store.
Your webhook receivers
Register a receiver with an order-intake key and send it test events. A test key's receivers get only the test events you send: simulated orders send none.
- POST
/v1/webhooks - GET
/v1/webhooks - GET
/v1/webhooks/{webhookId} - DELETE
/v1/webhooks/{webhookId} - POST
/v1/webhooks/{webhookId}/test - POST
/v1/webhooks/{webhookId}/rotate-secret - GET
/v1/webhooks/{webhookId}/deliveries
What it does not answer
These answer 422 not_in_sandbox for the demo store, without charging anything or reaching a store. Try them with a key for a real store.
- GET
/v1/promotions - GET
/v1/promotions/mix-match/{groupId} - GET
/v1/delivery/routes - GET
/v1/purchase-orders - GET
/v1/purchase-orders/{posPurchaseOrderId} - GET
/v1/receiving - GET
/v1/receiving/{posReceivingId} - GET
/v1/tickets - GET
/v1/tickets/{ticketId} - GET
/v1/sales/zreport - GET
/v1/accounting/sales-summaries - GET
/v1/accounting/journal-entries - GET
/v1/accounting/mapping - GET
/v1/usage/current