Code upload to existing workorder

Overview

This method enables you to add codes to an existing workorder. The workorder can be either a pre-print or post-print workorder. The uploaded codes will adopt the workorder's settings. The workorder must be created prior to the upload.

Supported code types:

• Serialized Identifiers (SID) codes (pre-print + post-print)
• Secure Codes (SSC) (pre-print + post-print)

Restrictions:

• A workorder must be created manually prior uploading
• The workorder download will not be re-generated (post-print)
• Printing Partner is not notified (post-print)

For more information about different upload methods, pre-print / post-print, please refer to the overview.

API Design

Upload codes to workorder

POST /api/v2/ingestion/codes/add-to-workorder/

Overview

Calling this endpoint will start the code upload (ingestion) process. The ingestion process is an async process which must be validated upon completion using the record key from the response.

Please refer to the Ingestion Record documentation to see how to retrieve ingestions and check status.

Field Description

Field	Type	Description
mode	string [api, file] (Optional)	Default = api, Defines the upload mode.
filetype	string [csv, json] (Optional)	Default = CSV, only applicable when mode = file
default_scm_data	json (Optional)	SCM data field including product/activation_status/blacklist_reason/… WOrks the same as the SCM upload endpoints. Data here will be used as the default for each code (overridden by what is in the code record)
codes	list - json (Optional*)	List of code records, may include SCM data / product etc and must include ‘id’
ingestion_key	string	Ingestion key found on existing pre_print/post_print workorders.
allow_posted_duplicates	bool (Optional)	Don’t error on duplicate check but ingest first entry and ignore next duplicates (within posted IDs)
id_format	string [gs1, default] (Optional)	Default=default. ID Format for upload

Validations

Some fields are validated directly upon the API call and others are validated during processing in the background.

Validated upon API call (400 BAD REQUEST - response, ingestion aborted)

• API mode
• • Code ID (must exist for every row), codes can not be empty
• • SCM data for codes must be valid
• • Duplicate checks in the codes field
• File Mode
• • Codes can not be passed directly
• All fields are separately checked for valid input

Validated during processing (200 OK, check status using record API):

• All code ID formats
• Duplicate checks within the system + file
• All SCM data / products / related objects / ...

Example payload

{
    "codes": [
        {
            "id": "c/01/abcde/22/dfge",
            "pallet_nr": "PA01"
        }
    ],
    "default_scm_data": {
        "activation_status": 1
    },
    "mode": "api",
    "ingestion_key": "wi-wv23833wgkrtgt7",
    "id_format": "gs1"
}

Example Response (mode API) 200 OK

{
    "record_key": "3k59jyrwznhp"
}

Example Response (mode S3) 200 OK

{
   "post_data": {
       "url": "https://st-media-dev.s3.amazonaws.com/",
       "fields": {
           "Content-Type": "text/csv",
           "key": "private/c/1/ingestion/code/p37bk370jurt.csv",
           "AWSAccessKeyId": "AKI...",
           "policy": "eyJ...",
           "signature": "yc..."
       }
   },
   "record_key": "p37bk370jurt"
}

Example Response invalid workorder 400 BAD REQUEST

{
    "ingestion_key": [
        "Invalid ingestion key."
    ]
}

Note: When using mode: file, the file must now be uploaded to the URL provided directly before calling /process-from-file/. Please refer to the file upload documentation for more information.

Next steps

1. When using mode = file, continue uploading the file and call /process-from-file/ as described in the file upload documentation
2. Check the ingestion status using the Ingestion Record API
3. Use your uploaded codes