What is GS1 EPCIS 2.0? An in-depth guide

GS1 EPCIS (Electronic Product Code Information Services) is an open standard designed to facilitate the seamless capture and sharing of supply chain event data across organizations. EPCIS enables businesses to track the journey of goods and products by recording critical events - such as production, shipping, and receipt - throughout the supply chain. By standardizing how data is structured and communicated, EPCIS helps organizations achieve greater visibility, traceability, and interoperability, supporting more efficient operations, regulatory compliance, and consumer transparency.

EPCIS 2.0 - the latest version of the standard - does this by giving us two important elements:

1. A consistent, standard data model to represent supply chain activity in an electronic, machine-readable format
2. A set of standard APIs that allow EPCIS systems to exchange this data with no additional system integration costs

In this in-depth technical guide, you will discover:

1. What is meant by a “supply chain event”
2. The anatomy of real EPCIS events
3. How EPCIS events can be exchanged seamlessly between businesses using standard APIs without custom system integration costs
4. How EPCIS events are used to record real world supply chain processes

What is an event in EPCIS?

In the context of EPCIS, an "event" refers to a specific occurrence that provides meaningful information about the movement, status, or transformation of a product or asset within the supply chain. An event consists of information about “what”, “where”, “when” and “why”:

• What object(s) did the event involve?
• When did the event occur?
• Where did the event occur?
• Why did the event occur?

By recording events, we are able to accurately represent any supply chain process or activity that occurs as data. Consider a typical supply chain process like the one below:

Each discrete step in the process can be recorded with an EPCIS event:

1. During manufacturing we record “commissioning” events (“why”) that tell us the identifiers of the exact items (“what”) that were manufactured, the exact timestamp (“when”), and the location “where” the event occurred
2. During case packing we record “packing” events (“why”) that tell us that specific items were packed into parent cases (“what”) at a specific timestamp (“when”) at a particular location (“where”)
3. During pallet packing we record “packing” events (“why”) that tell us that specific cases were packed into parent pallets (“what”) at a specific timestamp (“when”) at a particular location (“where”)
4. During shipping we record “shipping” events (“why”) that tell us that specific pallets were shipped at a specific timestamp (“when”) at a particular location (“where”)
5. During receiving we record “receiving” events (“why”) that tell us that specific pallets were received at a specific timestamp (“when”) at a particular location (“where”)

Any supply chain process you can think of can be modelled and recorded using EPCIS events. For example, if you wanted to record the installation of components into an asset, you could record an “installing” event using EPCIS:

Or if you wanted to record the exact input ingredient batches that contributed to a batch of output products, you can using a “transformation event”:

Diving deeper: the anatomy of an EPCIS event

So what does an EPCIS event actually look like under the covers? Let’s use a very simple scenario as our example - the receipt of a pallet at a warehouse:

What we want to record is simple: that we observed a pallet as part of a warehouse receiving process (the “why”), uniquely identified by the SSCC 277776661000000203 (the “what”), at a particular moment in time (the “when”), at location identified by the Global Location Number [GLN] 4444999400018 (the “where”).

If we were to show this conceptually, it looks like this:

But let’s take it one step further and look at a real EPCIS event represented as a JavaScript Object Notation (JSON) message. JSON is a text-based format for storing and exchanging data that's both human-readable and machine-parsable. It is heavily used by developers creating the Internet, and is fully supported by the latest version of EPCIS.

This is a very simple, valid EPCIS event. Let’s go through the data fields related to each dimension:

• What: The field epcList allows us to specify a set of GS1 identifiers that this event applies to. Here we have used a GS1 Digital Link (click here to learn more about Digital Link) to specify that the event has occurred to a single logistic unit with an SSCC code of “277776661000000203”. If multiple pallets were received as part of this supply chain operation, we could have added more identifiers to this list. Note that identifiers can be expressed either as Digital Links or in a format known as a “Pure Identity URI” which is commonly used in RFID projects. The GS1 Tag Data Standard explains each format and how to convert between
• When: The field eventTime stores the exact date and time the event occurred, in Universal Coordinated Time (UTC). The field eventTimeZoneOffset allows us to specify the local timezone the event was captured in
• Where: The field bizLocation refers to a single GS1 identifier corresponding to the location where the objects can be physically assumed to be following the event. In this example, we have received the pallet at a warehouse identified by the GS1 Global Location Number “4444999400018”, expressed here in Digital Link syntax. Sub-locations are also supported (e.g. a specific loading dock, store-room, field or production line within a business address). Note that you may also have a field called readPoint that represents the location dimension - this corresponds to the exact location where the object was interacted with, but may subtly differ from bizLocation in scenarios where an object is scanned in one location but then placed in another location; for example, an RFID-equipped doorway could be the readPoint, but the store-room beyond is the bizLocation.
• Why: The most important field for expressing the “why” dimension is bizStep, which contains the code of the supply chain process that was being executed when this event was captured (in this example, “receiving”). The value in this field comes from a list of possible values defined inside a companion standard to EPCIS called the GS1 Core Business Vocabulary (CBV) - we’ll explain this more in the next section. Another interesting field that also contains a value from the CBV is disposition, which tells us what state the object is in directly after this event. In this example, the value “sellable_not_accessible” tells us the object is in a sellable state but not accessible by customers. The field called action can be one of three values “ADD”, “DELETE” or “OBSERVE”, and represents whether we are adding, deleting or just observing objects. In this example we are just recording that we’ve seen an object, so we use OBSERVE. We’ll explain the type field in just a few moments, but first…

What is the GS1 Core Business Vocabulary?

The GS1 Core Business Vocabulary (CBV) is a standardized set of terms and definitions used within the EPCIS framework to ensure consistent communication and interpretation of supply chain events across different organizations and systems. It provides an agreed-upon language for describing business processes, including key terms related to business steps, disposition codes, and more. By establishing uniform terminology, the CBV helps ensure that data recorded and shared through EPCIS is understood in the same way by all parties, reducing ambiguity and enhancing interoperability.

In the previous section, we learnt about two special fields in the “Why” dimension called bizStep and disposition. Starting with bizStep, if we open up the standard and navigate to section 7.1.3, we can see a full list of all the business step codes and definitions - about 41 in total. Here is a screenshot of just a few of the values:

Similarly, the possible values of the field disposition, which is used to indicate the state of an object after an event, is defined in section 7.2.3:

By creating events that use business step and disposition codes, we can describe different business processes in a consistent, interoperable way.

The CBV defines many other code lists used in EPCIS, such as business transaction types, error codes, sensor measurement types and more. It also describes the format of other fields (such as identifiers) to ensure everyone expresses them in a consistent way. For example, section 8.4 describes the possible syntaxes that can be used in a location field (such as business location or read point), such as Digital Link, EPC URI, or proprietary schemes.

What does the “type” field mean in an EPCIS Event?

When a business user thinks about an “event type” in the supply chain, they would probably (and correctly!) think about packing, shipping, selling, and other business steps. As we saw before, this is already captured in the bizStep field. But in our previous example, we saw a field called “type”, with a value “ObjectEvent”:

What does this mean, and why do we need this? The field type refers to the EPCIS technical event type, which can either be “ObjectEvent”, “AggregationEvent”, “TransformationEvent”, “AssociationEvent” or “TransactionEvent”.

The main reason we need this is because the “what” fields - i.e. the subject(s) of an event, can vary depending on the supply chain scenario.

• If we are packing, or “aggregating”, we need to specify a parent and a list of children (that went inside the container), so the AggregationEvent schema provides special fields to allow this
• If we are installing components inside another object permanently, we also need to be able to specify a parent and children - the AssociationEvent schema allows this
• If we are transforming (consuming inputs to create outputs), we need to specify these inputs and outputs, so the TransformationEvent schema allows this
• Most other supply chain scenarios are covered by ObjectEvent, where a business scenario (e.g. shipping, receiving, selling, destroying etc) applies to one or more EPCs in a list
• TransactionEvent is a special event type intended to allow business transactions (e.g. purchase order, advance ship notice) to be associated with the specified EPCs

Because EPCIS defines a data schema, and we want to apply rules on that schema, a decision was made to define “sub-classes” of the main “EPCISEvent” data entity (a concept from “object oriented programming”), resulting in the five event types in the current version of the standard.

More Examples: Packing with AggregationEvent

So let’s take a look at another important scenario - how do we record the act of packing items into a container in EPCIS? Consider the business scenario below. We pack three sellable tomato cartons, identified uniquely with a combination of a GTIN and a Serial ID (SGTIN), into a pallet, identified by an SSCC:

In EPCIS packing is handled through the special event type called AggregationEvent. The easiest way to understand is by looking at an example:

 The fields for “When” and “Where” are the same as our previous example. The fields in “Why” have changed:

• The bizStep field is still present, but its value is “packing”, as defined by the CBV
• The technical EPCIS event type, indicated by the type field, has changed to AggregationEvent (instead of ObjectEvent). This allows the data schema for the “What” dimension to accommodate additional fields
• The action field is set to a value of ADD, used to signal that items are being packed into a parent object. If we were unpacking objects out of a parent, we would see a value of DELETE

The fields in the “What” dimension are also named subtly different, because this is an AggregationEvent.

• The parentID field tells us the identifier of the object being packed into. In this example, it is a pallet identifier with an SSCC of 277776661000000203. We use Digital Link syntax to express the identifier
• The childEPCs field lets us list the child objects being packed into the parent. In this case, we are packing three objects identified uniquely with a GTIN and Serial Number. Here we express this identifier as a Digital Link

More Examples: Packing Batch/Lots into Containers

What if we were doing batch/lot level traceability, such as the following example where a mixed pallet is being packed with 4 cartons of one batch and 6 cartons of another batch?

EPCIS events support batch level traceability too. Here is how the event changes:

Most fields are the same as our previous example. Inside the “What” dimension, epcList has been replaced with childQuantityList. Items inside this list allow us to specify a class of product in the epcClass field - in this case, a batch of tomatoes, expressed as a Digital Link - and a quantity. An optional field we omitted from our example, uom, allows us to specify a unit of measure, which would support scenarios such as packing a quantity of liquid into a bottle, or a weight of loose goods into a container.

More Examples: Unpacking

In our first packing example, what if we made a mistake and wanted to unpack the third carton? We can use an unpacking event, which looks like this:

The bizStep field is set to unpacking and the action field is now set to DELETE, indicating we are removing the children specified from the parent. Easy!

More Examples: Transformation

Let's look at one last important example. In traceability, we often want to track which input ingredients or materials were used to produce a particular output product. This means that if one of the ingredients is defective, we can trace all the output products that might be affected. Or if an output product is defective, we can understand all the inputs that might have caused the problem.

Lets take an example where 1 kilogram of a batch of salt and 10 liters of a batch of milk is being combined to produce a batch of 4 blocks of cheese:

Here is the above business process represented as an EPCIS Transformation event:

Let’s look at key differences to our previous examples:

• “Why”: The native EPCIS event type is set to “TransformationEvent”, which allows the schema to accommodate the special input/output lists that this scenario requires. The field bizStep is set to commissioning from the CBV to indicate new objects are being created/manufactured. Note that action is omitted, as a Transformation event always consumes inputs and creates new outputs.
• “What”: The field inputQuantityList allows us to provide a list of input ingredients and quantities that were consumed as part of manufacturing the batches specified in the outputQuantityList. Note the addition of another optional feature of EPCIS, the “ilmd” field, which stands for Instance/Lot Master Data. This is a set of extra attributes that the output product has - in this example, the output has an expiration date of 2024-04-10. The permissible values are defined in the GS1 CBV in section 9.2
• “When” is the same as in other events we’ve seen so far
• “Where” is also the same. However note here we show an example of a sub-location (such as a specific production line), by using a Digital Link identifier that contains a Global Location Number (signaled by the qualifier /414/) and a Global Location Number Extension (signaled by the qualifier /254/)

The EPCIS APIs: getting data in and out

Now that we’ve learned what EPCIS events look like, how do we get data into and out of an EPCIS system? The EPCIS 2.0 standard defines both a data model and a set of REST APIs for system to system data exchange. That means that two EPCIS compatible systems can be configured to exchange data with no integration middleware and no data transformation/mapping required, which means the cost of integration is reduced to practically nothing compared to connecting two systems that each have a proprietary, non-standard API.

Note that the standard also includes bindings for XML and other older options, but in this guide we’ll focus on the modern REST APIs with JSON data payloads.

Getting data in

If an application needs to push supply chain data into an EPCIS system, the primary way is to send a message containing a list of events into the special capture API. This is useful for business to business scenarios where traceability data needs to be sent to accompany a physical goods shipment:

The capture API is asynchronous, designed to be able to accept thousands of events at one time. A simpler /events API is also available that allows a single event to be pushed in, but we recommend using /capture. Section 12.6 of the EPCIS specification describes the endpoint:

Getting data out

EPCIS provides a query interface to allow an application to fetch specific events that match a search criteria.

In the REST API there are a number of query related endpoints that allow events to be fetched. The /queries interface allows a “standing query” to be defined which can be run over and over again.

Asking for events to be continually sent that match a criteria

The final set of APIs that EPCIS defines is a “subscription” mechanism, where one system can ask another system to continually send any events that arise that match a specific criteria. For example, “send me all events that occur at location ABC”. The accepting system will watch for new events that match that criteria and then send them automatically to the callback URL defined by the first system.

Using EPCIS in real life: Food Safety Modernization Act 204(d)

EPCIS is the perfect standard to apply in any scenario where businesses need to record and exchange traceability information. One such example is Section 204(d) of the Food Safety Modernization Act in the United States - entitled “Additional Recordkeeping Requirements for High Risk Foods” - which will require thousands of businesses in the USA to store and exchange lot-level traceability information if they produce, handle or process any food identified on the FDA’s Food Traceability List. The FDA has defined a series of Critical Tracking Events (CTEs), each containing Key Data Elements (KDEs), which they expect businesses to record. The FDA diagram below illustrates the CTEs and KDEs involved for a produce supply chain:

Note that not only do businesses need to record data, but they also need to send data to other parties in the supply chain, so those businesses can store accurate information too. For example, some harvesting and cooling KDEs need to be provided to the initial packer, and shipping CTE/KDEs always need to be forwarded to the receiver: 

EPCIS is the perfect data standard for both storing and sending the required data for this legislation. Consider the following snippet of a supply chain that covers a grower that harvests, cools, packs and ships produce to a food processor, who transforms the food and ships it onwards.

As we can see, each logical CTE defined by the FDA (in blue) can comfortably be recorded using the building blocks provided by the EPCIS standard that we’ve learnt about in this guide. If both parties were using an EPCIS compatible system, the farm could easily send the required data to the packed salad manufacturer using EPCIS APIs, with no additional system integration costs.

Conclusion

GS1 EPCIS 2.0 is an extremely powerful traceability data standard that provides both a data model and an API. It can help businesses record and exchange vital supply chain data that can meet legislative requirements, prove provenance, surface certifications, detect supply chain fraud, enable rapid and targeted product recalls, reduce waste and more. It can be applied to any supply chain, in any industry, with any product or asset - at item, batch or SKU level of granularity.

But because it is so powerful, it is also difficult to understand and leverage for new audiences. At TrackVision AI, we provide an easy to use traceability platform that has been built from the ground up on the GS1 EPCIS 2.0 standard. It includes a scalable EPCIS repository, full implementations of EPCIS APIs and data exchange frameworks, and comes packed with out-of-the-box analytics, workflow and AI features to help businesses meet their supply chain traceability requirements. Talk to us today for a free consultation on how your business could adopt and leverage the GS1 EPCIS 2.0 standard.