Below you will find information on how to develop Shoporama Apps.
Overall, a Shoporama app provides access to two things when a user installs it on their shop:
Everyone can create apps as a starting point, but in order for other shops to use your apps, it requires approval.
Apps are created on this page.
Download our e-conomic app to see an example of an app that uses our REST interface.
The settings options for apps are:
| Field | Content |
|---|---|
| Name | Short name. Used in overviews and emails. |
| Description | Extended description of what your app does. It is not possible to use HTML codes. Only a-tags for links. |
| Category | Optional category |
| Access | Because your app creates an API token in the store that installs the app, you can choose whether you want write, read, or all permissions for that API token. |
| Monthly price | A monthly price that your app costs. There is an 80/20 distribution of the amount, where Shoporama keeps 20%, and pays out the rest. Once an app has been activated, you can no longer increase the price. Only decrease. |
| Callback URL |
One URL that can receive all callbacks and events. The argument
{
"webshop_id": 1,
"webshop_url": "https://www.example.com/",
"app_token": "dcbfe5ad9e8af3495ca4582e364c1bce",
"app_token_daily_limit": 10000,
"app_token_current_usage": 200,
"installed": 1692857535,
"fields": {
}
}
If your app uses fields where the user can enter information, these will be included in the field For events and webhooks, the call will contain the data that is contained in our events and webhooks. These vary depending on whether it is events or products, orders, etc. To validate if a callback comes from Shoporama, we add the header
|
| Only allow on the following shops | Option to only allow the app on a series of webshops. |
| Webhooks | Here you can choose which webhooks you want to receive. You can receive webhooks when there are changes to orders (status, paid, created), products, or inventory. |
| Events |
Here you can choose which events you want to receive. Events have the possibility to be sent more often than webhooks. For example, when a user adds something to the cart or proceeds to payment. We have the following events:
add_to_basket, update_basket, view_basket, view_address, view_shipping,
view_approve, view_thanks, approved, order_created, paid, add_label,
and remove_label. |
When an app is installed in a shop, an API key is created for the app, and with that key, our REST interface for the respective shop can be accessed. The API key is sent to your callback URL as the field "app_token". Note that the same consumption rules apply to this API access as to regular API keys.
In addition to accessing our regular REST interface, it is possible to retrieve a list of webshops that have installed your app by calling:
GET /REST/app-status HTTP/2
Host: www.shoporama.dk
Authorization: App {din token}
Note that auth-scheme is App.
It is possible to insert code in four places on the shops that install the app. It is
after , after , before , and before
. However, they assume that the html elements are present in the shop that installs it. It is possible
to insert code on all pages, or only products, landing pages, categories, static pages, blog posts, or on /search, /basket,
/address, /shipping, /approve, /thanks, /order, and /also.
It is possible to use Smarty code in the code that is inserted, and it is possible to access the values entered by the user
under fields such as <{$app_vars.var_name}>.
The above can be combined in any way desired, so it is possible to insert a piece of code in on all pages, but on /thanks, something extra will be added.
Fields allow you to create some input fields that your users can fill out when they install the app. You can create as many fields as you want. The values will be included in callbacks when the user updates the settings.
We support the following field types: text, integer, boolean, list,
color, richtext, code.
For lists, it is possible to use external lists. That means when the user sees admin, the values are pulled from
https://example.com/callback?type=field&name={name}, and that page must return json in key:value format. Example:
{
"key1": "value1",
"key2": "value2"
}