0% found this document useful (0 votes)
119 views48 pages

CBIC Port Message Integration Specification Document v1.0

The document outlines APIs that will enable communication between ports and Indian Customs. It describes APIs for conveying call numbers, arrival/departure times, equipment reports, and customs messages. The APIs will use base64 encoding and digital signatures for security. Authentication will be via OAuth2.0.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
119 views48 pages

CBIC Port Message Integration Specification Document v1.0

The document outlines APIs that will enable communication between ports and Indian Customs. It describes APIs for conveying call numbers, arrival/departure times, equipment reports, and customs messages. The APIs will use base64 encoding and digital signatures for security. Authentication will be via OAuth2.0.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 48

CBIC - Port Message Integration Specification Document

Customs-Port Message Integration Specification Document

1
CBIC - Port Message Integration Specification Document

1. Document Title Customs-Port Message


Integration Specification
Document
2. Date of Release 04-08-2020
3. Version No. Version 1.0
4. Document Owner CBIC-ICEGATE

Document Change Approvals


S.No. Type of document Type of change Version Creator Update
1 API Design Original Version V1.0 CBIC - Raw Document
Document

2
CBIC - Port Message Integration Specification Document

Table of Contents
1. Introduction.........................................................................................................................................4
2. Purpose of the Document....................................................................................................................4
3. Mode of Implementation....................................................................................................................4
3.1 Base 64 Encoded, Cryptographic & Digital Signature Approach..................................................5
4. Authentication and Authorization.......................................................................................................5
5. APIs to be Developed...........................................................................................................................6
6. API Specification..................................................................................................................................6
6.1 API communicating Conveyance Call Number (VCN)...................................................................6
6.1.1 API Overview........................................................................................................................7
6.1.2 API Format...........................................................................................................................7
6.1.3 POST API Format – Posting VCN data to ICEGATE................................................................8
6.1.4 POST API Format – VCN acknowledgement sent to Port...................................................14
6.1.5 Error Code with Description....................................................................................................19
6.2 ATE – Actual Time Event - API Reporting actual Arrival / Departure Time................................19
6.2.1 API Overview......................................................................................................................19
6.2.2 POST API Format – To post Arrival/Departure Details to Customs....................................20
6.2.3 POST API Format – Arrival/Departure Details Acknowledgment.......................................26
6.2.4 Arrival Time JSON Schema and Sample..............................................................................29
6.2.6 Error Code With Description..................................................................................................29
6.3 ELR API - API Reporting Equipment Landed / Loaded Report....................................................30
6.3.1 API Overview......................................................................................................................30
6.3.2 POST API Format – To post Equipment Landed/Loaded Data to Customs.........................30
6.3.3 POST API Format – Equipment Landed/Loaded Details Acknowledgment........................36
6.3.4 Equipment Landed JSON Schema and Sample...................................................................39
6.3.6 Error Code With Description...................................................................................................39
6.4 CCM API – API Reporting Custom Control Message (EI, EO, PC, CH)..........................................40
6.4.1 API Overview......................................................................................................................40
6.4.2 API Format.........................................................................................................................41
6.4.3 First POST API...........................................................................................................................41
6.4.4 Second POST API.......................................................................................................................44
6.4.5 CCM API – API Reporting Customs Control Message (EI,EO,PC)) – Schema & Sample files48

3
CBIC - Port Message Integration Specification Document

1. Introduction

Ports play vital role in the overall economic development. About 95 percent by volume and 70
percent by value of the India’s international trade is carried on through maritime transport.
To enabling secure exchange of information between public and private stakeholders w.r.t. port
to improve the port operations, an open electronic platform has been envisaged to be
developed for port operation. The system optimizes, manages and automates port and logistics
processes operate at ports through online submission of data.

2. Purpose of the Document

To cover business requirement of ports, an integrated solution is proposed to be developed for


to handling of port operations. The communication between Ports & Indian Customs is a two-
way communication:
 For all Inbound messages to Customs from Ports, Customs will develop Post API and
expose them to Ports. Ports will invoke the Customs API to transmit data based on the
events defined in this document.
Upon receipt of this data, Indian Customs will update its database and make available an
ACK to Ports. e.g. – VCN

 For all Outbound messages from Customs to Ports, ICEGATE will develop and expose the
POST API. Ports system will invoke the POST API to fetch the data based on the events
defined in this document.

Upon receipt of this data Ports will store the data in its database and send an ACK back
to Customs.
The document mentioning the details of the APIs to be exchanged between Custom & Port
System. The content of this document is meant to act as a guideline for exchanging details
through API from both the end.

3. Mode of Implementation

Real time RESTful APIs will be developed at both the ends (Ports and ICEGATE). Following are the APIs to
be developed:

1. Two POST APIs shall be developed for each of the following three messages, first API to post the
data to Customs and second API (ACK API) to get the acknowledgment of the first API request:
a. Communication of Conveyance Call Number (e.g VCN)
b. Intimation of Actual Time of Arrival/Departure of Conveyance
c. Intimation of Transport Equipment’s Landed/Loaded in the conveyance

POST API Usage - The API will be developed & exposed by ICEGATE, Ports will consume the same.

4
CBIC - Port Message Integration Specification Document

2. Two POST APIs shall be developed for Customs Control Messages (e.g Entry Inwards, Entry
Outwards etc.):
a. First API is to get the details in bulk
b. Second API is to get the status of individual record

POST APIs Usage: These APIs shall be developed & exposed by ICEGATE and Ports will consume the
same.

Each payload and Acknowledgement from the respective senders will be base 64 encoded and
digitally signed.

3.1 Base 64 Encoded, Cryptographic & Digital Signature Approach

Stage 1: At Sender – Sharing the Payload with ICEGATE

1. Payload will be generated at Sender’s end and the same will be digitally signed by signer utility
2. Signed payload shall be encrypted with AES 256 bit encryption algorithm (with Secret key, which
would be of 32 bit).
3. Encrypted payload will be encoded using base64 encoder

Stage 2. At Receiver – Receiver of the Payload

1. Received encoded payload will be decoded with base64 decoder. Outcome will be encrypted
payload
2. Encrypted payload will be decrypted using AES 256 bit decryption algorithm with shared Secret
key. Outcome will be signed payload
3. Signed payload will be verified at receiver end using verify utility.

NOTE: Secret Key will be shared by ICEGATE to Ports, which is a onetime setup.

4. Authentication and Authorization

- Oauth2.0 used for ensuring Client reliability and to define access rights.
- Client application needs to be registered at Custom External API Gateway.
- CBIC External API Gateway enabled Oauth 2.0 Authentication and Authorization
Servers. To post the data in ICEGATE, sender need to invoke Auth API with registered
client-id and JWT token
- Post user validation by CBIC API Gateway, Access-Token will be generated and shared
with requesting party, as a response of their invoking request.
- Payload shared through REST POST request, hit the Custom interface with bearer
(Access-Token), for storing Payload Data at ICEGATE end.

5
CBIC - Port Message Integration Specification Document

5. APIs to be Developed

Following APIs shall be developed as a part of the API integration:

S.No Message Message Exposed


API Description Invoked By
. ID flow By

Communication of Conveyance Call Number (e.g Port to Port (Request submitted


PCCHC01 ICEGATE
VCN) Customs through POST method)
1
PCCHC01 Acknowledgment of Communication of Customs Port (Request submitted
ICEGATE
Ack Conveyance Call Number (e.g VCN) to Port through POST method)

Intimation of Actual Time of Arrival/Departure of Port to Port (Request submitted


PCCHC02
Conveyance Customs through POST method)
2 ICEGATE
PCCHC02 Acknowledgment of Intimation of Actual Time of Customs Port (Request submitted
Ack Arrival/Departure of Conveyance to Port through POST method)

Intimation of Transport Equipment’s Port to Port (Request submitted


PCCHC03
Landed/Loaded in the conveyance Customs through POST method)
3 ICEGATE
PCCHC03 Acknowledgement of Intimation of Transport Customs Port (Request submitted
ACK Equipment’s Landed/Loaded in the conveyance to Port through POST method)
To get the count of the records regarding
Customs Port (Request submitted
PCCHC04 Customs Controls (e.g Entry Inwards, Entry
to Port through POST method)
Outwards, Port Clearance)
4 ICEGATE
PCCHC04 To get the individual record on the inputs Customs Port (Request submitted
Ack received in First API using some fields to Port through POST method)

6. API Specification

6.1 API communicating Conveyance Call Number (VCN)

This API will be invoked by sender to post data to Custom. Upon receiving the request for
Voyage Registration (CALINF) from the Authorized Sea Carrier / Authorized Sea Agent, port
generate Voyage Number Which will share with Custom for further processing. Ports will share
these details to ICGEATE through API post receiving CALINV EDI request message from the port
after receiving approval of competent port authority.

6.1.1 API Overview

6
CBIC - Port Message Integration Specification Document

CBIC exposed POST API to take payload from the Ports application on real time basis.
Ports application will invoke this API when ready to push the details to Custom. As a response,
ACK will sent back to Ports.

6.1.2 API Format

This section describes standard format which will be used to define API exposed at CBIC
interface. This API will be published as stateless REST API over HTTPS.
Below table depicts the URI pattern to be used, content type, payload while defining API end
points along with API response:
API Endpoint Defined by Custom

Method Type POST


Content Type Application / JSON
URL Description
http/https All API will be published in production over
HTTPS only. HTTP protocol will be used in non-
production environments.
domain-name Domain name of Custom API Gateway
Request Validation Header
Access Bearer Used for sender validation at receiver end
Request Request ID
Number
Request Date Request date & time
& Time

7
CBIC - Port Message Integration Specification Document

Service Service ID
Number
Channel Customs Channel ID
Number
Flag Test (T) / production (P) indicator
Requestor ID ICEGATE ID of the Requestor

Request Payload
All the request parameters for this API shall be sent with POST request. This data will be
Base64 encoded JSON payload, digitally signed by communicating
stakeholders/partners. The browser request shall have the following parameters:
Parameter Description
Bearer/Access- Sender will obtain this parameter post successful
Token/Client- validation at CBIC external API Gateway with Client-
ID Id and Password.
Payload Data Payload generated as per defined schema at
stakeholder/partner end. This data will be encoded,
digitally signed and encrypted as per the SOP approach.
Request Sample JSON and Schema have listed for each API
payload.
6.1.3 POST API Format – Posting VCN data to ICEGATE

Request Payload Header:


Payload header detailing the type of document exchanged, reference number, sender &
receiver identity may along with the IDs of notified parties.
The following are the list of parameters that will be passed in the payload Header of
request:
Parameter Description
Doc Type PCCHC01
( VARCHAR2 (14) )
Comm Number assigned to the Payload request by sender
Ref. No. ( NUMBER (35) )

Sender ID ICEGATE ID of Terminal Operator Code


( VARCHAR2 (10) )
Receiver Port Code of particular place
ID ( VARCHAR2 (10) )

8
CBIC - Port Message Integration Specification Document

Parameter Description
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all)
( VARCHAR2 (10) )

6.1.3.1 Attributes Details – Request Payload

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
Requestor ID VARCHAR2(35) M ICEGATE ID of the requestor

Record CHAR (1) M Record/Message type may be


Type one of the following:
FRESH - F
Cancel – C
Voyage Call VARCHAR2(35) M Unique number assigned by
Number Operator for a Voyage

Format: Location Code (6


chars) + Year (4 digits) + 4
digits running serial no.

e.g: INBOM1+2019+0001
(INBOM120190001)

Mode Of VARCHAR2(4) M Mode of Transport used for


Transport crossing the
Border/Movement, Coded

Values:1- Sea, 2- Rail, 3-


Truck, 4- Air

Type of VARCHAR2(2) M The type of identifier of the


Transport means of transport used in
Means crossing the
border/Movement, coded.

Values: Refer below Code List


Table – A

Identity of the VARCHAR2(25) M Unique identifier for ships /


Transport registered ship management

9
CBIC - Port Message Integration Specification Document

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
Means companies. Values will be:
IMO/IATA/Lloyd

This would normally be 7


digit IMO Number for vessel
movement

Vessel Code VARCHAR2(25) O check if available in VCN


(Call sign)

Voyage VARCHAR2 M Unique number assigned by


Number (10) Operator for a voyage

Type of Vessel VARCHAR2(8) M E – Empty Vessel C – With Cargo


For Vessel Type C – At least
one Cargo line must be filed.
Also for Containerized cargo,
at least one Container line
must be filed.

Purpose of Call VARCHAR2(3) O Standard Code Available

Values: Refer Table-B below

Shipping Agent VARCHAR2 O Shipping Agent Code


Code (17)

Line Code VARCHAR2 M MLO Code


(17)

Terminal VARCHAR2 M Code of Terminal Operator


Operator Code (17)

Port Code CHAR (6) M Port Code of Reporting

Expected Date TIMESTAMP M The date and time the ship is


and Time of estimated to arrive at the port
Arrival (EDTA) of Call.

Expected Date TIMESTAMP M The date and time the ship is


and Time of estimated to depart at the
Departure port of call.
(EDTD)
Service Name VARCHAR2(10) O

10
CBIC - Port Message Integration Specification Document

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
Allotment Date DATE M Voyage Number Allotment
Date

6.1.3.2 Response Payload

Below table depicts the proposed URL, content type, payload while sending API response:
API response endpoint URL URL defined by ICEGATE

Method POST
Content Type Application/JSON
URL Description
http/https All API will be published in production
over HTTPS only. HTTP protocol will be
used in non-production environments.

Response Data
Synchronous Response parameters for this API shall be sent with POST. This data will be Base64
encoded JSON payload, digitally signed by communicating stakeholders/partners. The browser
URL payload shall have the following parameters:

Response from CBIC system for this API will be in the following format:
Parameter Description

Requestor ID ICEGATE ID of the Requestor

Common Common Reference Number of request cluster


Reference
Number
ACK-ID Generated at Custom end for every transaction, post receiving
the data
Request Status Error Code of the status. It is the structural validation of the

11
CBIC - Port Message Integration Specification Document

Parameter Description

payload at ICEGATE before inserting the data into database (to


be provided by ICEGATE)
SCERR01 error code will be used, if any error occurred.
Status ACK Message - Data successfully inserted into database
Description NAK Message – Data insertion has been failed

Attribute Details
Attribute Data Type Mandatory Description
Name with Size / /Remarks
Optional
Requesto VARCHAR2(35) M ICEGATE ID
r ID of the
Requestor
Common VARCHAR2(25) M Common
Reference Reference
Number Number of
request
cluster
ACK-ID VARCHAR2 M Generated
(28) at Custom
end for
every
transaction,
post
successful
schema
validation
REQUEST VARCHAR2(6) M 000 for success, else
STATUS error code along
with error
appropriate brief
will be provided.
STATUS VARCHAR2(30) M ACK
DESCRIPT Message -
ION Data
successfully
inserted into
database
NAK
Message –
Data

12
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
insertion has
been failed

ACK Response

{
"status": "success",
"errorCode": "000",
"comRefNum": "2019062649815390",
"message": "data integrated",
"senderID": "Port ICEGATEID ",
"ackID": "20081916573396467746447453813"
}

NAK Response

{
"status": "failure",
"errorCode": "SCERR01",
"comRefNum": "2019062649815390",
"message": "Schema Validation Failed due to bellow Error:\r\n\r\nerror: object has
missing required properties ([\"icegatePayload\"])\n level: \"error\"\n schema:
{\"loadingURI\":\"#\",\"pointer\":\"\"}\n instance: {\"pointer\":\"\"}\n
domain: \"validation\"\n keyword: \"required\"\n required: [\"icegatePayload\"]\n
missing: [\"icegatePayload\"]\ninValid json file",
"senderID": "Port ICEGATEID",
"ackID": "2008191656917722894179565488"
}

13
CBIC - Port Message Integration Specification Document

6.1.4 POST API Format – VCN acknowledgement sent to Port

Request Payload Header:


Payload header detailing the type of document exchanged, reference number, sender &
receiver identity may along with the IDs of notified parties.
The following are the list of parameters that will be passed in the payload Header of
request:
Parameter Description
Doc Type PCCHC01
( VARCHAR2 (14) )
Comm Number assigned to the Payload request by sender
Ref. No. ( NUMBER (35) )

Sender ID ICEGATE ID Terminal Operator Code


( VARCHAR2 (10) )
Receiver Port Code of particular place
ID ( VARCHAR2 (10) )
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all)
( VARCHAR2 (10) )

6.1.4.1 Attributes Details – Request Payload

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
Requestor ID VARCHAR2(35) M ICEGATE ID of the Requestor

Voyage Call VARCHAR2(35) M Unique number assigned by


Number Operator for a Voyage

Format: Location Code (6


chars) + Year (4 digits) + 4
digits running serial no.

e.g: INBOM1+2019+0001

14
CBIC - Port Message Integration Specification Document

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
(INBOM120190001)

ACK-ID VARCHAR2 M Generated at Custom end for


(28) every transaction, post
successful schema validation

6.1.4.2 Response Payload

Below table depicts the proposed URL, content type, payload while sending API
response:
API response endpoint URL URL defined by ICEGATE

Method
POST

Content Type Application/JSON

URL Description

http/https All API will be published in production


over HTTPS only. HTTP protocol will be
used in non-production environments.

Response Data
Synchronous Response parameters for this API shall be sent with POST/GET. This data
will be Base64 encoded JSON payload, digitally signed by communicating
stakeholders/partners. The browser URL payload shall have the following parameters:
Parameter Description
Response Data generated as per defined response schema at receiver end. This
Payload Data data will be digitally signed then encrypted and encoded as per the
SOP approach.

15
CBIC - Port Message Integration Specification Document

Attribute Details
Attribute Data Type Mandatory Description
Name with Size / /Remarks
Optional
Status VARCHAR2(15) M ACK Status
post
consumption
of Payload
Error VARCHAR2(6) M 000 for success, else
Code error code along
with error
appropriate brief
will be provided.

Message VARCHAR2(25) M ACK Msg -


Data
Integrated
NAK Msg -
Data not
Integrated
Common VARCHAR2(25) M Common
Referenc Reference
e Number Number of
request
cluster

Requesto VARCHAR2(35) M ICEGATE ID


r ID of the
Requestor

ACK-ID VARCHAR2 M Generated


(28) at Custom
end for
every
transaction,
post
successful
schema
validation

Manifest VARCHAR2 O Initially


Number/ Manifest

16
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
Rotation (15) Number will
Number be Optional
in VCN. It
may be
Mandatory
in future, if
required.

Manifest DATE O Date of


Date/Rot generation
ation of Manifest
Date Number

ACK Response

{
"status": "success",
"errorCode": "000",
"CommonRefNumber": "2019031955489454",
"Message”: "Data Integrated",
”Requestor ID”: ”JNPT”,
”ackId”: ”xyz”,
”manifestNumber/rotationNumber”: ”123456789”,
”manifestDate/rotationDate”: ”19/05/2019”
}

NAK Response

{
"status": "failure",
"errorCode": "109",
"CommonRefNumber": "2019031955489454",
"Message”: "Data not Integrated",
”Requestor ID”: ”JNPT”
”ackId”: ”xyz”
”manifestNumber/rotationNumber”: ”123456789”
”manifestDate/rotationDate”: ”19/05/2019”
}

17
CBIC - Port Message Integration Specification Document

Table A: Code List for Type-of-Transport-Means

Code Value
10 IMO ship identification number
11 Sea Going Vessel, not requiring IMO
Registration
20 Wagon number
30 Registration number of the road vehicle
40 IATA flight number
41 Registration number of the aircraft

Table B: Purpose-of-Call Values

Code Description
1 Cargo operations
2 Passenger movement
3 Taking bunkers
4 Changing crew
5 Goodwill visit
6 Taking supplies
7 Repair
8 Laid-up
9 Awaiting orders
10 Miscellaneous
11 Crew movement
12 Cruise, leisure and recreation
13 Under government order
14 Quarantine inspection
15 Refuge
16 Unloading cargo
17 Loading cargo
18 Repair in dry dock
19 Repair in wet dock
20 Cargo tank cleaning
21 Means of transport customs clearance
22 Degassing
23 Waste disposal

18
CBIC - Port Message Integration Specification Document

6.1.5 Error Code with Description

Message Error Fla


ID Cd Error Description g
PCCHC01 001 Entity Type is null or Invalid F
PCCHC01 002 Message type is not in F or C F
PCCHC01 003 Voyage Call no is null F
PCCHC01 004 Mode of Transport is null or Invalid F
PCCHC01 005 Types of Transport mean is null or Invalid F
PCCHC01 006 Transport Mean identity is null or Invalid F
PCCHC01 007 Invalid vessel code F
PCCHC01 008 voyage no is null or Invalid F
PCCHC01 009 Shipping agent code is invalid F
PCCHC01 010 MLO Code is null or invalid F
PCCHC01 011 TO code is null or Invalid F
PCCHC01 012 Port Code is null or Invalid F
PCCHC01 013 EDTA is null F
PCCHC01 014 Voyage Allotment date is null F
PCCHC01 015 Purpose of call is null or Invalid F

6.2 ATE – Actual Time Event - API Reporting actual Arrival / Departure Time

This API will be invoked by Port, after Arrival of Vessel at Port of Origin. Port Terminal
Operator will share this information with Port and Port push the details to Custom post
approval of competent authority.
Events are:
1. AT – Arrival
2. AD - Departure

6.2.1 API Overview

CBIC exposed POST API to receive ATA details with the Port application on real time basis.
Port application will invoke this API when they are ready to push the details at Custom end. As a
response, ACK / NAK will be sent back to Port.

19
CBIC - Port Message Integration Specification Document

6.2.2 POST API Format – To post Arrival/Departure Details to Customs

Payload header includes the information that is being exchanged such as the type of
document exchanged, reference number, sender & receiver identity may along with the
IDs of parties need to be notified.
The following are the list of parameters that will be passed in the payload Header of request:
Parameter Description
Doc Type TOCHI02
( VARCHAR2 (14) )
Comm Number assigned to the Payload request by sender
Ref. No. ( NUMBER (35) )

Sender ID ICEGATE ID of Terminal Operator Code


( VARCHAR2 (10) )
Receiver Port Code of particular place
ID ( VARCHAR2 (10) )

20
CBIC - Port Message Integration Specification Document

Parameter Description
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all)
( VARCHAR2 (10) )

6.2.2.1 Attributes Details – Request Payload

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
Requestor ID VARCHAR2(35) M ICEGATE ID of the
Requestor
Record CHAR (1) M Record/Message
Type/Messag type may be one of
e Type the following:
FRESH - F
Cancel – C
Port Code CHAR (6) M Port Code of
Reporting

Voyage Call VARCHAR2(35) M Unique number


Number assigned by
Operator for a
Voyage

Format: Location
Code (6 chars) +
Year (4 digits) + 4
digits running
serial no.

e.g:
INBOM1+2019+00
01
(INBOM12019000
1)

Terminal CHAR (10) M TO Code


Operator
Code

Reporting CHAR (4) M PLB/ATA/DEP


Event

21
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
(PLB – Pilot
Boarded on Arrival,

ARR – All Arrival


Time till Cast off,

DEP – All
Departure Time till
reported by
Harbour Master

Type of VARCHAR2(2) M The type of


Transport identifier of the
Means means of transport
used in crossing
the
border/Movement
, coded.

Values: Refer
below Code List
Table – A

Identity of VARCHAR2(25) M Unique identifier


the for ships /
Transport registered ship
Means management
companies. Values
will be:
IMO/IATA/Lloyd

This would
normally be 7 digit
IMO Number for
vessel movement

Berth VARCHAR2 (6) M Number allocated


Number on berthing of
vessel

(needed in case of
Departure only)

22
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
Manifest VARCHAR2(15) O The Unique ID
Number/Rot generated by
ation Customs for filed
Number Manifest

Manifest Date O Date of generation


Date/Rotatio of Manifest
n Date Number

AR of VARCHAR2 M Authorized
Terminal (17) Representative of
Operator Terminal Operator.
(PAN) (PAN of AR)

Arrival / TIMESTAMP M Pilot-Boarded /


Departure (YYYY-MM-DD Complete-
Time HH:MM:SS) Departure Time-
reported by Stamp after
TO Arrival / Departure
at / from, Port of
Call, reported by
Terminal Operator

(Note - Departure
done by harbor
master, not by Port
Operators)

Final/ ARRAY O Array of all amends


Amends [EVENT_CODE, timestamps (final
Arrival / TIMESTAMP] timestamp).
Departure
Time (other Would be
Timestamp) incorporated as 2nd
Trigger

1st Trigger – will be


Arrival / Departure
time, which is
Mandatory as in
above row

Values would be
like:

1. Time of

23
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
Berthing
2. Anchoring
Time
3. Sailing
Time
4. Time of
Un-
Berthing
5. Arrival
Time

6.2.2.2 Response Payload

Below table depicts the proposed URL, content type, payload while sending API response:
API response endpoint URL URL defined by ICEGATE

Method POST
Content Type Application/JSON
URL Description
http/https All API will be published in production
over HTTPS only. HTTP protocol will be
used in non-production environments.

Response Data
Synchronous Response parameters for this API shall be sent with POST. This data will be Base64
encoded JSON payload, digitally signed by communicating stakeholders/partners. The browser
URL payload shall have the following parameters:

Attribute Details
Attribute Data Type Mandatory Description
Name with Size / /Remarks
Optional
Requesto VARCHAR2(35) M ICEGATE ID

24
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
r ID of the
Requestor
Common VARCHAR2(25) M Common
Reference Reference
Number Number of
request
cluster
ACK-ID VARCHAR2 M Generated
(28) at Custom
end for
every
transaction,
post
successful
schema
validation
REQUEST VARCHAR2(6) M 000 for success, else
STATUS error code along
with error
appropriate brief
will be provided.
STATUS VARCHAR2(30) M ACK
DESCRIPT Message -
ION Data
successfully
inserted into
database
NAK
Message –
Data
insertion has
been failed

Synchronous Response from Customs

ACK Response

{
"status": "success",
"errorCode": "000",
"CommonRefNumber": "2019031955489454",

25
CBIC - Port Message Integration Specification Document

"Message”: "Request Processed",


”Requestor ID”: ”JNPT”,
”ackId”: ”1234567890123456”,
}

NAK Response

{
"status": "failure",
"errorCode": "SCERR01",
"comRefNum": "2019062649815390",
"message": "Schema Validation Failed due to bellow Error:\r\n\r\nerror: object has
missing required properties ([\"icegatePayload\"])\n level: \"error\"\n schema:
{\"loadingURI\":\"#\",\"pointer\":\"\"}\n instance: {\"pointer\":\"\"}\n
domain: \"validation\"\n keyword: \"required\"\n required: [\"icegatePayload\"]\n
missing: [\"icegatePayload\"]\ninValid json file",
"requestorID": "JNPT",
"ackid": "1234567890123456",
}

6.2.3 POST API Format – Arrival/Departure Details Acknowledgment

Request Payload Header:


Payload header detailing the type of document exchanged, reference number, sender & receiver
identity may along with the IDs of notified parties.
The following are the list of parameters that will be passed in the payload Header of request:
Parameter Description
Doc Type TOCHI02 ACK/NACK
( VARCHAR2 (14) )
Comm Number assigned to the Payload request by sender
Ref. No. ( NUMBER (35) )

Sender ID ICEGATE ID Terminal Operator Code


( VARCHAR2 (10) )
Receiver Port Code of particular place
ID ( VARCHAR2 (10) )

26
CBIC - Port Message Integration Specification Document

Parameter Description
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all)
( VARCHAR2 (10) )

6.2.3.1 Attributes Details – Request Payload

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
Requestor ID VARCHAR2(35) M ICEGATE ID of the Requestor

Voyage Call VARCHAR2(35) M Unique number assigned by


Number Operator for a Voyage

Format: Location Code (6


chars) + Year (4 digits) + 4
digits running serial no.

e.g: INBOM1+2019+0001
(INBOM120190001)

ACK-ID VARCHAR2 M Generated at Custom end for


(28) every transaction, post
successful schema validation

6.2.3.2 Attributes Details – Response Payload

Response Data
Synchronous Response parameters for this API shall be sent with POST/GET. This data will be
Base64 encoded JSON payload, digitally signed by communicating stakeholders/partners. The
browser URL payload shall have the following parameters:
Parameter Description
Response Data generated as per defined response schema at receiver end. This
Payload Data data will be digitally signed then encrypted and encoded as per the
SOP approach.

27
CBIC - Port Message Integration Specification Document

Parameter Description

Attribute Details
Attribute Data Type Mandatory Description
Name with Size / /Remarks
Optional
Status VARCHAR2(15) M ACK Status
post
consumption
of Payload
Error VARCHAR2(6) M 000 for success, else
Code error code along
with error
appropriate brief
will be provided.

Message VARCHAR2(25) M ACK Msg -


Data
Integrated
NAK Msg -
Data not
Integrated
Common VARCHAR2(25) M Common
Referenc Reference
e Number Number of
request
cluster

Requesto VARCHAR2(35) M ICEGATE ID


r ID of the
Requestor

ACK-ID VARCHAR2 M Generated


(28) at Custom
end for
every
transaction,
post
successful
schema
validation

28
CBIC - Port Message Integration Specification Document

ACK Response

{
"status": "success",
"errorCode": "000",
"CommonRefNumber": "2019031955489454",
"Message”: "Data Integrated",
”Requestor ID”: ”JNPT”,
”ackId”: ”xyz”,
}
NAK Response

{
"status": "failure",
"errorCode": "109",
"CommonRefNumber": "2019031955489454",
"Message”: "Data not Integrated",
”Requestor ID”: ”JNPT”
”ackId”: ”xyz”
}

6.2.4 Arrival Time JSON Schema and Sample

6.2.6 Error Code With Description

Message Error Fla


ID code Error Description g
PCCHC02 001 Entity Type is null or Invalid F
PCCHC02 002 Message type is not in F/C/S/D F
PCCHC02 003 Port Name is null or Invalid F
PCCHC02 004 Voyage Call No is null or Invalid F
PCCHC02 005 Identity of Transport mean is null or Invalid F
PCCHC02 006 Type of Transport means is null or Invalid F
PCCHC02 007 Rotn No/ Date is null or Invalid F
PCCHC02 008 AR of Terminal Operator (PAN) is null F
PCCHC02 009 Event Code not in PLB/ATA/DEP or null F
PCCHC02 010 Terminal Operator Code is null or Invalid F
PCCHC02 011 Reporting Event is null F

29
CBIC - Port Message Integration Specification Document

6.3 ELR API - API Reporting Equipment Landed / Loaded Report

This API will be invoked by Ports, after Arrival of Vessel at Port of Origin. Port Terminal
Operator will share this information with Ports and Ports push the details to Custom
post approval of competent authority.

6.3.1 API Overview

CBIC exposed POST API to receive event timestamp details with the Ports application on
real time basis.
Ports application will invoke this API when they are ready to push the details at Custom
end. As a response, ACK / NAK will be sent back to Ports.

6.3.2 POST API Format – To post Equipment Landed/Loaded Data to Customs

Payload header includes the information that is being exchanged such as the type of document
exchanged, reference number, sender & receiver identity may along with the IDs of parties need
to be notified.
The following are the list of parameters that will be passed in the payload Header of request:
Parameter Description
Doc Type TOCHI03
( VARCHAR2 (14) )

30
CBIC - Port Message Integration Specification Document

Parameter Description
Comm Number assigned to the Payload request by Ports/
Ref. No. sender
(NUMBER (35) )

Sender ID ICEGATE ID of Terminal Operator Code


(VARCHAR2 (10) )
Receiver Port Code of particular place
ID (VARCHAR2 (10) )
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all )
( VARCHAR2 (10) )

6.3.2.1 Attributes Details – Request Payload

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
Requestor ID VARCHAR2(35) M ICEGATE ID of the
Requestor
Record Type CHAR (1) M Record/Message
type may be one of
the following:
Fresh - F
SUPPLEMENT - S
(This event will
provide the detail of
the subsequent
equipment
landed/loaded)
Cancel – C
Reconciliation – R
How it works:
The very first stock of
the equipment will
be captured as Fresh
(F), then subsequent
landing/loading of
the equipment will
be captured in

31
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
Supplement (S),
Cancel equipment’s
will be captured in
Cancel (C).
Reconciliation (R)
event must contain
all the equipment’s
details.
F+S-C=R
Port Code CHAR (6) M Port Code of
Reporting

Voyage Call VARCHAR2(35) M Unique number


Number assigned by Operator
for a Voyage

Format: Location
Code (6 chars) + Year
(4 digits) + 4 digits
running serial no.

e.g:
INBOM1+2019+0001
(INBOM120190001)

Identity of the VARCHAR2(25) M Unique identifier for


Transport ships / registered
Means ship management
companies. Values
will be:
IMO/IATA/Lloyd

This would normally


be 7 digit IMO
Number for vessel
movement

Total No. of NUMBER (5) M Total Number of


Containers transport
Landed / equipment’s
Loaded (TO) Loaded/Landed by
TO

32
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
Total No. of NUMBER (5) M The Count of
Transport Transport Equipment
Equipment reported on the
Reported in Arrival / Departure in
current current message
message

Landing / TIMESTAMP M The Actual Time of


Loading (YYYY-MM-DD Completion of
Complete HH:MM:SS) Loading / Landing of
Time by TO Cargo as reported by
Authorized Terminal
Operator

Manifest VARCHAR2(15) O The Unique ID


Number/Rota generated by
tion Number Customs for filed
Manifest

Manifest Date O Date of generation of


Date/Rotation Manifest Number
Date
FLAG VARCHAR2 (7) M Following will be the
values:
1. Equipment Landed
2. Equipment Loaded
Equipment ARRAY M List of equipment
Details [EQUIPMENT with their details
TYPE,
EQUIPMENT
NUMBER,
EQUIPMENT
SEQUENCE
NO,
EQUIPMENT
DAMAGE
INDICATOR,
DESCRIPTION
OF DAMAGE
EQUIPMENT,
CONTAINER
WEIGHT
(VGM),
EQUIPMENT
SEAL TYPE,

33
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory/ Description


Name with Size /Remarks
Optional
DIMENSION
CODE, OVER
DIM LENGTH,
OVER DIM
WIDTH, OVER
DIM HEIGHT]

Details of the attributes in ‘Equipment Details’ array:

Equipment Type VARCHAR2 (3) M The Code


specifying the type
of the Equipment
used for Transport.

EDIFACT 8053:
BB-Breakbulk,
BL- Blocks
CH – Chassis,
CN - Container,
OBE -
Onboard
Container,
TE - Trailer

EQUIPMENT VARCHAR2(30) M Equipment


NUMBER Number/Container
Number
Equipment NUMBER (5) M The Serial number
sequence no of
Equipment/Contai
ner

Equipment CHAR (3) O


damage indicator
Description of VARCHAR2 O
Damage (250)
Equipment
Container Weight NUMBER (14, M The Verified Gross
(VGM) 2) Mass (VGM) is the
weight of the cargo
including dunnage
and bracing plus
the tare weight of

34
CBIC - Port Message Integration Specification Document

the container
carrying this cargo.

Equipment Seal VARCHAR2 (5) M The Type of Seal


Type used for affixing to
a Transport
Equipment

1- In Right
condition,
2- Damaged

Dimension Code CHAR (3) O Dimension Code


( in case of over
dimension
container only)
*(6145)

Over Dim Length NUMBER (8,2) O Over Dimension


Length
Over Dim Width NUMBER (8,2) O Over Dimension
Width
Over Dim Height NUMBER (8,2) O Over Dimension
Height

Synchronous Response from Customs

ACK Response

{
"status": "success",
"errorCode": "000",
"CommonRefNumber": "2019031955489454",
"Message”: "Request Processed",
”Requestor ID”: ”JNPT”,
”ackId”: ”1234567890123456”,
}

NAK Response

{
"status": "failure",
"errorCode": "SCERR01",
"comRefNum": "2019062649815390",

35
CBIC - Port Message Integration Specification Document

"message": "Schema Validation Failed due to bellow Error:\r\n\r\nerror: object has


missing required properties ([\"icegatePayload\"])\n level: \"error\"\n schema:
{\"loadingURI\":\"#\",\"pointer\":\"\"}\n instance: {\"pointer\":\"\"}\n
domain: \"validation\"\n keyword: \"required\"\n required: [\"icegatePayload\"]\n
missing: [\"icegatePayload\"]\ninValid json file",
"requestorid": "Port ICEGATEID",
"ackid": "1234567890123456"
}

6.3.3 POST API Format – Equipment Landed/Loaded Details Acknowledgment

Request Payload Header:


Payload header detailing the type of document exchanged, reference number, sender & receiver
identity may along with the IDs of notified parties.
The following are the list of parameters that will be passed in the payload Header of request:
Parameter Description
Doc Type TOCHI02 ACK/NACK
( VARCHAR2 (14) )
Comm Number assigned to the Payload request by sender
Ref. No. ( NUMBER (35) )

Sender ID ICEGATE ID Terminal Operator Code


( VARCHAR2 (10) )
Receiver Port Code of particular place
ID ( VARCHAR2 (10) )
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all )
( VARCHAR2 (10) )

6.3.3.1 Attributes Details – Request Payload

36
CBIC - Port Message Integration Specification Document

Attribute Name Data Type & Manda Description /Remarks


Length tory/
Option
al
Requestor ID VARCHAR2(35) M ICEGATE ID of the Requestor

Voyage Call VARCHAR2(35) M Unique number assigned by


Number Operator for a Voyage

Format: Location Code (6


chars) + Year (4 digits) + 4
digits running serial no.

e.g: INBOM1+2019+0001
(INBOM120190001)

ACK-ID VARCHAR2 M Generated at Custom end for


(28) every transaction, post
successful schema validation

6.3.3.2 Attributes Details – Response Payload

Response Data
Synchronous Response parameters for this API shall be sent with POST. This data will be Base64
encoded JSON payload, digitally signed by communicating stakeholders/partners. The browser
URL payload shall have the following parameters:
Parameter Description
Response Data generated as per defined response schema at receiver end. This
Payload Data data will be digitally signed then encrypted and encoded as per the
SOP approach.

Attribute Details

37
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
Status VARCHAR2(15) M ACK Status
post
consumption
of Payload
Error VARCHAR2(6) M 000 for success, else
Code error code along
with error
appropriate brief
will be provided.

Message VARCHAR2(25) M ACK Msg -


Data
Integrated
NAK Msg -
Data not
Integrated
Common VARCHAR2(25) M Common
Referenc Reference
e Number Number of
request
cluster

Requesto VARCHAR2(35) M ICEGATE ID


r ID of the
Requestor

ACK-ID VARCHAR2 M Generated


(28) at Custom
end for
every
transaction,
post
successful
schema
validation

ACK Response

{
"status": "success",

38
CBIC - Port Message Integration Specification Document

"errorCode": "000",
"CommonRefNumber": "2019031955489454",
"Message”: "Data Integrated",
”Requestor ID”: ”JNPT”,
”ackId”: ”xyz”,
}
NAK Response

{
"status": "failure",
"errorCode": "109",
"CommonRefNumber": "2019031955489454",
"Message”: "Data not Integrated",
”Requestor ID”: ”JNPT”
”ackId”: ”xyz”
}

6.3.4 Equipment Landed JSON Schema and Sample

6.3.6 Error Code With Description

Message Error Fla


ID code Error Description g
PCCHC03 001 Type of Transport means not in 1/2/3/4 F
PCCHC03 002 Message type is not in F/C F
PCCHC03 003 Port Name is null or Invalid F
PCCHC03 004 Voyage Call No is null or Invalid F
PCCHC03 005 Identity of Transprot mean is null or Invalid F
PCCHC03 006 Total No of containers Landed/Loaded is null F
PCCHC03 007 Total No. of Transport Equipment Reported is null F
PCCHC03 008 Landing / Loading Complete Time is null F
PCCHC03 009 Equipment Flag not in 1 or 2 F
PCCHC03 010 Rotn No or Rotn Date is null F
PCCHC03 011 Equipment Type not in BB/BL/CH/CN/OBE/TE F
PCCHC03 012 Equipment no is null F
PCCHC03 013 Equipment sequence no is null F
PCCHC03 014 Container Weight is null F
PCCHC03 015 Equipment Seal Type not in 1 or 2 F
PCCHC03 016 Rotn No or Rotn Date is null F

39
CBIC - Port Message Integration Specification Document

6.4 CCM API – API Reporting Custom Control Message (EI, EO, PC, CH)

Two POST APIs shall be developed for this message:

POST API Usage: These APIs shall be developed & exposed by ICEGATE and Ports will consume the
same.

1. The First POST API shall be used to POST details like Count of Records, Rotation Number,
Rotation Date, VCN, Custom Control Timestamp, Flag and array of records as synchronous reply
of messages left to be post.. The count of records in the will represent the number of messages
to be pulled.
2. The Second POST API will be used to seek the status of individual Control Flags based on the
required parameter to post the actual payload from ICEGATE.
3. In response to the request, messages regarding Entry Inward/Control Granted/not Granted
message will share with requester.

6.4.1 API Overview

This API will be invoked by the Ports, to obtain Entry Inward Grant / Entry Outward Grant / Port
Clearance / Container Hold Grant permissions from Custom. Custom facilitate the request after
validating Manifest and ATA details filed by them.

The possible events for this API are:


1. Entry Inward Grant (EI)
2. Entry Outward Grant (EO)
3. Port Clearance Grant (PC)
4. Container Hold (CH) (Not Included in the Current Development)

Custom provides Grant details, whenever Custom is ready with such details post vetting Sender-
Request.

40
CBIC - Port Message Integration Specification Document

6.4.2 API Format

Payload header includes the information that is being exchanged such as the type of document
exchanged, reference number, sender & receiver identity may along with the IDs of parties need
to be notified.
The following are the list of parameters that will be passed in the payload Header of request:
Parameter Description
Doc Type CHTOI04
( VARCHAR2 (14) )
Comm Number assigned to the Payload request by Ports /
Ref. No. sender
( NUMBER (35) )

Sender ID ICEGATE ID of the Terminal Operator Code


( VARCHAR2 (10) )
Receiver Port Code of particular place
ID ( VARCHAR2 (10) )
Sender-ID- Icegate-ID of stakeholders would be like
Qualifier Port/TO/ZZ_DSC etc.
( ZZ - for all )
( VARCHAR2 (10) )

6.4.3 First POST API

The first POST API will take the count of the messages to be post by ICEGATE.

6.4.3.1 Attributes Details – Request Payload

41
CBIC - Port Message Integration Specification Document

Attribute Data Type with Mandatory/ Description


Name Size /Remarks
Optional
Requestor ID VARCHAR2 (35) M ICEGATE ID of the
Requestor
Sender ID VARCHAR2 (10) O Port Code of
particular place
Receiver ID VARCHAR2 (10) O Terminal Operator
Code
Sender ID VARCHAR2 (10) M ZZ_DSC (ZZ - for
Qualifier all )

Response Data
Synchronous Response parameters for this API shall be sent with POST. This data will be Base64
encoded JSON payload, digitally signed by communicating stakeholders/partners. The browser
URL payload shall have the following parameters:

6.4.3.2 Attributes Details – Response Payload

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
Requesto VARCHAR2(10) M ICEGATE ID
r ID of the
Requestor
Count of NUMBER(4) M Number of
Records Records in
an array

Records ARRAY[] O Records as


Array array would
be available.
If count is
zero, the
records
would be
nill.
Receiver VARCHAR2 M The Code of
ID (10) the Receiver

42
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
ID ( Terminal
Operator
Code or
Custodian
Code)
FLAG VARCHAR2(2) M Following
will be the
event
values:
1. EO -
Entr
y
Out
ward
2. EI -
Entr
y
Inwa
rd
3. PC-
Port
Clea
ranc
e

4. CH –
Container
Hold

MANIFES [VARCHAR2(15 O The Unique


T_NO/ ) ID generated
ROTATIO by Customs
N NO for filed
Manifest
MANIFES Date O Date of
T_DT/ generation
ROTATIO of Manifest
N DT Number
Voyage VARCHAR2(35) O Unique number
Call assigned by
Number Operator for a
Voyage

43
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
Format:
Location
Code (6
chars) + Year
(4 digits) + 4
digits
running
serial no.

e.g:
INBOM1+2019+000
1
(INBOM120190001)

Customs Timestamp O The


Control Timestamp
Timestam of exercise
p of customs
Control

EQUIPME VARCHAR2(30) O Equipment


NT Number/Con
NUMBER tainer
Number

EQUIPME VARCHAR2(10) O The Type of


NT TYPE Equipment

EQUIPME VARCHAR2(10) O The Status of


NT the
STATUS Equipment

1.HOLD

2. RELEASE

6.4.4 Second POST API

This API will be invoked by Ports to get the actual payload against the Rotation Number and Rotation
Date received in first POST API
6.4.4.1 Attributes Details – Request Payload

44
CBIC - Port Message Integration Specification Document

Attribute Data Type with Mandatory/ Description


Name Size /Remarks
Optional
Requestor VARCHAR2 (35) M ICEGATE ID of the
ID Requestor
RECEIVER VARCHAR2 (10) O Terminal Operator
ID Code
RECEIVER VARCHAR2(2) O Receiver ID
ID qualifier
QUALIFIER
FLAG VARCHAR2(2) M Following will be
the event values:
4. EO - Entry
Outward
5. EI - Entry
Inward
6. PC- Port
Clearance
CH – Container
Hold
MANIFEST VARCHAR2(15) O The Unique ID
_NO/ generated by
ROTATION Customs for filed
_NO Manifest

MANIFEST Date O Date of


_DT/ generation of
ROTATION Manifest Number
DT

EQUIPME VARCHAR2(30) O Equipment


NT Number/Containe
NUMBER r Number

Voyage VARCHAR2(35) O Unique number


Call assigned by
Number Operator for a
Voyage
Format: Location
Code (6 chars) +
Year (4 digits) + 4
digits running
serial no.

e.g:
INBOM1+2019
+0001

45
CBIC - Port Message Integration Specification Document

Attribute Data Type with Mandatory/ Description


Name Size /Remarks
Optional

(INBOM120190
001)

Response Data
Synchronous Response parameters for this API shall be sent with POST. This data will be Base64
encoded JSON payload, digitally signed by communicating stakeholders/partners. The browser
URL payload shall have the following parameters:
Parameter Description
Bearer/Access- Sender will obtain this parameter post successful validation at CBIC
Token/Client- external API Gateway with Client-Id and Password.
ID

Response Data generated as per defined response schema at receiver end. This
Payload Data data will be encoded, digitally signed and encrypted as per the SOP
approach.
Response Sample JSON and Schema have listed for each API.

6.4.4.2 Attributes Details – Response Payload

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
Requesto VARCHAR2(35) M ICEGATE ID
r ID of the
Requestor
ACKNOW VARCHAR2 M Generated
LEDGME (28) at Custom
NT end. This
NUMBER acknowledg
ment
number will
be mapped
to each
message

Custom- VARCHAR2 (3) M Values will


Control- be:
Type

46
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
1. EI
2. EO
3. PC
4. CH

Custom- EVENT_VALUE M Values will


Control- S be:
Response
1. EI_G
rant
2. EO_
Gran
t
3. PC_
Gran
t
4. CH_
Gran
t

Voyage VARCHAR2 C Unique


Call (35) number
Number assigned by
Operator for
a Voyage

Format:
Location
Code (6
chars) + Year
(4 digits) + 4
digits
running
serial no.

e.g:
INBOM1+20
19+0001
(INBOM120
190001)

MANIFES VARCHAR2(15) O The Unique


T_NO/ ID generated
ROTATIO by Customs
N_NO for filed

47
CBIC - Port Message Integration Specification Document

Attribute Data Type Mandatory Description


Name with Size / /Remarks
Optional
Manifest

MANIFES Date O Date of


T_DT/ generation
ROTATIO of Manifest
N_DT Number

Custom- ARRAY O Furnished


Control- [STATUS_COD Equipment’s
Equipmen E, details:
t EQUIPMENT_T
YPE, - Status
EQUIPMENT_ Code
NO] ( VARCHAR2
(10) )

- Type of
Equipment
( VARCHAR2
(10) )

- Equipment
Unique
Number
( VARCHAR2
(10) )

6.4.5 CCM API – API Reporting Customs Control Message (EI,EO,PC)) – Schema & Sample files

48

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy