shippinginyectionext icon

shippinginyectionext

1.0.x
(0 reviews)

Home EN

shippinginyectionext

Shipping information injection

Description:

This API allows you to upload information regarding one or more shipments to the Correos applications that need to consult or show the traceability of these shipments (RODA, Minerva, etc.).

API Details:

Using this API

This Api has a single endpoint (/api2kinbulto) which receives a JSON message with several fields such as the data of the person sending the shipment, references to the Correos Office(s) that managed the shipment or the data of the recipient (see example). This message is processed by a microservice that, if there are no errors in the structure of the message that prevent the information from being processed, propagates the information to different Correos-Trazabilidad applications.

JSON request example:

curl "https://api1.correos.es/support/shippinginyection/api/v1/api2kinbulto

  "inputData": {
    "addedValues": [
      {
        "addedValueType": 13,
        "deliveryAttempts": 9
      },
      {
        "addedValueType": 16,
        "activeAdditionalManagement": false,
        "managementTask": "ENTREGA EXCLUSIVA AL DESTINATARIO TITULAR DEL ENVIO. No entregar si no nos presentan DNI original d"
      },
      {
        "addedValueType": 19,
        "timeZone": "01"
      },
      {
        "addedValueType": 8,
        "returnItemCode": "62215100015030001000119"
      }
    ],
    "createdOn": "2023-06-01T15:15:15+01:00",
    "deliveryOfficeCode": "12345678",
    "shipmentId": "63300020049654101280058",
    "collectionolddevice": "S",
    "productCode": "X0",
    "itemsQuantity": 2,
    "customerShipmentCode": "PKJ1510001503000100123P",
    "ownerCode": "X",
    "createdAt": "22",
    "sourceApp": "22",
    "partialDelivery": false,
    "referenceShipmentCode": "PKJ1510123",
    "printedReference": "printedReference_TEST",
    "recipient": {
      "firstName": "Leonardo",
      "LastName1": "Tortuga López",
      "customerCode": "123456",
      "phoneNumber": "600123456",
      "email": "leo@mail.com",
      "latitude": 42.45598622792,
      "longitude": -2.44503402069,
      "address": {
        "cityName": "Madrid",
        "countryCode": "ESP",
        "fullAddress": "Plaza Galápagos, 13, 28080 Madrid, España",
        "postalCode": "28080"
      },
      "doi": {
        "code": "99452784"
      },
      "contact": {
        "value": "ALFONSO ALONSO"
      }
    },
    "sender": {
      "firstName": "Leonardo",
      "LastName1": "Tortuga López",
      "customerCode": "123456",
      "phoneNumber": "600123456",
      "email": "leo@mail.com",
      "observations": "Entregar por la mañana",
      "address": {
        "cityName": "Madrid",
        "countryCode": "ESP",
        "fullAddress": "Plaza Galápagos, 13, 28080 Madrid, España",
        "postalCode": "28080"
      },
      "doi": {
        "code": "99452784"
      },
      "contact": {
        "value": "ALFONSO ALONSO"
      }
    },
    "items": [
      {
        "createdOn": "2023-06-01T15:15:15+01:00",
        "shipmentCreatedOn": "2023-06-01T15:15:15+01:00",
        "id": "62215100015030001000119",
        "status": {
          "id": 22,
          "statusDate": "2023-06-01T15:15:15+01:00",
            "reportingNode":"12345678"
        },
        "itemNumber": 1,
        "height": 200,
        "wide": 100,
        "large": 200,
        "weight": 500,
        "realVolume": 3,
        "itemCertainDate": "2022-06-01T15:15:15+01:00",
        "createdAt": "22",
        "customerItemCode": "89350124046054104580529",
        "referenceOfficeCodeCex": "12345678",
        "terminalId": "S1000396D",
        "openCode": "12345678",
        "committedDateDetail": "24/07/2023 10:00-13:00 14:00-18:00",
        "safeDelivery": 0,
        "amounts": [
          {
            "base": 15.5,
            "iban": "ES2201822370410201508813",
            "total": 30.4,
            "type": "065"
          }
        ]
      }
    ]
  }

In this way, a flow is created whose objective is to know all the traceability information of a shipment.

Note: Being an information injection API, we only receive an Ok message in response if the ingestion process has been successful or, on the contrary, a specific error that has made the process impossible.

Request API access

From the Exchange itself, or the API access portal you are using, there will be a Request Access option. If you do not see this option, then that API does not support access requests.

Before a client application is allowed to consume an API, it must request access to the API. Once access is requested, the request goes through an approval flow. Once this flow is completed, and approved by the API owner, you will receive an email with the access credentials (if defined).

Usage levels

APIS can have different usage levels defined. When requesting access to an API you will see indications of the usage level (SLA) that the API offers. Note that some usage levels may have a cost associated with them.

To find out which usage levels apply to your API you can review the API Overview

Security policies

There are several security policies that can be applied to APIS. An API offered by Posts may carry none, one or several of these policies.

For the security policies that apply to your API you can review the API Overview.

Security policies:
    - Rate limiting SLA based
    - CORS

Rate limiting SLA based

The Rate-Limiting Service Level Agreement (SLA) based policy enables you to control incoming traffic to an API by limiting the number of requests that the API can receive within a given timespan. When the limit is reached before the time expires, the policy rejects all requests.

To apply the Rate-Limiting SLA policy to an API, you must first create a contract between the API and a registered client application, that is the number of requests that an API can receive within a given time.

Each request must be identified by a client ID and an optional client secret (see Client ID Enforcement).

Is necessary to include something in the API call with Rate Limiting?: There is no need to make any modifications to an API calls, the Rate limiting restriction is defined when publishing the API in MuleSoft.

Client ID Enforcement

Client ID Enforcement Policy (included in the Rate limiting SLA based): The API expects headers with key/value pairs in its requests.

Before a client application is allowed to consume an API protected by this policy, access to the API must be requested. After an approved contract exists between the client application and the API, each request must include the client application's credentials in accordance with the policy configuration.

The credentials will go as headers of the request as shown in the following example of a request using curl:

curl "http://example.restapi.es/myResource" -H "client_id:1234" -H "client_secret:abcd"

CORS

CORS (Cross-Origin Resource Sharing) is a mechanism by which a web application can access resources defined in another domain. Browsers implement this standard by default. The CORS policy complies with the CORS W3C Standard recommendation.

The most common use of this policy is in browsers that detect API calls from JavaScript code that invoke a URL that is not from the same domain from which the page was downloaded.

When your web pages request data, the browser detects whether the request comes from the same source and determines whether the CORS algorithm is applied. The CORS algorithm works on the web server (backend) and on the client side of the web page that requested the information (browser). If the backend does not accept the origin, the backend server responds to the request without a specific header. This way, the client (browser) understands that the page origin is not allowed on that server and does not execute the actual request.

The allowed origins from which the API can be invoked are defined on the server side

Is necessary to include something in the API call with CORS?: There is no need to make any modifications to an API calls, the origins allowed in the CORS policy are defined on the server side.

Introduction using to API REST

REST APIs use Uniform Resource Identifiers (URI) to direct resources. Well-made URIs designs would clearly communicate the API resource, such as:


[http://example.restapi.es/france/paris/louvre/leonardo-da-vinci/mona-lisa](http://example.restapi.es/france/paris/louvre/leonardo-da-vinci/mona-lisa)

An incorrect design of the URIs would give a resource that is much more difficult to understand such as:

http://example.restapi.es/68dd0-a9d3-11e0-9f1c-0800200c9a66

URI format

The generic URI format is defined like this:

URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]

  • scheme: The scheme identifies the resource access protocol (http, https)
  • authority: It is the hierarchical element that identifies the naming authority, it is made up of the host name and the port.
  • path: The path is the most specific part of the URI that indicates the path or location of the resource within the server. The path can include deep hierarchies and often reflects the organizational structure of resources.
  • query: It is an optional component that comes after the path and has a non-hierarchical structure, providing a string of information that the resource can use for some purpose, for example, to look up parameters or data to process. The query is usually a string of parameter-value pairs ("argument=value"). The arguments along with the values ​​are separated from each other with an ampersand ("&").
  • fragment: The fragment is an optional component that allows you to identify a part of the main resource, or the view of a representation of it. The beginning of this component is indicated by the pound character ("#").

Reviews