Use case 14

Loading and unloading areas

Use case 14 is dedicated to information regarding loading and unloading areas.

This use case aims to collect and publish in a centralized and homogeneous way the information related to the loading and unloading areas of the different cities/municipalities of the national territory. It allows suppliers to send information to the DGT 3.0 platform in real time about the characteristics that limit loading and unloading areas. Consumers will be able to publish the information in their information systems accessible by the end user, allowing the latter to anticipate loading and unloading areas in advance in the development of their trajectory.

The platform has a functionality for publication (sending) and a functionality for subscription (consumption) of information through a REST API.

The publication functionality requires an access certificate that must be requested and supplied by DGT 3.0. This certificate, if not already requested, must be requested to soporte@cmobility30.es.

Below are the URLs with which each functionality is accessed:

Mode URL Description
Publication https://pre.cmobility30.es/use-case-14 Client integration environment endpoint for publishing (certain publishing methods will be accessible for consumption)
Suscription (Consumer) https://pre.cmobility30.es/use-case-14 Integration environment endpoint for subscription

The functionalities are described below:


This use case has a REST API for the publication (sending) of the data by the companies that request it. Details of this can be found in the following sections:

  • General details for making a request:

General · (cmobility30.es)

  • Information regarding the specific methods of the use case:

Publication methods

Note: Some publication methods for obtaining information may also be used by consumers.

Suscription (Consumer)

This use case has a REST API for data consumption by the companies that request it. Details of this can be found in the following sections:

  • Information regarding the specific methods of the use case:

Suscription methods


As stated above, all HTTP responses other than 200 – OK, can be considered invalid. The format of the error response is like the following example:

    "status": 401,
    "code": 1,
    "message": "User not found or valid"

These errors will have three main categories:

Authentication Error

  • HTTP Status: 401 - Unauthorized

    Code Message
    1 User not found or valid

Client Error

  • HTTP Status: 400 - Bad Request

    Code Message
    0 Authenticate
    2 Entity ID not found
    3 Missing required property
    4 The entity received cannot be proccessed
    5 Incorrect token received
    6 Expired token received
    7 There is an error with the token provided. Please request a new one
    8 No token received
    9 Required request body is missing
    10 Event is marked as expired by timestamp
    11 Missing request header
    12 Access denied role
    13 Unique key violated
    14 There is an error in one or more elements
    15 Invalid GeoJson
    16 GeoJson does not belong to municipality

In the case of getting an error 3 - Missing required property, the response obtained will have a value in the message that will indicate the missing fields to send:

    "status": 400,
    "code": 3,
    "message": "[municipalityIneCode: must not be null, capacity: must not be null]"

Server Error

  • HTTP Status: 500 - Internal Server Error

    Code Message
    18 Internal error