Slot Types

A slot is an attribute of a specific intent. A slot is specified by two attributes: type and name. For example, the slots associated to the searchWeatherForecast intent would be:

  • The city slot has a custom slot type, whose values must me manually specified.

  • The forecast_datetime slot has a built-in type snips/datetime which means that the assistant uses a pre-trained detection algorithm.

Three types of slots can be handled by the NLU engine: custom, default and built-in slot types.

Default slot type

By default, a new slot has the default slot type. This default slot type does not allow you to specify values and synonyms for the slot, aside from the values that are defined in the examples of queries provided for the intent. If you want to extend the list of values for a slot, please consider creating a custom slot type.

Custom slot type

Custom slot type allows you to define your own slot type. Custom slot types are meant for two major use cases:

  1. You want to manually specify all the values for a given slot type, and specify synonyms.

  2. You plan to reuse a certain slot type between several custom intents. Let’s assume you want to build an assistant for a restaurant. You may want to create intents such as createOrder, cancelOrder, etc. All these intents may share an ordered_dish slot type. Defining a common custom slot type for ordered_dish allows you to extend its value list with all the values found in the intents that include this slot type.

If you want to learn more about how to create a custom slot type, go to this tutorial for more details.

We're also providing a feature called "auto-suggest" that will allow you to automatically enrich your custom slot type with hundreds of values via our Wikidata powered tool. This feature allows you to save time, and will prevent you from doing the cumbersome work of writing / thinking of all the possible values for a given slot type. Note: this feature does is not available for all languages.

Built-in slot type

The built-in slot type can be used by everyone out of the box. It is strongly advised to use them when specifying your intent's slots whenever possible. They come with powerful built-in entity detectors that have been specifically trained to detect these types.

Let's assume you're building an intent such as bookRestaurant with slots party_size, and reservation_datetime. You would specify slot types for both of these slots as being built-in ones:

  • party_size: snips/number

  • reservation_datetime: snips/datetime

The following built-in slot types are available depending on the language:

  • Numeric entities:number,ordinal,amountOfMoney, percentage, temperature

  • Time related entities: datetime, duration

  • Music entities: musicArtist, musicAlbum, musicTrack

You will find below a detailed table for each type of entity with related built-in slot type categories, supported languages, units and ranges, possible values and serialization examples.

Numeric entities

Supported languages




Additional information

en, fr, pt-br, es, it, de, ja


Integer number, positive or negative

twenty-two minus one hundred three million seventy-five

Supported range:

-999.999.999.999 to 999.999.999.999

Serialization example

twenty-two { "kind": "Number", "value": 22.0 }

en, fr, pt-br, es, it, de, ja


Ordinal number

second tenth twenty-third

  • Supported range for en, fr, it, de, ja: 1st to 1000th

  • Supported range for es: 1st to 20th

  • Supported range for pt-br: 1st to billionth

Serialization example

second { "kind": "Ordinal", "value": 2 }

en, fr, pt-br, es, it, de, ja


Amount of money (decimal or integer number + major currencies)

10.05€ ten dollars eight hundred twenty-two pesos

  • Supported currencies: $, USD, AUD, CAD, HKD, EUR, £, GBP, CHF, KR, DKK, NOK, SEK, RUB, INR, JPY, CNY, ¥, KRW, ฿

  • For currencies that share part of the name (e.g. dollars, US dollars, Hong Kong dollars), the currency is resolved as $ if there is no more info given (dollar). Otherwise US dollars is resolved as USD

  • Supported range for en, fr, pt-br, es, it, de: 0 to 999.999.999.999

  • Supported range for ja: 0 to 99.999.999

  • Decimal numbers only supported in French at the moment

Serialization example

10.05€ { "kind": "AmountOfMoney", "value":10.05, "precision": "Approximate", "unit": "€" }

one dollar { "kind": "AmountOfMoney", "value": 1, "precision": "Exact", "unit": "$" }, five American dollars { "kind": "AmountOfMoney", "value": 5, "precision": "Exact", "unit": "USD" }

en, fr, pt-br, es, it, de, ja



25% fifty-two percent one hundred percent

Serialization example

25% { "kind": "Percentage", "value": 25.0 }

en, fr, pt-br, es, it, de, ja



70 Kelvin -3°C twenty-three degrees one hundred degrees Fahrenheit

Positive or negative temperatures expressed in degrees, Celsius, Kelvin or Fahrenheit

Serialization example

70 Kelvin { "kind": "Temperature", "value": 70.0, "unit": "kelvin"}

one degree { "kind": "Temperature", "value": 1, "unit": "degree"} minus three degrees celsius { "kind": "Temperature", "value": -3, "unit": "celsius"}

We have two kinds of entities for time: date/time and duration.

Date/Time entities

These are expressions of time that can be positioned in time (whereas durations can not).

1. Available Languages

In English, French and Brazilian Portuguese, 5 different slot types are available for dates and times:

  • time

  • time-period

  • date

  • date-period

  • datetime

In German, Spanish, Italian and Japanese, a single slot is currently available: datetime.

See description of these slot types and examples in the chart below.

2. Resolution of date/time expressions

In NLU, the distinction between time, time-period, date, date-period and datetime is not relevant. The NLU distinguishes between two kinds of dates and times:

  • Instant Times e.g. "tomorrow at 7:30pm"

  • Time Intervals e.g. "from Monday to Wednesday"

a. Resolution of Instant Times

Instant time = expression of time that can be understood as a single time unit (a cycle, with a specific grain) positioned at a specific moment. Examples:

  • "now" (grain: second)

  • "tomorrow at 7:30pm" (grain: minute)

  • "around seven o'clock" (grain: hour)

  • "on the day before yesterday" (grain: day)

  • "next week" (grain: week)

  • "for January 2019" (grain: month)

  • "this quarter" (grain: quarter)

  • "in 2020" (grain: year)

Resolution in the console: kind: InstantTime, value: <date + time (yyyy-mm-dd hh:mm:ss)>, grain: <Year, Quarter, Month, Week, Day, Hour, Minute, Second>; precision: <“Exact”, “Approximate">

b. Resolution of Time Intervals

Time interval = expression of time consisting of multiple successive time units, and that can be positioned in time. Time intervals can be of three kinds:

1 - Has an explicit starting point and an explicit finishing point:

  • "from today 3 pm to tomorrow 8 am" (starting point: today 3 pm, finishing point: tomorrow 8 am)

  • "from Monday to Wednesday" (starting point: Monday, finishing point: Wednesday)

2 - The starting point or the finishing point is implicit:

  • "for the next two hours" (starting point [implicit]: now, finishing point: in 2 hours)

  • "during the last three weeks" (starting point: 3 weeks ago, finishing point [implicit]: now)

The implicit starting or finishing point is not exactly now, but some definite time near now. In "for the next two hours", the starting point is actually the beginning of the next hour, not the exact moment of enunciation.

3 - The starting point or the finishing point is undefined:

  • "until next year" (starting point: undefined, finishing point: next year)

  • "since last Friday" (starting point: last Friday, finishing point: undefined)

Resolution in the console: kind: TimeInterval, from: <starting point (always included in the time interval)>, to: <finishing point (always excluded from the time interval)>

Supported languages




en, fr, pt-br


Time of day

at five pm at seven and a half ten in the evening

Serialization example

at five pm { "kind": "InstantTime", "value": "2019-09-17 17:00:00 +00:00", "grain": "Hour", "precision":"Exact" }

en, fr, pt-br


Interval or period at time of day level

between five am and two pm from noon to midnight after ten in the morning in the afternoon

Serialization example

between five am and two pm { "kind": "TimeInterval", "from": "2019-09-17 05:00:00 +00:00", "to": "2019-09-17 14:00:00 +00:00" }

en, fr, pt-br



tomorrow on Monday on the fifth of July 2018 five days ago in ten days

Serialization example

tomorrow { "kind": "InstantTime", "value": "2019-09-18 00:00:00 +00:00", "grain": "Day", "precision":"Exact" }

en, fr, pt-br


Date interval or period spanning over more than 1 day

during the week-end in summer since June 10th from Monday to Friday

Serialization example

during the week-end { "kind": "TimeInterval", "from": "2019-09-20 18:00:00 +00:00", "to": "2019-09-23 00:00:00 +00:00" }

en, fr, pt-br, es, it, de, ja


Time, time period, date, date poriod, or combination of date and time (or time period)

seven pm (InstantTime) at midnight (InstantTime) from five am to noon (TimeInterval) this morning (TimeInterval) on the third of July 2020 (InstantTime) next Monday (InstantTime) from yesterday until tomorrow (TimeInterval) during the next summer (TimeInterval) june second at quarter to ten in the evening (InstantTime) from five to six pm tomorrow (TimeInterval) this morning (TimeInterval) at ten in the evening on Christmas day (InstantTime) yesterday morning (TimeInterval) from yesterday to next Monday at two thirty pm (TimeInterval)

Serialization example

seven pm { "kind": "InstantTime", "value": "2019-09-17 19:00:00 +00:00", "grain": "Hour", "precision": "Exact" } june second at quarter to ten in the evening { "kind": "InstantTime", "value": "2020-06-02 21:45:00 +00:00", "grain": "Minute", "precision": "Exact" } from five to six pm tomorrow { "kind": "TimeInterval", "from": "2019-09-18 17:00:00 +00:00", "to": "2019-09-18 18:00:00 +00:00" }

Duration entities

Expressions of time that can NOT be positioned in time. This means that starting and finishing points are not defined, neither explicitly nor implicitly. Examples:

  • "for 3 years"

  • "during two hours and five minutes"

Resolution in the console: kind: Duration, years: <nb>, quarters: <nb>, months: <nb>, weeks: <nb>, days: <nb>, hours: <nb>, minutes: <nb>, seconds: <nb>, precision: <“Exact”, “Approximate">

Supported languages




Additional information

en, fr, pt-br, es, it, de, ja


Time duration

three months four seconds eight years five hours fifteen minutes and eight seconds

Serialization example

three months four seconds { "kind": "Duration", "years": 0, "quarters": 0, "months": 3, "weeks": 0, "days": 0, "hours": 0, "minutes": 0, "seconds": 4, "precision": "Exact" }

Music entities

Supported languages




Additional information

en, fr


Artist or band name

Radiohead Queen Madonna Björk

Serialization example

Radiohead { "kind":"MusicArtist", "value": "Radiohead" }

en, fr


Album name

Nevermind Thriller OK Computer London Calling

Serialization example

Nevermind { "kind": "MusicAlbum", "value": "Nevermind" }

en, fr


Song name

Bohemian Rhapsody Call me Respect Fake plastic trees

Serialization example

Bohemian Rhapsody { "kind": "MusicTrack", "value": "Bohemian Rhapsody" }

Required slots and dialog

In some cases, an application requires certain slots to be present for a command to be processed. This could for example be the case for a moneyTransfer intent, requiring an amount slot. Using the web console, you can choose to force the presence of a specific slot in an intent. If the assistant detects an intent but does not identify the required slot in the query, it will ask the user for the value of the slot. You can define in the console the question to ask the user when a slot is missing.