Standard practices in the Emporix API
Here you can find descriptions of practices, concepts, and data formats that are commonly used across the Emporix API services.
Data standardization
To ensure consistency between the Emporix API services, some data types use standardized formats:
Data type | Description |
---|---|
Countries | Countries are indicated through two-letter codes compliant with the ISO 3166-1 alpha-2 standard. |
Currencies | Currencies are indicated through three-letter codes compliant with the ISO 4217 standard. |
Dates and times | All dates and times are stored as instantaneous moments in the UTC timezone, compliant with the ISO 8601 standard. |
Languages | Languages (including regional variants) are indicated through codes compliant with the IETF BCP-47 standard. |
Mixins
Mixins are custom properties that you can use to describe your business resources in more details. Mixins can be applied to most objects in the Emporix API. Learn more about mixin schemas in Schema Service.
Schemas
To apply a mixin to a resource, you need to define the mixin schema in the form of a JSON Schema object. Mixin schemas need to be uploaded to a hosting service and then referenced in a resource's mixin metadata.
attention
The following Emporix API services do not require mixin schemas:
Here's an example of a JSON schema that defines custom delivery options for customers:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"description": "Mixin schema for delivery options.",
"properties": {
"packaging": {
"type": ["string", "null"],
"description": "Delivery packaging."
},
"hint": {
"type": ["string", "null"],
"description": "Additional information from the customer."
},
"substituteProduct": {
"type": ["boolean"],
"default": false,
"description": "Flag indicating whether products that are out of stock can be substituted."
}
}
}
Usage example
Here's an example of custom delivery options applied inside aCustomer
object with the schema referenced in mixin metadata:{
"mixins": {
"deliveryOptions": {
"packaging": "Paper",
"hint": "If we are not home, the package can be left in front of the door.",
"substituteProduct": true
}
},
"metadata": {
"mixinMetadata": {
"mixins": {
"deliveryOptions": "https://res.cloudinary.com/saas-ag/raw/upload/schemata/deliveryOptionsMixIn.v6.json"
}
}
}
}
How to add mixins to an object
info
Customer
object.- Define your mixin schema.
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"description": "Mixin schema for delivery options.",
"properties": {
"packaging": {
"type": ["string", "null"],
"description": "Delivery packaging."
},
"hint": {
"type": ["string", "null"],
"description": "Additional information from the customer."
},
"substituteProduct": {
"type": ["boolean"],
"default": false,
"description": "Flag indicating whether products that are out of stock can be substituted."
}
}
}
- Upload your schema to a hosting service and save its URL.
- Update an object with mixins and the mixin schema.
Translations
Descriptive fields — such as names or descriptions — can be localized and translated into multiple languages.
In the Emporix Commerce Engine, localized fields are stored in the form of String-String maps, where the keys are language codes and the values are the translations.
info
Language codes must match the ones defined in your language configurations.
For more information on language configurations, check out the Language Configuration Tutorials.
How to create a localized object in a specific language
To create an object where field values are specified in one language, you need to call aPOST
endpoint for a specific resource with the Content-Language
header set to the language's IETF BCP 47 tag.attention
Content-Language
header to a specific language, you need to pass the localized fields as Strings.info
What if I don't specify the fields' language?
If you do not specify a language in which the values are expressed, the Emporix API will assume the values are expressed in your tenant's default language.
Here's an example on how to create a measurement unit with its name in German:
How to create a localized object in multiple languages
To create an object where field values are translated to multiple languages, you need to call aPOST
endpoint for a specific resource with the Content-Language
header set to *
.attention
Content-Language
header to *
, you need to pass the translations as maps of String-String pairs. Here's an example on how to create a measurement unit with its name in multiple languages:
How to retrieve a localized object in a specific language
To retrieve localized fields in one language, you need to call aGET
endpoint for a specific resource with the Accept-Language
header set to the language's IETF BCP 47 tag.Here's an example on how to retrieve a product's localized fields in German:
How to retrieve a localized object in all available languages
To retrieve localized fields in all available languages, you need to call aGET
endpoint for a specific resource with the Accept-Language
header set to *
.Here's an example on how to retrieve a product's localized fields in all available languages:
How to add localized fields to an existing object
To add translations to an existing object's localizable fields, you need to call aPUT
or a PATCH
endpoint for a specific resource with the Content-Language
header set to *
.attention
When you add translations to an existing object, you need to always pass the translations as maps of String-String pairs.
Here's an example on how to add translations to a measurement unit's name: