Website World provides access to most of the data in our system, via a restful JSON API.
Our API is used by Couriers, Inventory platforms, CRMs etc.
Courier Integrations
Couriers would usually fetch "recent orders" (aka baskets), with a an extra parameter to identify only those orders that are "ready to ship", to reduce effort. Fetch orders in bulk with minimal details, or request full order line data. Fetch orders individually for full detail.
After an order label is printed, send an update back to our basket/order endpoint, with courier tracking details, and to record a delivered status in our database. You can also optionally trigger a notification to be sent to the customer (if your courier platform does not send it's own notification. We recommend this is configurable per merchant.)
Inventory Management / ERP
Post recently changed products to our product API.
Only include the minimal data to be updated. eg you could just supply code, price and stock count.
Setup a web hook in our CMS platform, to receive notifications of new orders or new customers.
Or poll hourly for new orders, or new customers.
Post member/customer records optionally. The expectation is that the customer facing website usually has the most up to date customer information.
Sync all objects by your own code/reference, or using our ID/reference.
CRM
Setup web hooks for customer events, or poll hourly for new customers or updated customer records.
Customisation / New Endpoints
Website world is a very large platform, with many features. This API has exposed the most common end points required by our customers. If you require addition of a new parameter to reduce I/O, or a whole new endpoint to access whatever data, then please contact us support@website.world
General Knowledge
Whenever possible, we have attempted to maintain some standard approaches across each endpoint.
- "id" = the unique ID of the object / row / data. When retrieving data, you may find a different worded ID field with the same number. These ID's are interchangeable, with "id" used for consistency. If an ID is supplied, then it will update on POST, and only return data on GET. If an ID is not provided, then it will INSERT on POST, or get an ARRAY of data on GET.
- "mbr_id" = when data is associated with a customer, user or member, then we need to state the unique member ID for which the data is associated. This may also be referred to as "about_mbrid" or "mbr_uid" or "staff_id" etc. For consistency, we prefer to use "mbr_id" across all end points, even thought the other id name remains available for use. In many cases, if the mbr_id is not yet known, you can supply a mbr_email and mbr_name, and a mbr_id will automatically be associated based on a unique email lookup, or if not found, it will create a new member record with that email address, and update the data with the correct mbr_id. This is great for flat data systems like Zapier.