Entities

The Skill Engine API is built around a domain-driven philosophy: our goal is for functionality to be expressed in the same language that our customers and end users speak. That way, the Skill Engine API maps onto your use case with as little friction as possible. On this page, we briefly describe the available entity types, their meaning and their functionality.

Throughout this developer portal, entities are always capitalised. For example, "Employee" always indicates an Employee entity.

The Skill Engine API currently supports five entity types:

  • Employee: represents either a person within your organisation or a candidate within the job market.
  • Vacancy: corresponds to job postings or open positions.
  • Course: any internal or external training or education.
  • Occupation: a generic role or function defined by your organisation.
  • Document: an informational document produced or used by your organisation.

Each of these entities shares the following properties:

  • An entity always corresponds to a real-life entity in your organisation, and is mapped one-on-one with them. For example, each Employee entity is linked to one (and only one) employee in your core systems.
  • An entity can always be represented by a single, meaningful skill profile.
  • An entity always has explicit lifecycle management: you, as our customer, are in full control about its continued existence.
  • An entity can be configured with custom properties, which can be used for filtering, enhanced matching and advanced querying.
Entityexternal_idcustom_propertiesskill_profileEmployeelocationworking_historyeducation_historylanguagesdesired_functionsemployee_resume...Vacancylocationjob_titlejob_description...Coursecourse_titlecourse_description...Occupationoccupation_nameoccupation_descriptionoccupation_titles...Documenttitle...

Flexible Data Models

We know that your use case may have some unique business logic that you would like to integrate in using our solution. Especially for matchmaking, it's beneficial to apply these constraints within the context of the operations rather than after the fact. For this reason, we have built a system of custom properties, which can be added to every Entity used in the API.

A custom property can be a number, a string, a Boolean, datetime or a list of strings. You can use properties to filter Entities before operations such as matching or employability calculations, as well as to match between them based on your own criteria.

Want to add things like work regimes, country preferences, ratings and much more into the mix? Then custom properties will be your go-to tool. To help you set up your desired custom property configuration, we provide our customers with integration support, so if you want to learn more about how you can map your use case, don't hesitate to get in touch!