Curriculum: High-speed read-only integration (Broker)

The initial setup of the Broker is a handled by a request to the Service Desk. Via this request the Broker will be enabled on your environment.

The next step is to define which data in what state should be made available in the Broker. As stated earlier the standard use case is to only publish data to the Broker that has been approved. Or 'better phrased' has reached as specific status that guarantees the quality and external accessibility of the data. Two options are available.

Option 1: Script automated transfer of published data (advised)

The script automated transfer uses a scheduled script to transfer all published data from the moment executed back to the configured number of days. This allows for instance to transfer data for the last 2 days and run it nightly, and thus sent one day of data twice.

The configuration required is:

• Definition of the hook to set the publication data
• Configuration of the script, frequency (e.d. daily, every 2 hours, ...) and the time overlap

Using the script automated transfer the Broker is not 100% up-to-date, but lacks based on the configured frequency of the script. The frequency can be set based on the requirement.

Option 2: Hook automated transfer of published data

The second option fully handles the exchange of data using a hook. While the hook is executed the user has to wait for it to be finished before a next action can be done.

The configuration required is:

• Definition of two separate hooks: set the publication data and sent to broker
• Definition of a combined hook with that combines the two defined hooks

For more details on the configuration of hooks see the generic integration guide.

‍

The second option can be used for all data exchange to the Broker, but preferably only in specific situations.
This means the default exchange is performed using the script and its the configured delay (based on frequency). The hook is used for specific ad-hoc changes that should be available immediately. In this setup the user is only 'bothered' with a short wait time for changes that should immediately be available.

The API documentation is published on the TimeEdit Developer Hub. The following 2 links are the most important ones:

• Authentication for the service: https://developer.timeedit.com/reference/getting-started‍
• API definition for data retrieval: https://developer.timeedit.com/reference/broker_searchobject‍

In a normal setup the Authentication of the curriculum API and the broker API are equal.

‍

Example: retrieve all modules from a year using a filter

/objects/search?page=1&size=10&sort=code,DESC
{
   "types": ["module"],
   "filters": [
       {
           "name": "data.year.id",
           "operator": "EQUAL_TO",
           "value": “2026"
       },
       {
           "name": "data.localName",
           "operator": "LIKE",
           "value": “Math"
       }
   ]
}

• The url contains the size, which is set to 10. The maximum size returned is 250.
• The url contains sorting information, in this case the code
• In this case the type is set to modules, so only module-data will be returned.
• The filter is set to use the year, which is set to be EQUAL TO 2026
• The localName should contain the 'Math' in the name.

‍

Example: retrieve all modules with after a given publication date

/objects/search?page=1&size=250&sort=data.metadata.publicationDate,ASC&sort=data.key,ASC
{
   "filters": [
       {
           "name": "data.metadata.publicationDate",
           "operator": "GREATER_THAN",
           "value": "2026-02-04T00:00:00.000",
           "valueType": "DATE"
       }
   ]
}

• The url contains the size, which is set to 250.
• The url contains sorting information, in this case sorting should be done on the publication date first, and then the key.
• No type is set, so all object (e.g. module, study, ...) will be returned.
• The filter is set to use the publication date, and it should be after a specific date.
• In this case the valueType is added to express publicationDate is a date field. The default is string.

By configuring the sorting to be based on publication date and secondly on key (db id) the result will support a deterministic sort for paged traversals.

The supported operators are:

• EQUAL_TO
• LESS_THAN
• LESS_OR_EQUAL
• LIKE
• GREATER_THAN
• GREATER_OR_EQUAL

‍

OOAPI support

Next to the Curriculum / Broker generic API, there is also support for the OOAPI used to exchange data with eduXchange. The supported OOAPI services are:

• Organization
• Specification
• Programs
• Courses
• Offerings