API Call context

Header context

Back office is stateless so we need the front to send all of the information/details to get the API call context.
Whenever you make API calls, DJUST expects some project context.

Up to five parameters can be defined in your header to specify the context of your call.

Tenant context

When you call DJUST, the URL is generic so in order to identify yourself, you need an API key (provided by DJUST). This key is used in every call performed.
Djclient always set to ACCOUNT just for DJUST to differentiate back-end API calls from the front-end ones.

Store context

Stores are the different fronts (for example, a front-end dedicated to clothing, and a second one dedicated to medical supplies).
In some cases, you might need several fronts with different languages (localizations), which need to have their own navigation categories. These are the storeviews.

If not specified, the default store and storeview are used.

Account context

As users can be associated with several different accounts, you need to specify which user from which account is in the call context. If not specified, the default account is used.

Define the currency

The DJUST application can manage multi currency. The currencies can be specified in many API calls.

For example, if you want to receive the product offers in US dollars, then you can call PRODUCT-502 with a request parameter currency=USD to get all the offers in this currency.

⚠️

Important

This request parameter does not act as a filter. It returns all offers converted in the selected currency.

Define the locale

When you ask for product information or navigation categories, you can precise the locale in your API call.

Locales are configured in the back-office.

Context with Stardust

With stardust, you can use functions and variables to define the context

Context of your tenant

un Stardust, you can specify your dj-api-keyin the .env file (the value is APIKEY)

You dont have to specify the dj-client , it'll be automaticaly added

Define the store

📘

Note

In Stardust, the store and storeView IDs are stored in the store and in the cookies.

When you have several stores, you have two choices when using Stardust:

1. If you have one store for each front-end: define your store (and storeview) in the env file. The variables are STORE_ID and STORE_VIEW_ID.
2. If you want to manage several stores for one store: manage your store in the core and the app store.
   • First define the default storeID and storeViewID in the .env file
   • Modify the store with $useApp/changeStore. This modifies the cookies and the app store.

Define the currency

If you want to define your default currency, you can use en .env variable NUXT_ENV_CURRENCY.
The currency is then defined in the store > app > currency and also registered in cookies.

If you want to change the currency, you can use the action $useApp/changeCurrency.

Define the locale and manage translation

Stardust uses the Nuxt I18n module.

Manage translation in the code

Manage your locales with translation files. You have one file per langage. You can find files in the source code lang > locales > $yourtheme > $locale.json.

For example, if you want to have dynamic content for a button (you want a "send" button in English and an "envoyer" one in French), you have to:

1 . Create a new line in both json translation files.

2 . Write the dynamic translation in your component:

Define the locale to use

The default locale is defined in the .env file (the LOCALE variable). You will have a prefix in your URL to define the locale, except for the default langage.

If you want to change the locale, use the core action router function this.$router.push(this.switchLocalePath(locale)), where you send the new locale code ("en " or "fr").