Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Overview

Org Folders are simply there to help structure your projects.

Navigate to Folders > View Folder Tree to create and manage Org Folders.

It's possible to have an Org folder within an Org folder. You can do this by dragging and dropping your Org Folder to the location you want it to move to.

You can also have multiple Active Folders within Org Folders.

You cannot delete an Org Folder unless it is empty.

Creating Organisation Folders

Navigate to the Main Menu > Folders > View Folder Tree.

In the Add Root Folder panel, enter the Folder name and choose the Folder Type using the drop down list. Then click Add Folder.

Deleting an Organisation Folder

To delete an Org Folder, navigate to Main Menu > Folders > View Folder Tree. Then right click on the desired Folder and click 'Delete'. Org Folders need to be empty to be deleted.

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Overview

An Active Folder is required. You can have up to 10 Active Folders on the Flex Plan and 100 Active Folders on the Flex Pro Plan. Active Folders have important settings but are also used to manage structures.

Important Active Folder settings :

• Response Mode

• Extended Data Fields

• Data Merge Settings

Creating Active Folders

Navigate to the Main Menu > Folders > View Folder Tree.

In the Add Root Folder panel, enter the Folder name and choose the Folder Type using the drop down list. Then click Add Folder. Alternatively, you can right click on an Org Folder and click 'Add Active Folder'. This will place the new Active Folder within your Org Folder.

To rename an Active Folder, right click on the Folder and click 'Rename', enter the text and press enter. You can also rename an Active Folder from the Active Folder screen.

After an Active Folder has been created, you can add the Active Folder settings.

Moving Active Folders

To move an Active Folder, navigate to the Main Menu > Folders > View Folder Tree. From here you can drag and drop your Active Folder to an Org Folder. Active Folders cannot exist inside other Active Folders.

Deleting Active Folders

To delete an Active Folder, navigate to the Main Menu > Folders > View Folder Tree. Right click on the desired Folder and click 'Delete'.

Alternatively, you can navigate to the Main Menu > Folders > List Active Folders. Then click on the Active Folder you wish to delete. In the Folder Detail panel, click the Settings tab, select the Folder Status drop down list and select Delete, then Update.

Tag Codes

Ixkio is designed as a one-to-one platform so every NFC tag and therefore every single product the tags are attached to has it's own unique code - called a Tag Code.

Tag Codes are organised into Batches, which sit in Tag Groups, which are contained in Active Folders which can be optionally organised into Org Folders.

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes For example: 2022 > Summer Release > Shoes > Size > Tags

The system is designed in a way that allows you to keep growing and adding to your projects without having to recreate management rules or configurations.

Organisation Folders

• Org Folders are simply there to help you organise your project.

• They have no settings or features.

• Org Folders are optional, you don't need to use them.

Active Folders

• Active Folders define the Response Mode.

• You can move Active Folders between Org Folders.

• Active Folders cannot be inside another Active Folder.

• Extended Data fields are created at the Folder level.

• You must have at least one Active Folder.

Tag Groups

• Response Rules can be set for all Batches/Tag Codes at the Tag Group level.

• Tag Groups manage either Standard Tags (NTAG213, etc) or Authentication Tag (NTAG424, etc) - not both.

• You cannot move Tag Groups outside of an Active Folder.

• Extended Data (for example, product data such as colour, size, etc) is entered at the Tag Group level and will be inherited by all Batches and Tag Codes within the Group.

• You must have at least one Tag Group.

Batches

• Batches directly contain Tag Codes.

• Tag Data can be downloaded and uploaded at the Batch level.

• Tag encoding with the ixkio App is controlled at the Batch level.

• Assignment always moves a Tag Code from one Batch to another.

• You can move Batches between Tag Groups.

• Extended data (product data for example) can also be set at the Batch level overruling the Tag Group data and then being inherited by all the Tag Codes within the Batch.

• You must have at least one Batch.

Tag Codes (XUID)

• Tag Codes are unique URLs/links for encoding onto NFC Tags or QR Codes

• You can move Tag Codes between Batches under the same Active Folder.

• Extended data (product data for example) can also be set at the Tag Code level overruling any Batch or Tag Group level data.

• Rules can be created at a Tag Code level or are inherited from the Tag Group level.

Recommended Structure

If you are setting up a large structure, talk to us first. Alongside the hierarchy structure, there's also additional management tools such as Clusters which can be used to organise large numbers of tags. We can provide advise on the best way to set things up for scale.

Keep it simple

As a general rule, keep it simple. Most projects won't need Org Folders and many won't need more than one Active Folder. Many of the projects - even those with hundreds of thousands of Tag Codes - can be simply managed with multiple Tag Groups under a single Active Folder.

Use Batches

Batches contain are an important way to help manage projects. You can download stats, encode with the ixkio mobile app, move tags with Assignment and create associations all at the Batch level. We certainly recommend using Batches for each set of tags you release.

Ixkio is a full featured NFC tag management platform providing support for both regular NFC tags (NTAG213, ICODE) and authentication NFC tags (NTAG424).

Ixkio can dynamically display product and authentication data with three user Response Modes : API, Redirect and Direct.

Getting Started

These guides will help get you started but we recommend that if you are planning out a large tag structure, then speak to us first for advice.

Organising your tags / products

Working with your Response Mode

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Overview

There are two types of Folders :

Organisation Folders, which are only used to manage your Active Folders

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Overview

Batches are an important tool for managing large numbers of Tag Codes that will act in a similar way and will typically have the same Rules and settings.

For example, if you have a product that has a manufacturing run every few months, you can create a new Batch for each run. This will give you control and organisation over the release of your tags.

Creating a Batch

Batches are created at the Tag Group level.

Navigate to the Tag Group where you wish to create your Batch, then the Batches panel. Click 'Add New Batch'. This will instantly create a new Batch and display the Batch screen.

You can name your new Batch in the Batch Data Panel > Core Tab

The Batch name is used internally for management but can also be dynamically included in the Response using Subtags.

Moving a Batch

You can move Batches between Tag Groups within the same Active Folder. Batches cannot be moved outside the current Active Folder.

To do this, on your chosen Batch screen, navigate to Batch Detail Panel > Move Tab. Select your destination Tag Group from the dropdown list and click 'Move Batch'. All Tag Codes within this Batch will automatically inherit any Rules or settings from the destination Tag Group.

Deleting a Batch

To delete a Batch, on your chosen Batch screen navigate to Batch Detail Panel > Settings Tab. You will be asked to confirm your delete action.

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Overview

The Tag Group level is designed a broad management level for tags that will have a similar response. In many cases, projects can be managed simply from Tag Groups.

Important Tag Group settings :

• Rules

• Extended Data Defaults

Creating Tag Groups

You create Tag Groups at the Active Folder level.

Scroll down to the bottom of the Active Folder page to the Tag Groups panel. Click the Add New Tag Group button. This will direct you to the Add New Tag Group screen where you can enter the name of your new Tag Group.

Tag Group names can only have a character restriction so they can be used within Dynamic Response.

Tag Type

Flex Pro Flex Alpha

If you are on the Flex Pro or Alpha plans, then you can also select the Tag Type of your Tag Group. This cannot be changed after the Tag Group has been created. If you are using authentication grade NFC tags (NTAG424 for example), then you must select Authentication. If you are using standard NFC tags (NTAG213 for example), then you should select Standard.

This setting changes the way that data is handled and it's important to select the right Tag Type.

Deleting Tag Groups

Tag Groups need to be empty of all Tag Codes and Batches before they can be deleted.

Navigate to the Tag Group you want to delete, then Folder Detail Panel > Settings Tab. Select Delete from the Folder Status dropdown menu. Then Update. You will be prompted to confirm you are sure and then the Tag Group will be deleted.

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

New Active Folders

Before an Active Folder can be used, the Response Mode needs to be selected. After creating a new Active Folder, navigate to the Settings tab on the Folder Detail panel. Select the chosen Response Mode and click Update to activate.

The available settings will depend on the Response Mode. However, there are also some generic settings across all Modes.

Generic Active Folder Settings

These are settings available across more than one of the Response Modes.

Folder Status

Folder Detail Panel > Settings Tab

Changes the Status of the Folder and all Tag Groups, Batches and Tag Codes underneath. Options are :

Active : Normal function.

Inactive : Tag Code response is disabled.

Delete : Will delete the Folder. All Tag Groups need to have been deleted to delete a Folder.

Folder Name

Folder Data Panel > Core Tab

Change the name of your Folder. As Folder names can also be used in Responses (see Dynamic Response), the range of allowed characters is limited. Any update to the Folder Name here is instantly changed throughout the system.

Redirect Response Mode Settings

TapStart

Folder Detail Panel > Settings Tab

Disables or enables the TapStart feature. This can only be set before any Tag Codes have been added to the Folder.

Test Mode

Folder Detail Panel > Settings Tab

Test Mode allows you to see the decision process and actions taken during the Redirect. It is designed as an easy debug mechanism to understand, for example, how any Rules are being processed.

Locus

Folder Function Panel > Locus Tab

Locus is a powerful feature that enables limited control over Tag Codes directly from an NFC tag scan. The Locus status settings for this Folder can be set as follows :

Off : No Locus access is allowed for Tag Codes under this Folder.

Registered User : Any Registered User (Account Master, Admin User or Controlled User) can access Tag Codes under this Folder.

Anyone : Any User can access Tag Codes via Locus.

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Overview

Tag Group settings will be dependent on the selected Response Mode and other Active Folder settings.

Generic Tag Group Settings

These are settings available across more than one of the Response Modes.

Tag Group Status

Tag Group Detail Panel > Settings Tab

Changes the Status of the Tag Group and the effective status of the Tag Codes underneath. Options are :

Active : Tag Codes under the Tag Group are Active.

Inactive : Tag Code response is disabled. For both Redirect and Direct Response Mode, any request for Response (ie, a tag scan directing to ixkio), will show a blank page. No message is provided. For API Response Mode, a 'tg_inactive' error will be returned.

Delete : Will delete the Tag Group. All Batches need to have been deleted to delete a Tag Group.

Chip Count Enabled (was Tag Count)

Tag Group Detail Panel > Settings Tab

This will enable the display of the Chip Count within the interface. Read the notes on the difference between between Chip Count and Scan Count.

Tag Group Name

Tag Group Data Panel > Core Tab

This changes the interface name for the Tag Group. This name can also be included in the Response using Subtags.

Extended Data Defaults

Tag Group Data Panel > Extended Tab

Allows the setting of default data for any Extended Data fields you have created (at the Active Folder level). Any data entered here will automatically be inherited by all Tag Codes within this Tag Group unless specifically set at the Tag Code level.

Extended Data defaults can be included in the Response either using Subtags or Data Merge. To include this data in a Data Merge response, you also need to allow this on the Active Folder > Folder Function Panel > Response Tab.

Redirect & API Tag Group Settings

Both the Redirect and API Response Mode allow Tag Group Rules.

Tag Group Function Panel > Ruleset Tab

Rules control how ixkio responds to a request. A Rule is required but can be as simple as a default Response such as a destination URL.

Rules created at the Tag Group level are automatically inherited by all Tag Codes within that Tag Group. However, Rules can also be set for each Tag Code and will replace these Tag Group Rules. This allows for a flexible and specific control over large Batches of Tag Codes but also a granular level if required.

What is a Response Mode ?

The Response Mode will define how you will interact with the ixkio platform.

Ixkio has three Response modes : Redirect, API and Direct. Each of our plans is tailored to one of these modes although it is possible add an additional mode as an add-on Module.

The Response Mode is set at the Active Folder level.

Redirect

The Redirect system allows management of what's typically called dynamic links.

When the NFC tag is scanned, the user is directed to the ixkio platform. Ixkio checks where the tag needs to redirected to and redirects the user immediately. This happens almost instantly and user isn't aware of the redirect.

Setting up a redirect is quick, easy and flexible. It allows the management of tag destinations after the tags have been deployed.

API

The API Response Method is primarily designed for advanced users, specifically catering to the use of authentication NFC tags.

The NFC tags will link to your third party server first. Your server will extract parameters from the URL and make an API request to the ixkio platform. Ixkio will then respond to your server verifying the tag details.

Direct Response

With Direct Response mode, ixkio displays the landing page directly on tag scan. No other website or server is required.

• Build templates using a drag and drop creator

• Upload your brand and content images

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Generic Tag Code Settings

Tag Status

Tag Detail Panel > Settings Tab

Modifies the Status of the Tag Code. Options are :

Active : Normal function.

Inactive : Tag Code is disabled. For both Redirect and Direct Response Mode, any request for Response (ie, a tag scan directing to ixkio), will show a blank page. No message is provided. For API Response Mode, a 'tag_inactive' error will be returned.

Delete : Will delete the Tag Code. A prompt will be given to confirm. This action cannot be reversed.

Tag Data (Core)

Tag Data Panel > Core Tab

The Tag Name does not have to be unique across your account which allows you to have the same Tag Name in multiple Batches, Tag Groups or Folders.

The UID and CUID need to be unique across your entire account. The console will prevent you from entering the duplicate UID or CUID entries.

Tag Data (Extended)

Tag Data Panel > Extended Tab

If you add Extended Data at a Tag Code level, it will overrule the default Tag Group level Extended Data. However, if you then delete the data at the Tag Code level, the Tag Code will then automatically inherit the default Tag Group level data again.

Redirect & API Tag Code Settings

Both the Redirect and API Response Mode allow Tag Code Rules.

Tag Code Function Panel > Ruleset Tab

Rules control how ixkio responds to a request. A Rule is required but can be as simple as a default Response such as a destination URL.

Any Rules created at the Tag Group level will automatically be inherited at the Tag Code level.

However, you can also create Rules at the Tag Code level which will overwrite any default Tag Group Rules.

Once a Tag Code Ruleset has been created, click on the 'Revert' button which will remove any Tag Code level rules and the Tag Code will default back to the Tag Group Rules.

Authentication Tag Code Settings

If you have ordered your Authentication NFC tags from our sister NFC Tag company Seritag, then we will have uploaded the keys already into your Tag Codes and you will be ready to use.

If you are using your own tags then contact us to enable key uploading as it's not available by default. Once enabled, you can upload keys at the Batch level for any Tag Codes under that Batch. Note that there can be a 1-2 hour delay between uploading keys and becoming active.

You can see whether the keys are loaded from the Tag Code screen, then Tag Detail Panel > Info Tab. Under the setting 'Tag Type' which should say 'Authentication' (not 'Standard') there will be either:

(keys not loaded) - which indicates that the keys have not been loaded yet.

(keys loaded) - which means the keys are loaded and the Tag Codes are ready for use.

NFT Settings

Flex Alpha

On Flex Alpha, you can also set NFT data against a Tag Code. You need to have enabled NFT at the Tag Group level (Tag Group Screen > Tag Group Detail Panel > Settings Tab).

Navigate to Tag Code Screen > Tag Data Panel > NFT Tab and set the Chain (Polygon Main, Polygon Test, Etherium Main, Etherium Test), Contract and Token. These need to start 0x.

Entering the Owner is optional.

Overview

Ixkio supports using QR Codes either alongside or instead of NFC tags. It's possible - and in many instances very useful - to use the same Tag Code on both an NFC tag and a QR Code and manage them together as one item.

You can use Tag Codes purely for QR Codes if required. There's no requirement to use any Tag Codes - or the entire platform - for NFC tags if not needed.

Tracking QR Code Scans

QR Codes can be tracked independently of NFC tag scans within the ixkio platform by using a slightly different URL. For example, if your XUID Tag Code is 12345ax, you can use either :

https://qr.ixkio.com/12345ax

or

https://t.ixkio.com/12345ax?qr=1

By using either of these options, the ixkio platform will register the scan as a QR Code scan instead of an NFC tag scan and display it as such in the stats as the 'Method'.

If you use the same XUID on both an NFC tag and a QR Code, then using 12345ax as an example XUID, use :

https://qr.ixkio.com/12345ax

on the QR Code and use :

https://t.ixkio.com/12345ax

on the NFC tag. You can then manage both on the same Rules, settings, etc but will see the different scans via the Console.

Downloading a QR Code

Tag Code Screen > QR Codes Panel

Ixkio has built in function to download QR Codes for Tag Codes. Expand the QR Codes panel and click on either 'Download as PNG' or 'Download as SVG' to get your desired format.

Downloaded QR Codes will be automatically encoded to work on that Tag Code and register in the platform as a QR Code scan.

Authentication Tags and Keys

Ixkio will store the keys used for tag authentication. For security reasons, tag keys are not visible via the console. You can access the keys at any time by contacting us and we set up a one time download option.

Authentication (NTAG424) NFC Tags purchased from Seritag

During the encoding process, Seritag will upload the tag encryption keys to ixkio so that your tags are ready to use. They are your Tag Authentication Keys and you can request them at any time by contacting us.

Authentication (NTAG424) NFC Tags encoded with the ixkio mobile app

If you are encoding blank NTAG424 tags with the ixkio mobile app, then ixkio will automatically generate the keys and store them. As always, they are your Tag Authentication Keys and you can request them at any time.

Authentication Tags encoded using other platforms

You can upload NTAG424 keys to the ixkio platform at the batch level. This setting is not enabled by default - contact us to add this function to your account.

The NTAG424 tag can be encoded in a large number of different permutations. Ixkio supports four different encoding settings and it's important that tags are encoded in a certain way so they work correctly. Contact us for more information.

With Direct Response mode, ixkio displays the landing page directly on tag scan. No other website or server is required.

• Display brand images / logos

• Display authentication status (for Authentication Tags)

• Display dynamic data including Extended Data, Core Data and System Data

• Create multiple templates and integrate with Rules to show different pages

Key Features & Terms

Templates

Templates are the layout and content of your Direct Response page. You create Templates at the Folder level using our drag and drop creator.

You can then set which Template to show using Rules at the Tag Group or Tag Code level.

The API Response Mode for use with authentication tags is similar to standard tags. For the authentication system to work :

• You must be using authentication NFC Tags (NTAG424 for example)

• The tag keys must have been loaded into the ixkio platform (how to check)

As the authentication system will only work using a unique code generated by the authentication NFC tag, we recommend testing and developing with a set of working NFC tags.

API Response

The API Response will follow the Rules configured for that Tag Code (or inherited by that Tag Code from the Tag Group).

For the authentication system to work correctly, we need to create a Rule Group that will activate on a successful authentication and provide a Response and then, on a fail, will fall back to the Default Response.

Example Configuration

For this example, we will assume that a simple configuration has been created with an Active Folder > Tag Group (authentication type) > Batch > Tag Code. You will also need a sample authentication NFC tag associated with this Tag Code. (It's possible that if we have provided some sample tags, we will already have configured the Rules as detailed for you. You can, of course, change them.)

For this example, we are going to set a Rule at the Tag Group level. It is possible to set the rule for each individual Tag Code as well.

At the Tag Group level, you need to create the Authentication Rule Group. On the Tag Group screen, under Tag Group Function Panel > Ruleset Tab, click on 'Add Rule Group'. Click the small burger menu on the right, then 'Add New Rule'. Select 'Tag Authentication', then 'Authentication Pass'.

You will now have two empty 'Response' fields.

The first is for the 'Rule Group API Response' - which is the response given on a successful authentication. Enter 'Pass' into this field.

The second is the Default API Response. This is the response if the authentication is not successful (ie, a fail). Enter 'Fail' into this field.

Then click 'Save Changes'.

Testing

We will be testing a tag XUID of 'q8w3sbcz'. The sample NFC tag will have been configured to hit your server first. So you will need to extract the correct parameters from the URL query string.

There are a few ways that this can be configured - see notes below - but we will explain the standard method.

Step 1 : The Tag Scan

On scanning the NFC tag, the URL will be presented as follows :

https://yourdomain.com/auth?x=q8w3sbcz&n=000001&e=abcde12345abcde1234

(Where, in this example, yourdomain.com is your website and auth is your page handling the tag scans)

Step 2 : Your Server Request

Your server needs to extract the x, n and e parameters and make an API call to our server as follows :

GET https://api.ixkio.com/v1/t?x=q8w3sbcz&n=000001&e=abcde12345abcde1234

Remember that both the n and e parameters will change on every scan. You should only test directly from each tag scan and don't change the parameters in any way until you are comfortable with the platform.

Step 3 : The Response

The ixkio platform will now respond to your API request after checking the authentication. Based on the Rules we have created, a successful authentication would return :

{
	"xuid": "q8w3sbcz",
	"response": "Pass"
}

If the authentication fails, the response would be :

{
	"xuid": "q8w3sbcz",
	"response": "Fail"
}

An error in the request would be, for example :

{
	"xuid": "q8w3sbcz",
	"error": "batch_inactive"
}

Response to CUID or UID requests

If your request is via the CUID or UID method, then a successful response will return only the CUID and the associated XUID. For example, a request for :

GET https://api.ixkio.com/v1/t?a=youraid&c=yourcuid&n=000001&e=abcde12345abcde1234

will generate a successful response of :

{
	"xuid": "q8w3sbcz",
	"cuid": "yourcuid",
	"response": "Pass"
}

The 'n' Parameter

The 'n' parameter passes the ixkio platform the scan count from the NFC chip itself (in hexadecimal). This is not the same as the ixkio scan count as explained in our Chip Count vs. Scan Count page.

The ixkio platform uses the chip count along with the unique tag 'auth' code (the 'e' parameter) to authenticate. Each 'n' chip count will have a matching 'e' auth code. If they are out of sync, then the response will be a fail.

Some important points :

Ixkio will believe you

Ixkio will believe whatever 'n' chip count parameter you send it.

The chip count can only move forward

The chip count can never go backwards on the ixkio platform. If you accidently set the chip count to 1,000, then only a genuine tag scan from 1,001 onwards will now work. You cannot 'reset' the chip count on the ixkio platform.

Single use

Once a chip count has been used, it is instantly no longer valid. If you 'refresh' the API request, you will get a failed authentication.

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

Generic Batch Settings

Batch Status

Batch Detail Panel > Settings Tab

Modifies the status of the Batch. Options are :

Active : Normal function.

Inactive : Tag Codes within this Batch are disabled. For both Redirect and Direct Response Mode, any request for Response (ie, a tag scan directing to ixkio), will show a blank page. No message is provided. For API Response Mode, a 'batch_inactive' error will be returned.

Delete : Will delete the Batch. A prompt will be given to confirm. This action cannot be reversed.

Batch Name

Batch Data Panel > Core Tab

This changes the interface name for the Batch. This name can also be included in the Response using Subtags.

Encoding Data

Batch Function Panel > Encoding

Encoding URL for Tag Codes within the Batch can be downloaded as a CSV file. The CSV also contains XUID Tag Codes and any CUID entered for reference purposes.

Associate Data

Batch Function Panel > Associate

The Associate Data feature can be used to upload CUID, UID or default Response data via CSV for all of some of the Tag Codes within a Batch.

Batch Screen > Tags Panel

You can move Tag Codes individually between Tag Groups and Batches.

Select which Tag Codes you want to move by checking the box to the left of the XUID, then 'Move Selected Tags'. Navigate to your destination Batch and on the Tags Panel at the bottom, click Move Tags Here.

The Tag Code will automatically inherit any settings or Rules from the new Tag Group and Batch.

The Redirect Mode, like all ixkio configurations, has a number of flexible options. We recommend starting with a simple configuration then gradually experimenting with the features to get your best setup.

Setting up Redirect Mode

These steps are designed to get you started with a simple configuration.

Adding Tag Codes

Create a new Active Folder, then under Folder Detail Panel > Settings Tab, select the 'Redirect' Response Mode and click 'Update'.

Then, add a Tag Group (click 'Add Tag Group' from the 'Tag Groups Panel'). This will automatically create a Batch. Click on the 'Batch 1' link to view the Batch Screen.

From the Batch Function Panel > Add change the quantity to 10 and click on 'Add Tags' to add some Tag Codes. This will have created 10 new Tag Codes and the full management structure.

We would recommend you test the set up on an NFC tag. From the Batch Screen, click on the Tag Code XUID link on the Tags Panel to get the Tag Code screen for that XUID. From here you can get the encoding URL by clicking the link icon from the Tag Detail Panel > Info Tab.

Managing the Redirect

Tag Codes can each have an individual Default URL or you can set the Default URL at the Tag Group Level and it will be inherited by all Tag Codes.

To set the redirect URL for the 10 Tag Codes created in the sample above, navigate to the Tag Group level (use the breadcrumb menu).

Then, enter a full URL (including https:// or http://) into the 'Rule Set Default URL' field at Tag Group Function Panel > Ruleset Tab. Now, all the 10 Tag Codes will redirect to your URL on scan.

Using Authentication NFC Tags

Authentication NFC tags need to be encoded by Seritag (ixkio's sister company) to be used on the ixkio platform. Seritag will encode the tags for your project and upload the encryption keys directly to the platform ready for use.

We strongly advise discussing your requirements with us before proceeding but the general process is :

1. Contact us to discuss or inform us of required NFC tag type

2. Create your Active Folder, Authentication Tag Group and Batch

3. Add the required number of Tag Codes into your Batch

4. Contact us with details of where you have created your Tag Codes

5. We encode your tags for the platform and upload the encryption keys

Designed for for verification of authentication tags, ixkio's Response API access is available on Flex API, or on other plans with the Extra Response Mode module.

Use of the API system requires a strong understanding of technical knowledge and the ability to access and develop your webserver at an in-depth level. Ixkio cannot give advice on setting up or the configuration of your server beyond advising how our server would respond to an API call. If you aren't technically minded or don't have access to technical developers, we'd recommend using our Redirect Response Mode instead.

Typical Use Case

In all cases, the authentication NFC tag will link directly to your webserver or application, rather than linking directly to the ixkio platform. In other words, you can't use ixkio as a redirect and API platform for the same tag.

Where the tags are linked to a website, your webserver would extract the query string parameters from the URL and then make a GET request with those parameters to our server. The ixkio server will check the parameters and respond with a pass or fail message.

Your server can then respond directly to the user with the appropriate message.

API Overview

The ixkio Response API system is designed to be easy to use and access.

• The Response Mode API can only be used to extract tag information, not set, create or change it

• Rules can be used to control the API response

• All API requests must be on https not http

• Access to API can be open or controlled with an API Key

The Redirect Response Mode allows the control of tag destinations after tags have been deployed. It's a very powerful, flexible and easy to use option.

When using the Redirect Response Mode, tags will link to the ixkio server first and then redirect to a third party website/page depending on rules you set. You can change the destination and the redirect rules of your tags as many times as you like quickly and easily.

Getting Started with Redirect

Key Features

Rules

For example, you can define a Rule that directs your tag scans to Page A on the first scan and then Page B for all subsequent scans.

Rules can be set at the Tag Group Level or at the individual Tag Level.

Dynamic Response

For example, this can allow you to add serial numbers to Tag Codes at any stage within the ixkio platform and then have those numbers dynamically added to your redirect link.

Overview

Rules allow you to change the Response depending on criteria that you set.

For example, for Tag Authentication on Redirect Response Mode, you would create a Rule to provide one Response (a Redirect to a 'Pass' page) for Authentication Pass and then another Response (a Redirect to a 'Fail' page) for Authentication Fail.

Rules can be set at the Tag Group Level or the Tag Code Level.

Tag Group Rules will apply to all Tag Codes under that Tag Group.

You can also set specific Rules for individual Tag Codes at the Tag Code level. These will override the general Tag Group Rules.

If you have a very small number of tags, you might manage the Rules on a tag by tag basis. In the majority of cases, it's likely that you will manage a number of tags together at the Tag Group level.

Rule Structure

Rules are managed as Rule Set > Rule Groups > Rules.

A Rule Set contains Rule Groups. Each Rule Group contains Rules, such as 'is the count less than 5'. And each Rule Group also has it's own Response (ie, it's own URL destination).

In addition, the whole Rule Set has it's own Response. This is the 'Default' Response to return if no Rule Groups are matched.

On a request, ixkio will run down through each Rule Group in order looking for a positive match.

If the Rule Group is matched (for example, the count is less than 5), it will return that Rule Group Response.

If it doesn't it will move to the next Rule Group and check that one.

If no Rule Group is matched, then it will return the Rule Set Default Response.

Rule Set

• The Rule Set displays all the Rule Groups created by you.

• You are allowed up to 3 Rule Groups in a Rule Set.

• Each Rule Set has a Default URL or Default API Response. If no Rule Group is matched (or no Rule Group is created), then the response will be either the Default URL (in the case of Redirect Mode) or the Default API Response (in the case of an API Mode).

• You must have a Rule Set and set a Default Response.

Rule Group

• Rule Groups are optional. You can just use a Rule Set Default Response.

• Each Rule Group can have up to 3 Rules.

• Each Rule Group has it's own URL or API Response. This response is activated when the all the Rules of a Rule Group are matched.

• Rule Groups are processed in order. The top Rule Group gets checked first. If the Rules do not match, the next Rule Group is checked. If no Rule Group is matched, the Rule Set Default URL/API Response is used.

• It is possible to reorder, delete, change and add to your Rule Groups at any time.

Rules

• Scan Count

• QR/NFC

• Tag Authentication

Each Rule has a 'Criteria' and a 'Target'

• A Criteria allows you to choose how you want to match.

• The Target (if shown) will be what the Criteria will match against.

For example, Scan Count could have a Criteria of 'More Than' and the Target could be 5. The Rule would therefore match if the Scan Count reached more than 5 scans.

These pages discuss accessing the API for the purposes of using the API Response Mode. While the API can be used with standard tags, it is designed for use with Authentication Tags.

Accessing the API

The ixkio API is accessed at the following endpoint via :

Early ixkio users might have accessed the API via https://t.ixkio.com/k. We would recommend updating to the new v1 endpoint as soon as possible.

Parameters should be passed in the query string as follows :

XUID (Required*)

x={XUID}

Example : GET https://api.ixkio.com/v1/t?x=abcd1234

The Tag Code (XUID) needs to be added to all API GET requests unless you wish to access the tag using your CUID or UID.

As the XUID is unique across the entire ixkio platform, there is no need to include any additional identifier or your AID with this request type.

If you are not using authentication tags, then this can be the only parameter you need to include to generate a response from the API.

CUID or UID (Optional*)

c={CUID}

Example : GET https://api.ixkio.com/v1/t?c=yourcode&a=abc123

or

u={UID}

Example : GET https://api.ixkio.com/v1/t?u=04AABBCC112233&a=abc123

API Response

The API Response will follow the Rules configured for that Tag Code (or inherited by that Tag Code from the Tag Group).

For this example, we will assume that a simple configuration has been created with an Active Folder > Tag Group (standard type) > Batch > Tag Code. We will also assume that a 'Default API Response' has been set at the Tag Group level. In this example, we will simply use a Default API Response of 'Found'. We will be testing a tag XUID of 'q8w3sbcz'.

The API request is made to :

The API will return a JSON response in the format :

Error responses will be provided as :

Response to CUID or UID requests

If your request is via the CUID or UID method, then a successful response will return only the CUID and the associated XUID. For example, a request for :

will generate a successful response of :

(where 'Found' is the API Response entered into your Tag Group or Tag Code Rule)

However, a failed response for an incorrect AID will return an error :

where a not found CUID will return :

API settings

API settings are controlled at the Folder level and affect all Tag Groups, Batches and Tags under that Folder. It's possible to set different API settings on different Folders to allow different access options.

Navigate to the API Folder Level, then the API Settings panel to make changes to the settings.

API Tokens

By default, access to your API does not require any token. However, you can set token access in the API settings to restrict access.

An alphanumeric token up to 32 characters in length can be added into the API Token field.

The API Token can then be passed in either GET query string using the parameter 'r', for example :

r={API_TOKEN}

Example : GET https://api.ixkio.com/v1/t?x=abcd1234&r=yourapitoken

Alternatively, you can pass the token in the GET Header request using any one of the keys X-API-Key, X-Api-Key or Ixkio-R.

CORS

No setting (default)

If you leave the CORS setting blank, then the API response will be returned without an Access-Control-Allow-Origin header.

*

Entering a * into the CORS field will allow access from any domain.

Domain

Entering a specific domain, such as https://seritag.com (no trailing slash), will activate the Access-Control-Allow-Origin header response with the value of the domain entered. The CORS field will accept a single domain value up to 100 characters in length.

Rate Limits

Access to the API is rate limited and monitored to maintain overall service levels. However, under all normal NFC use cases, users would not hit any limits.

We will contact you if our systems flag any unusual or high volume access.

Using Authentication NFC Tags

Seritag Encoding

If you are purchasing your NTAG424 tags from Seritag, you can ask for them to be encoded before shipping. In this instance, Seritag will encode the tags and store the encryption keys against each tag.

Ixkio App Encoding

You can use the ixkio mobile app to encode authentication tags for the API response mode. Read the guide here on how to configure the console for encoding Tags to your auth landing page.

Encoding Tags Yourself

If you can encode the NTAG424 tags yourself, you can upload the keys into the ixkio platform.

• Create the Tag Codes in a new Batch in your Console

• Download the XUID (Batch Function Panel > Download)

• Generate your own keys and create an Associate Data file with the header XUID,KEY

• Upload your Keys into the ixkio platform at Batch Function Panel > Keys

Organisation Folders > Active Folders > Tag Groups > Batches > Tag Codes

What is a Tag Code/XUID?

A Tag Code or 'XUID' is a unique 8 or 16 character code which defines that tag within the ixkio platform.

This XUID is used in the tag URL which is encoded on the NFC tag to direct to the ixkio platform (or used via the API).

For example, a Tag Code of 12456ax would be encoded onto an NFC tag as t.ixkio.com/123456ax . This will then identify the Tag Code within the platform.

Encoding multiple NFC Tags with one XUID

In the majority of use cases, each Tag Code would be encoded onto each NFC Tag allowing for full control over every tag.

However, you can also encode multiple NFC tags (or QR Codes) using the the same Tag Code. For example, one Tag Code can be encoded onto 100 different NFC tags. In this instance, all 100 NFC tags would be managed together.

Important notes for encoding multiple NFC tags with the same XUID :

• Chip Counts will not work correctly if the same XUID is used across multiple tags

• Authentication NFC Tags must be encoded with unique XUID (or CUID/UID) codes

Creating a Tag Code

Batch Screen > Batch Function Panel > Add

Tag Codes are created at the Batch level. Tag Codes can be added in any quantity up to your current account limit. Enter the quantity of desired Tag Codes and set the Status (Active or Inactive).

If you have enabled Assignment, then you will also need to select the starting Assignment Status of the Tag Codes.

Click 'Add Tags' to add your Tag Codes.

You can add additional Tag Codes to a Batch at any time.

Moving Tag Codes

Instructions on moving tag codes, can now be found on a dedicated page.

Deleting a Tag Code

Tag Screen > Tag Detail Panel > Settings Tab

Select 'Delete' from the 'Tag Status' dropdown and click 'Update'. You will be prompted to confirm the deletion.

Deleted Tag Codes are not re-used on your account or any other ixkio account.

Scan Count

A Scan Count is how many times the NFC tag or QR code has been registered on the ixkio Console. The Scan Count rule has a few Criteria options such as:

• Count less than

• Count more than

• Count equal to

• Count not equal to

From here you can set your Target. For example, Scan Count more than 10.

Scan Method

Scan Method matches how the scan occurred. In almost all configurations, this would be either NFC or QR code. This option isn't available on the API Response Mode.

For example, this means you can redirect a QR code to one URL and an NFC tag scan to another URL.

Tamper

If Tag Tamper has been enabled on your tag (only available on a very limited number of specialist tags) then you can change response based on tamper status.

The Tamper rule has just two Criteria options to match the chips encoded tamper response :

• Tamper equal to

• Tamper not equal to

User Authorisation

When creating a Rule in the Rule Group, you can choose from the following settings:

• Not Registered User - Anyone that is not registered

• Any Registered User - Anyone that is registered (and logged in)

• Administrators Only - Only Account Master and Account Admin Users (Multiuser systems only)

This Rule is not available on API Response Mode. We recommend using SmartAccess instead of User Authorisation for easier management.

SmartAccess Group

Allows users that have scanned SmartAccess Cards within this SmartAccess Group.

Mobile OS

Allows the creation of a Rule based on the Mobile operating system - either iOS or Android. This Rule is not available on API Response Mode.

Mobile Browser

Allows the creation of a Rule based on a selection of the current most popular Mobile Browsers - Safari, Chrome, Samsung, Firefox, UC Browser or Opera. This Rule is not available on API Response Mode.

Tag Authentication

For Tag Groups using Authentication NFC tags this is an essential Rule.

You need to create a Response for 'Authentication Pass' and then a Default Response.

Assignment Status

Creates a Rule based on the Assignment Status of that Tag Code. Can be either Assigned or Unassigned. Used for controlling the destination (or API response) of deployed or not-deployed Tag Codes.

Overview

For this example, we will create a Rule within a Redirect Response Mode configuration.

Redirect Rule Example

How the Ruleset works

In this example, we have created two Rule Groups. The Rule Groups are processed in order.

User scans an NFC tag for the first time

The user scans a tag for the first time and therefore the scan count is 1. As the scan count is less than 5, then the first Rule Group will be matched and the Rule Group URL : https://seritag.com will be the response. Therefore, the user scanning the tag will be redirected to our seritag website.

User scans an NFC tag for the 5th time

In this instance, the scan count is now 5. The first Rule Group no longer matches so ixkio will proceed to the second Rule Group.

This has two Rules. The scan must be from an NFC tag and the scan count is less than 10.

In this instance, the scan would match the second Rule Group and the Rule Group URL : https://seritag.com/learn/ would be returned.

User scans an NFC tag for the 11th time

Now, neither the first or second Rule Groups would match and the response would default to the 'Rule Set Default URL'. In this example, the response returned would be https://ixkio.com. Therefore, the user scanning the tag would be redirected to our ixkio website.

QR Code Scenario

If the first four scans were from an NFC tag and the fifth scan was from a QR code, then the scan count would still be five (as ixkio's scan count is for both NFC and QR).

However, while the scan count is less than 10, the fifth scan was not from an NFC tag and therefore the second Rule Group would not match.

The response would therefore default to the Rule Set Default URL.

Overview

Rules are created at either the Tag Group or Tag Code level.

Rules created at the Tag Group level will apply to all Tag Codes under that Tag Group - unless you create separate Rules for a specific Tag Code.

Where to Create Rules

Tag Group Level

To create Rules at the Tag Group level, navigate to your Tag Group and then Tag Group Function Panel > Ruleset Tab.

Rules created at this level will, by default, apply to all Tag Codes under this Tag Group.

If you navigate to a Tag Code, you will see that the Rule Set Default URL (and, if set, any Rule Groups) are 'inherited'. This means they are getting their Rules from the Tag Group level.

Tag Code Level

Rules can also be created at individual Tag Code level. These rules will override the Tag Group Rules. You can 'revert' back to the Tag Group Rules at any time.

To create Rules at the Tag Code level, navigate to your Tag Code and then Tag Function Panel > Ruleset Tab. Then just follow the create rules instructions below.

Creating Rules at the Tag Code level will break the link to the Tag Group rules and they will no longer be inherited. However, you can revert back at any time by clicking the 'Revert' button.

Creating Rules

The same process applies at both the Tag Group and Tag Code levels.

Setting the Rule Set Default Response

To begin with, you will have a 'Rule Set Default Response'. For API, this will be a field that will show in the API response. For Redirect Mode, this will be a URL.

This is the Response if no Rule Group is matched.

Adding a Rule Group

Click on the 'Add Rule Group' button to add your first Rule Group.

Until you have added all the data and settings required, the Rule Group will not be active.

Add a Response

The Rule Group will have a it's own Response. Again, for API, this will simply be some text. For Redirect, this will be a URL.

This is the Response that is given if all the Rules in that Rule Group are matched.

Add a Rule

Click the small burger menu icon on the top right of the Rule Group box and select 'Add New Rule'. This will allow you to select from the Rule options for your account configuration. For example, you might select 'Scan Count'.

You can now see the Criteria and possibly the Target (for the Criteria) for that Rule.

For 'Scan Count', you could select 'Count Less Than', with a Target of 5.

Save Changes

Once you have added your Rule Group Response and set your Rule, you can 'Save Changes' to activate.

Changing Rule Group Order

Click and hold on the icon in the top left of the Rule Group and drag up and down.

Rule Groups are processed in order. So if the first Rule Group is matched, the second will not be processed.

If no Rule Group is matched, then the Default Response will be given.

Deleting a Rule Group

Click on the burger menu icon on the top right of your Rule Group and select Delete. Note that you will not be prompted to confirm the deletion.

Overview

Dynamic Response is used to add Enhanced Data (tag information or system information) dynamically into your Responses.

For example, you can set your redirect URL link to dynamically include the Tag Code's Batch Name, Scan Count, an Extended Data field such as a CUID or chip UID, the Tag Name and more.

Tag Codes moved from one Tag Group to another can automatically inherit Enhanced Data and therefore dynamically change response just by being in another location within the system.

Dynamic Response can be used with all three response types : Redirects, Direct Reponses and API Responses.

It's a very powerful and flexible system and is often an integral part of using the ixkio tag management system.

Dynamic Response uses two systems which can be used separately or even combined to achieve more complex responses.

Subtags

Subtags dynamically add Enhanced Data into the responses. This is handled by using curly brackets {}.

For example, you could add a CUID (custom unique ID) stored in the ixkio platform dynamically onto a URL by including {CUID} within your redirect response.

So, if your CUID for Tag Code was 12345, a URL entered as :

https://seritag.com?code={CUID}

would become :

https://seritag.com?code=12345

Datamerge

Datamerge allows you to dynamically add Extended Data onto your responses. In other words, it will add them to your response rather than substituting into your response as Subtags would. Note that datamerge only works with Extended Data (not the entire Enhanced Data set).

For example, assuming you had an Extended Data field set up as 'Colour' and the data for that field for a particular Tag Group was 'Blue'. You could use datamerge to change your Redirect URL from :

https://seritag.com

to :

https://seritag.com?Colour=Blue

Overview

Rule Layering is a specific configuration where you can use the Rules from a Tag Group layer with the Default Responses of the Tag Code layer.

This can be useful if you want to set a generic Rule across all the Tag Codes within a Tag Group but want to set individual URLs on each of the Tag Codes themselves.

How to use Rule Layering

To use Rule Layering, you should have configured your Rules at the Tag Group level. In one (only one) of your Rule Responses, you add :

{tagcodedr}

At the Tag Code level, you need to enter your Default Destination URL for that Tag Code.

Under normal use case, ixkio would not process Tag Group Rules if a Default Response had been entered at the Tag Code level - the Tag Code Response would overrule.

However, with Rule Layering, ixkio processes the Tag Group Rules instead and the uses the Tag Code URL where you have used {tagcodedr}

Rule Layering Example

Let's assume we have a configuration where you want to prevent all non-registered users from being redirected to a Tag Code URL. In this instance, each of our Tag Codes has it's own URL.

We create a Ruleset at the Tag Group level like this :

Where a Not Registered User would be directed to Seritag and therefore Registered Users would pass through to the Default URL. For this Default URL, we've entered the Rule Layering code {tagcodedr}

At the Tag Code level, we will enter our Default URL as :

Normal Process

Under normal ixkio process, as the Tag Code Ruleset Default URL is configured, ixkio would use this and ignore the Tag Group Rules, however...

Rule Layering Process

When Rule Layers are enabled (by using the {tagcodedr}), then ixkio uses the Tag Group Rules first. In this example, a Non-Registered User would be directed to Seritag. A registered user would pass through to the Tag Code URL, which in this case would be ixkio.

When to use Rule Layering

Generally, when you are entering specific, unique URLs for every Tag Code but want a global Ruleset to apply to them all.

Without Rule Layering, you would need to add Rules to each and every Tag Code. With Rule Layering you can have a global generic Ruleset but still allow each Tag Code to have it's own URL.

Note that there are often alternative ways to do this if you aren't adding specific full URLs to each Tag Code - for example, adding just the unique part as a CUID or Tag Name on each Tag Code and then using Subtags at the Tag Group Rule level.

Enhanced Data is additional data (metadata) or information associated with a Tag Code.

Core Data

Core Data fields are created with every Tag Code. By default, they are empty fields. Any data you add will be associated only with that Tag Code. The Core Data fields are :

• Tag Name

• UID

• Custom UID (CUID)

Extended Data

Extended Data fields are optional. They are either text or dates that can be associated with a Tag Code.

Extended Data fields can be given data at the Tag Group level to be inherited by all Tag Codes within that Tag Group. Additionally, Extended Data fields can also be given data at the Tag Code level either instead of the Tag Group data or to overrule the Tag Group data.

For customers used to using Rules, the Tag Group / Tag Data inheritance works in the same way.

Up to 5 Extended Data fields can be created.

System Data

System Data is data that is automatically associated with Tag Codes. This is either in relation to their location within the system, such as the Batch Name where the Tag Code is located, or data associated with changes to the Tag Code such as Scan Count or Created Date.

For example :

• Batch Name

• Tag Group Name

• Chip Count (if enabled)

• Scan Count

• Date Created

Action Data

• OS - android/iOS

• Browser

• Country

• Time Zone

Flex Pro Flex Alpha

This document explains how to include subtag data within Extended Data fields on an API request. This can be useful if you want to access data using subtags but do not want to include that data within the Ruleset Response.

Step 1 : Create your Extended Data field

Active Folder > Folder Function Panel > Data Tab

Create a new Extended Data field by entering a name for your field, selecting 'text' or 'JSON' and clicking 'Add'

NOTE : The JSON data type is currently in Beta and should only be used for the NFT metadata Subtag.

Step 2 : Add the Extended Data field to the API response

Active Folder > Folder Function Panel > Response Tab

Change the 'Response' option for your Data Name (as created in Step 1) to 'Add to Response'.

Step 3 : Add the Subtag to the Extended Data response

Tag Group > Tag Group Data Panel > Extended Tab

Under the Extended Data name you just created, enter your Subtag. For example, if you created a Data field called 'scancount', you can add {scount} to dynamically display the Tag Code Scan Count.

The resulting API response would be :

Overview

Datamerge is useful for passing information stored about the Tag Codes through automatically. In addition, the Datamerge data will follow the Tag Code location so that if a Tag Code is moved to another Tag Group - it can then dynamically show Extended Data associated with the new Tag Group.

You can even add Subtags into your Extended Data fields. So you can create an Extended Data field and then add a Subtag into the field data to combine the two dynamic response methods to create more complex response structures.

Using Datamerge

Using Datamerge varies significantly between the Response Modes.

Redirect Mode

When you are using the Redirect Mode, Datamerge will add Extended Data to the end of your Redirect URL as a query string.

Then, navigate to the Active Folder level and Folder Function Panel > Response Tab and change the Append setting of the 'Colour' Data Name to 'Add to Redirect'. You are telling ixkio to add this Extended Data field to the end of your Redirect URL.

This will change your redirect URL from :

to :

If you already have a query string in your redirect URL, then Datamerge will add it to the end of this. For example :

would become :

API Response Mode

Flex Pro Flex Alpha

If you make an API request as usual (in this example to Tag Code q8w3sbcz):

The API will return a JSON response in the format :

(This example also assumes you have also set up an API Response of 'Found'.)

Datamerge responses are not included in API error responses. If your API request returns an error, it will not include the Extended Data fields.

Overview

System Data is additional information associated with a Tag Code which either isn't directly related to the Tag Code or is other data not user editable.

• Batch Name

• Tag Group Name

• Chip Count (if enabled)

• Scan Count

• Date Created

Once a Tag Code has been created within the ixkio platform, it's possible to upload data via a CSV file to set the Core Data and/or the Default URL/Default API Response rather than entering manually.

Preparing the data file

Get the XUID list

Associate Data uploads are managed on a Batch by Batch basis so you can only associate Core Data to an XUID that is within that Batch.

The easiest way to get the list of Tag Codes (XUIDs) from a Batch is to download the encoding data. From a Batch screen, navigate to the Encoding tab of the Batch Function panel. Click on Download Data to get the list of XUID for that Batch.

The file needs to be in CSV format which is a comma delimited file. The file can be named .txt or .csv. You can save and create in a text file if you prefer or work in Excel (or similar) and save as CSV. You can't upload as an Excel file.

The first line of your Associate Data file must contain 'XUID' and then at least one of the following items - UID, CUID, TAGNAME, RESPONSE, STATUS, ASSIGNED, NFTCONTRACT, NFTTOKEN, NFTCHAIN, NFTOWNER, NFTMETA.

For example :

XUID,UID,CUID,TAGNAME,RESPONSE,STATUS

Then each subsequent line should contain the XUID Tag Code and the corresponding Data fields.

If you don't want to set any data for a particular field, then you can leave it blank but you need to include all commas for the fields you have specified. For example :

XUID,UID,CUID,TAGNAME
gts5ch6k,04AABBCC112233,12345,
h7dvbz6k,,,My Tag
mff59hek,,12345,

For the 'gts5ch6k' example, this would set the UID and CUID but not the Tag Name

For the 'h7dvbz6k' example, this would set only the Tag Name

For the 'mff59hek' example, this would set only the CUID

As another example, if you just want to add a set of unique URLs to a batch of Tag Codes, you can prepare your file as :

XUID,RESPONSE
h7dvbz6k,https://seritag.com

Changing/Updating Data

Any data uploaded for an XUID will overwrite any existing data in ixkio. You will not be prompted for the overwrite. If there is existing data that you want to keep, then you need to set the same data again.

Data formats

Core Data needs to be in a specific format for the association to work correctly.

UID

The UID should only be the UID of the NFC chip. This will be either 7 or 8 bytes in Hex - a total of 14 or 16 characters long. The UID should be in Uppercase and without spaces or other delimiters. For example, 04AABBCC112233 would be allowed. 04:aa:bb:cc:11:22:33 would fail.

Be careful if you prepare your data in excel as the leading '0' can be removed if by chance your UID is all numbers. In this case, you can add a ' before the data in excel to fix the 0 in place. Or, work only in a text file.

CUID

The CUID field can be any alphanumeric sequence along with underscores and dashes. It cannot contain spaces or other special characters. Maximum length of the CUID is 32 characters.

CUID are case sensitive.

Tag Name

The Tag Name can be any alphanumeric sequence including spaces, underscore and dashes. Maximum length of the Tag Name is 32 characters.

Duplicate data

The UID and CUID are designed to be identifiers within the ixkio platform for your tags. Therefore, to work correctly, these Core Data fields need to be unique across your entire account (not just your Batch).

You cannot upload a UID or CUID that has been used on another Tag Code anywhere in your account. Ixkio will throw an error message if it detects a duplicate.

As CUID are case sensitive, it is possible to upload a CUID with a different case. For example, ABC123 is different than ABc123 and would be allowed.

URL / API Response

Uploading a URL/API Response - RESPONSE - in the Associate Data file will only change the Default Response on each tag. Important notes :

• If the Tag Code currently inherits it's Default Response from the Tag Group, then a Tag Level Rule will be created and it will no longer get it's Default Response from the Tag Group.

• If no data is entered on the URL field on the CSV upload, the Tag Code Tag Level Rule will be removed and the Tag Group Ruleset will take it's place.

• If there are Rule Groups already in place for a Tag Code, then only the Default Response for that Tag Code will be overwritten with any data in the CSV upload. If the CSV upload has blank data for a Response, then the Tag Code will be updated to revert to the Tag Group Ruleset.

Status

Adding a Status column will allow you to change the Status of a Tag Code. Suitable values are 'Active' and 'Inactive'. You cannot delete a Tag Code using an Associate Data file upload.

Leaving this blank for a Tag Code line will not make any changes.

Assigned

Flex Alpha

Adding an ASSIGNED column will allow you to change the Assignment Status of the Tag Code. Suitable values are 'Assigned' and 'Unassigned'. If you Assign a Tag Code that has already been Assigned via an Associate Data file upload, the Assignment Date will not change.

Leaving this blank for a Tag Code line will not make any changes.

NFT

Flex Alpha

NFT data related to a Tag Code can also be uploaded. NFTCONTRACT, NFTTOKEN, and NFTCHAIN are required fields. You need to set all of these.

The possible options for NFTCHAIN are :

Adding an NFTOWNER is optional. See the NFT Integration documents for more information.

NFTMETA is currently in beta. Do not use this unless you are part of the NFT beta testing.

It's possible to add different combinations of the columns (only) as follows :

Uploading the data file

Navigate to the Batch screen, then the 'Associate' tab of the Batch Function panel. Select the file from your local computer and click associate tags.

Ixkio undertakes a large number of checks on the data so for a large file upload, it can take a number of seconds to complete.

Overview

Action Data is data related directly to Tag Data scans from an NFC tag or QR Code related to the specification or location of the scan device.

• OS - Android/iOS

• Browser

• Country

• Local Time Zone

• Local Currency

• Local Time (based on IP, not device)

This Data can be included in the Redirect responses using Subtags. Action Data is not available for API Responses.

Overview

Scan Assignment is used for moving and/or 'assigning' (changing the Assignment Status of a Tag Code to Assigned) Tag Codes. Your NFC tags will need to have been pre-encoded.

Scan Assignment works with our ixkio mobile phone app.

Typical Process

1. Set up a Batch to contain a generic 'pool' of Tag Codes

2. Encode the NFC tags with the URLs from this Batch

3. Place the NFC tags into any product or item

4. Set up a Batch for your product

5. Activate Scan Assignment on that Batch

6. Scan the NFC tags to Assign them from the pool to the product Batch

Overview

Main Menu > Control > Assignment

The Assignment Manager can be accessed via the main menu or, if a Scan Assignment is currently activated on a Batch, via the Assign Mode Activated tab on the top right of the Console.

The Assignment Manager provides a near realtime update of last assignments made throughout the Console. Additionally, you can view currently active Assignment Batches.

This screen can be particularly useful in multi-device environments where multiple devices can be used to simultaneously assign across different Batches.

Overview

For smaller configurations or where you don't want to use USB readers/writers, it's also possible to manually change a Tag Codes Assignment Status.

This can be either done on an individual Tag Code basis via the Console or in bulk via Associate Data.

Manual Console Assignment

Tag Code Screen > Tag Detail Panel > Settings Tab

Select your Tag Assignment Status from the dropdown and click on Update.

Tags that have been previously Assigned can be set back to Unassigned and then re-Assigned using the Standard (USB Device) Assignment process.

Setting up CodeLink

CodeLink is a flexible system. We will outline here the basics to getting started but if you want to modify the user experience or make further changes, then review the CodeLink Integration options.

There's three stages to setting up CodeLink :

• Create a CodeLink Code

• Enable CodeLink on your Tag Group

• Embed the CodeLink javascript in your page(s)

Create a CodeLink Code

CodeLink Codes manage the settings for the javascript that you will add to your landing page. You can set up multiple CodeLink Codes with different settings, but you need at least one.

Go to 'Control' on the main menu and select 'CodeLink'. On the bottom right, select 'Add CodeLink Code'.

The Add CodeLink Code screen will present you with options as follows :

CodeLink Settings

CodeLink Fail URL This is the URL page on your website that any failed CodeLink check will be sent to. If, for example, the user hasn't come from an ixkio redirect link - or the link is now too old - they will be redirected to this link. If you leave this blank, then notification of the fail will be displayed directly to the user on the landing page.

Default Display HTML The CodeLink system allows you to modify the user experience during the CodeLink process, but we can also serve some HTML directly to the page via the javascript. This will display a white screen while the CodeLink check is being made. In most cases, the check is so fast that this will never show, but if there is a delay (or you don't use a CodeLink Fail URL), then this is what the user will see.

If you don't use the Default Display HTML, then you should add your own HTML code.

Verification Text This is the text that the user will see while the CodeLink check is being made. Typically, this would be 'Authentication Check In Progress' or similar. However, you can include whatever text you prefer. HTML <br> line break syntax is allowed.

Verification Text Pause Allows you to add a small pause on the CodeLink check screen while displaying the first 'Verification Text' message. This can prevent a quick flash of the authentication checking screen.

Error Codes If enabled, this will add the reason for a CodeLink fail onto the CodeLink Fail URL as query string.

Escape Word & Tag Code Override (Only available on Edit after CodeLink Code created) This will prevent the CodeLink system from giving an error state if it detects the Escape Word in the URL (not in the query string). This is designed to allow pages to be used in a development environment but not trigger the CodeLink code. For example, you could add the word 'admin' to prevent CodeLink from working in Shopify's admin pages.

Tag Code Override can be used with the Escape Word to force ixkio to use the data from a specific Tag Code. This will ignore any key used (or lack of key). This is useful for testing NFT integration via CodeLink in a development environment. Needs to be a valid XUID.

Status Enables or disables (or deletes) this CodeLink Code. Even if the CodeLink code is inactive, the CodeLink code that you add to your website will still make a call to our servers. In some cases, if you have included the default display HTML, it will also still display the temporary blank screen and then immediately hide it. To completely disable the CodeLink code, you need to remove it from your website.

Create the Code

Click on Add to create your code. You can modify all these settings later as required.

Enable CodeLink

Tag Group > Tag Group Function Panel > CodeLink Tab

CodeLink is enabled at the Tag Group level (and by enabling your CodeLink Code).

Select Status as either Enabled or Disabled.

If CodeLink is On, then an additional unique key will be automatically added to your redirect URL. The parameter for this is ixr. For example, if your standard redirect URL was :

https://yourdomain.com/authsuccess

Then it will become (for example) :

https://yourdomain.com/authsuccess?ixr=e97f8xrvzbsw4by7

If you have other query string elements either as part of your link or dynamically added via Dynamic Response, then the CodeLink key will be added to the end of the query string.

Add the Javascript to your page

You need to add the following code to your authentication landing page :

<script defer src="https://t.ixkio.com/s/traceback.js?code=<yourcode>"></script>

Where <yourcode> will be replaced by the CodeLink Code you created in step 1. For example, if your CodeLink Code was dRzABK, then your javascript woudl be :

<script defer src="https://t.ixkio.com/s/traceback.js?code=dRzABK"></script>

You can add the code anywhere you choose, for example in the <head> section or before the end of the <body> section.

CodeLink Flow

The Process

CodeLink has the following flow :

1. User scans the NFC tag which directs them to ixkio

2. Ixkio handles the authentication check and redirects to your auth page. Ixkio will add a unique CodeLink Key into the URL.

3. Your page will load the CodeLink Javascript which will either :

   1. Display our Default Display HTML Overlay or

   2. Display your HTML

4. The CodeLink Javascript will then make a call to our server to verify the CodeLink Key. This will response either as :

   1. A pass, in which case :

      1. The CodeLink Javascript will simply close our Default Display Overlay or

      2. The script will hide your HTML and/or

      3. The script will trigger your javascript function

   2. A fail, in which case :

      1. The Trackback Javascript will display a fail message via our Default HTML Overlay or

      2. The script will redirect instantly to your CodeLink Fail URL or

      3. The script will trigger your javascript function

Why CodeLink might fail

1. If a user attempts to access your auth page directly without any CodeLink Key in which case it will trigger a 'No Key' error.

2. If a user attempts to re-use a link to your auth page with a CodeLink Key, in which case either :

   1. If the attempt is made quickly (but slower than a normal page hit), then it will trigger an 'Expired Key' error.

   2. If the attempt is made a substantial time later, then it will trigger an 'Key Not Found' error

3. If the user attempts to access the page with an incorrect CodeLink Key, then either:

   1. It will trigger a 'Key Not Found' error, if it looks like it might be a real key or

   2. It will trigger a 'Key Error' error.

The Display

If the Default Display HTML is selected, then ixkio will serve a few lines of HTML code along with the javascript.

This HTML code will attempt to display a full page white overlay onto your page and display the 'Authentication Text' (typically, Authentication Check In Progress). Under normal use - providing it's a valid attempt to view your page from a redirect - then this will only show for the briefest of moments and the overlay will be removed.

If the CodeLink check does not pass, then :

• If a CodeLink Fail URL has been entered in your settings, then the user will be redirected to this page

• If a CodeLink Fail URL has not been entered in your settings, then a message will be presented to the user (on the white overlay) of either :

  • No CodeLink Key (when no Key has been provided)

  • CodeLink Key Error (if the key is of the wrong format)

  • CodeLink Key Expired (if the key is too old to be used)

  • CodeLink Key Not Found (this can mean that the key is the right format but not correct or it can mean that the key was very old and has been removed from the ixkio platform)

Overview

Core Data is the most common information stored for each Tag Code. Three Core Data fields are always available and are created empty with each Tag Code. They can be left blank without data but the fields are always there and cannot be removed.

Core Data fields can be set either through the Console or in some cases via Locus. The data fields are then included in stats and encoding downloads for ease of identification and can also be displayed dynamically using Dynamic Response.

Tag Name

The Tag Name is typically used to identify Tag Codes.

For example, it might be a location identifier such as 'Main Lobby'. In some configurations you may choose to use the Tag Name field as a general identifier - such as your own Serial Number or Product Code.

Once set, the Tag Name is used to help identify the the Tag Code throughout the system and for stats downloads. You can search for the Tag Name and it's available for view throughout all Response Modes.

In many cases, it can be more useful to use the CUID as an identifier (such as your own Serial Number) rather than the Tag Name. This is because the CUID can also be used to make the request to ixkio.

Changing the Tag Name data

Tag Name data can be added and modified via Tag Data Panel > Core Tab on the Tag Code screen.

Once set, the Tag Name is then generally used throughout the interface instead of the Tag Code (XUID) for ease of reference.

UID

This is reserved for the use of the UID (unique ID) of the NFC chip associated with that Tag Code.

While this data can be added manually via the Tag Data Panel > Core Tab on the Tag Code screen, the UID data is typically added via an Association upload.

Under normal use cases, the UID would be added into the ixkio system during the encoding process carried out by us. However, it's not standard procedure and needs to be specifically requested.

Custom UID (CUID)

This is an additional Core Data field available for users typically wanting to add their own Tag Code identifiers - for example a unique Serial Number.

This can be set via the Core tab of the Tag Data panel on each Tag Code screen. Or more typically, the CUID is set from a Association upload.

The CUID should be alphanumeric only with no spaces. Maximum length of 24 characters.

The CUID must be unique throughout your Account.

Using the CUID in the link

Normally, the Tag Code is the reference when making a request to the ixkio platform. For example, for tags encoded directly to the ixkio platform, the link would contain only the XUID such as :

https://t.ixkio.com/xuid

However, it is also possible to use the CUID instead. In these instances, the customer AID (account ID) must also be included as your CUID may not be unique within the whole ixkio platform.

So, if your AID is 1E5241 and you have set your CUID to be a54857then the encoded link to the ixkio platform would be :

https://t.ixkio.com/t?c=a54857&a=1E5241

Association Uploads

In most cases it's not logical to enter UID or CUID data for a set of Tag Codes one by one through the Console.

A faster way is to use Tag Association by uploading a CSV file of your data directly into the ixkio platform.

Overview

Assignment is the process of 'activating' or 'deploying' an NFC tag either by scanning the tag or encoding the tag. In the majority of cases, Assignment would take place after the tags have been installed into your products, packaging or locations.

Assignment is typically one of three things :

1. Simply changing a Tag Code's Assignment Status so that you know that the Tag Code is in use. NFC Tags will be pre-encoded and the Assignment Status changed by a scan.

2. Encoding a blank NFC Tag directly from the ixkio platform.

3. Changing a Tag Code's location (ie, moving it from on Batch to another) by scanning a pre-encoded NFC tag using Scan Assignment.

All NFC tags on the ixkio platform have an Assignment status (assigned or unassigned) and an Assignment date.

Scan Assignment

This is where you will scan your already encoded NFC tags, typically after they have been installed into your products, to Assign or 'activate' them.

For example, you might have a large pool of tags (Tag Codes) which are in a Batch in your ixkio platform. Let's call this 'Holding Batch'. You might use these tags in any product at any time.

You then create a Batch for a particular product line. For example 'New 2023 T-Shirt'.

You can use any of the NFC tags from your large pool of 'Holding Batch' tags and place them inside your new t-shirts. But now you need to make sure you know which tags you have used.

This is Scan Assignment. You activate Scan Assignment within your 'New 2023 T-Shirt' Batch, scan the tags directly from the t-shirts, and ixkio will automatically move the tags from the 'Holding Batch' to the 'New 2023 T-Shirt' Batch.

Moved tags will automatically inherit any new Rules (eg, destination URL), Extended Data and other features from their new location.

Encoding Assignment

Encoding Assignment allows you to deploy NFC tags by encoding them directly using the ixkio mobile app.

In this instance, you would not have a pool of tags (as per the Scan Assignment). You would add non-encoded tags to your products first.

You would then create your Batch - for example 'New 2023 T-Shirt' - create a set of Tag Codes and from that Batch, activate 'Encoding Assignment'.

You would then scan each tag to encode.

Manual Assignment

For smaller configurations, it's also possible to simply change a Tag Code's Assignment Status one by one directly from the Console or in bulk via Associate Data.

Overview

For each Tag Code you have the option of creating up to five additional text or date data fields. These are called the Extended Data fields.

Extended Data fields can store tag specific data, such as 'Colour' or 'Size' which can be used to identify Tag Codes throughout the platform in stats and the Console. They can also be included in Redirect URLs, API Responses and the Direct Response page using Dynamic Response.

The Extended Data fields are created at the Folder level. Data for those fields can then be entered at the Tag Group or the Tag Code level.

If no data is entered at the Tag Code level, then the Tag Code will automatically inherit data for that Extended Data field from the Tag Group level. Entering data into an Extended Data field at the Tag Code level will override the default Tag Group level data.

Creating Extended Data Fields

Extended Data fields are created at the Active Folder level and are available to all Tag Groups, Batches and Tag Codes within that Folder.

Navigate to an Active Folder, then Folder Function Panel > Data Tab.

The first item is the 'Tag Name' which is a Core Data field not an Extended Data field. This cannot be removed.

To add the first Extended Data field, enter the name of the field (which can be edited later), select either a Text or Date data type and click 'Add'. Up to five of these Extended Data fields can be added.

Removing an Extended Data field

To remove an Extended Data field, navigate to the Active Folder level and then Folder Function Panel > Data Tab. Then click the 'x' button next to the Data field to be deleted.

Changing Extended Data Values

Once the Extended Data field has been created, data can be associated with that field at both the Tag Group and Tag Code levels.

Any data entered for an Extended Data field at the Tag Group level will automatically be inherited by any Tag Codes under that Tag Group. However, entering data for that Extended Data field at a Tag Code level will break the inherited link.

Setting the value at Tag Group level

Navigate to a Tag Group within the Active Folder where you have just set up your Extended Data fields. Then Tag Group Data Panel > Extended Tab.

This will list all the Extended Data fields that you have created at the Active Folder level.

Enter a value into the appropriate Extended Data field and click Update.

Setting the value at the Tag Code level

Navigate to a Tag Code within the Active Folder where you have just set up your Extended Data fields. Then Tag Data Panel > Extended Tab.

If you have set data for this Extended Data field at the Tag Group level, you will see 'inherited' next to the field name. To change the data for this Tag Code only, you can enter new data and click 'Update'.

If you want to revert back to the Tag Group 'default' data, then simply delete all data and click 'Update'.

Moving Tag Codes

One of the core functions of using Extended Data is that Tag Codes inherit any data for that field set at the Tag Group level. The data isn't set, it's just inherited (unless you set it specifically for a Tag Code).

This means that if you move a Tag Code to another Tag Group - in the Console or via Locus - then it will automatically inherit the Extended Data from the new Tag Group.

For example, you may have created an Extended Data field called 'Location'. Assume one Tag Group has default data for this field as 'Warehouse A' and another Tag Group in the same Active Folder has data for this for field as 'Warehouse B'. Moving a Tag Code from the first Tag Group to the second will change the Extended Data field for this Tag Code from Warehouse A to Warehouse B.

Viewing the Extended Data

Extended Data can be viewed at any time through the Console.

However, the real benefit is being able to add the Extended Data fields directly into the Responses using Dynamic Response.

In the example above, we moved a Tag Code from 'Warehouse A' to 'Warehouse B'. This information can then be dynamically included in URL link on the Response Mode, on a response page on Direct Response or even in the API with the API Response Mode.

The Tag Codes therefore have changing responses based on their location with your configuration. Moving a Tag Code automatically changes the Response.

Scan Assignment with the ixkio mobile app is quick and straightforward.

Create a Controlled User

If you are on the Flex plan, you will log in to the mobile app with your master login. On the Flex Pro and Flex Alpha plans, you can still do this - but we recommend setting up a Controlled User instead.

Create a generic Batch 'pool'

The point of assignment is to move tags from a generic pool of tags to a specific product. In this example, let's assume we've added pre-encoded NFC tags from the 'pool' to a new Blue T-Shirt.

We now want to scan those NFC tags to 'assign' them from the pool to a Batch on your system called 'Blue T-Shirt'.

For this demo - let's assume we already have these two Batches on ixkio and you have encoded the NFC tags from the 'Pool' Batch. (If you want to test this with unencoded tags, then follow the 'Encode Assignment' example).

Note that we have five Tag Codes in our Generic Pool and these are currently marked as 'unassigned'.

This is important - you can only assign unassigned tags. Once tags are assigned, you can only re-assign them by removing the assignment status (in the console). This is to prevent accidental tag movements.

Activate Scan Assignment on your Product Batch

Batch Screen > Batch Function Panel > Assignment Tab

What we are doing is telling ixkio where we want the Tags to move to when we assign them. Where the tags are before assignment isn't important.

In this example below, we are navigating to our Blue T-Shirt (where we want to move the tags to) and activating assignment to our 'Test User'.

Log into the ixkio App

Log into the ixkio app using your Test User (or the user you created for your app).

CodeLink works with most of the major website development platforms and can also be added to your custom design pages.

Follow these guides for your website platform:

Overview

For example, you could add a CUID (customer unique ID) stored in the ixkio platform dynamically onto a URL by including {CUID} within your redirect response.

So, if your CUID for Tag Code was 12345, a URL entered as :

would become :

Using Subtags

Subtags can generally be used anywhere you enter data. For example, you can include a Subtag into a URL Redirect, or a Tag Name, or even another Extended Data field !

At the point that ixkio presents that data, it will automatically substitute the content of the Subtag.

You can find which subtags can be used in which locations by reading the documents related to the element you are editing. However, example subtags include :

Subtags For Redirects

Subtags can be added directly to your Redirect URL (both the Default Response and any RuleGroup Responses). For example, if you wanted to add the scan count into your redirect URL, you would enter :

would become :

(Seritag.com is just being used as an example domain)

You can also use it directly into the URL. So, for example you could use a subtag to dynamically add a Custom ID (CUID) into a URL to change the page name. For example, assuming your CUID for a tag was 'beach' :

would become :

Subtags for API

Flex Pro Flex Alpha

Subtags in the Response

Subtags can be used with Ruleset API Responses - both the Default Response and with any RuleGroup Responses. For example, if you wanted to add the scan count into the API response, you can set the Ruleset API Response as :

would become :

(Assuming that your request was for Tag Code q8w3sbcz and the scan count was at 5)

Subtags in Extended Data

If you do not want to put Subtags into the Ruleset Responses or want data to be separated into other fields, it is possible to include Subtags within Extended Data fields.

Subtags for NFT

Flex Alpha

If you have entered complete NFT data for a Tag Code, it's possible to retrieve information regarding the NFT directly in the response using Subtags.

{nft_status}

This will check the NFT owner for the NFT as entered into ixkio against live NFT data on your chosen blockchain. If the owner as recorded in ixkio matches that on the NFT, then the subtag will be replace with either 'pass' or 'fail'.

{nft_xowner}

This will return the NFT owner as given by a live check on the NFT (not the owner as entered into ixkio).

{nft_owner}, {nft_chain},{nft_contract},{nft_token}

This will return the NFT data as set in ikxio.

{nft_meta}

If you are using Shopify with standard NFC tags (such as NTAG213 or iCODE SLIX) then the process is similar to authentication NFC tags. You can still :

• Dynamically pass and display data from ixkio to Shopify

• Protect the page so that it can only be viewed from ixkio

A note on Page Protection

CodeLink can help protect the page from views that haven't come from ixkio. This can be useful to prevent a view of the landing page if someone hasn't scanned your NFC tag. However, the page protection wouldn't stop someone sharing the link from the NFC tag itself. If you need full tag > page protection then you need to use authentication NFC tags.

Setting up CodeLink

First step is to set up CodeLink on Shopify and ixkio.

Install the Shopify CodeLink App

Search on shopify for the ixkio codelink App and install. Make sure you enable the theme extension on your page headers (follow the link in the blue setup box on the app).

Create a CodeLink code within ixkio

Navigate to Main Menu > Control > CodeLink.

Click 'Create New CodeLink Code'. For this example, we will just use CodeLink to transfer data from ixkio to Shopify. So, give the CodeLink a name (just used internally for your reference), change 'Default Display HTML' to 'Do Not Include' and leave everything else. Then click Add.

Now copy the new CodeLink Code (six alphanumeric digits) and paste this into the ixkio App on Shopify :

Adding CodeLink to Shopify Pages

Create the landing page

The next step is to add CodeLink to your Shopify Page. For this example, let's create a product landing page called 'product-page'. To start with, just add some simple text, perhaps like this :

Add CodeLink to the page

Now navigate to to the CodeLink app on Shopify and add this page. This will then add the CodeLink code specifically to that page. Note that CodeLink is only added to the pages you specify. Don't add CodeLink to your whole website - just the landing page from the tag scan.

Add the Redirect Link to your Tag Codes

Now we need to redirect our tags through to this page. In our example, our landing page is 'https://demo-ixkio-codelink.myshopify.com/pages/product-page'.

Within ixkio, we have created a Shopify Folder, a Shopify Tag Group, Batch and a Tag Code. Navigate to the Tag Group level and add the destination URL into the Rule Set Default URL and Save Changes :

This will redirect all scans on all tags within this Tag Group to this page.

Enable CodeLink for this Tag Group

CodeLink can be enabled and disabled for each Tag Group. In this same Tag Group, we want to enable CodeLink so navigate to Tag Group Function Panel > CodeLink Tab

Change Status to Enabled, Data Link to Core & Extended and leave NFT Data as off (if you are on Alpha plan).

The Data Link part is allowing Tag Code Core data (Tag Name, UID, CUID) and Extended Data (that you create) to be dynamically passed through to your Shopify landing page.

Test the Link

At this stage, we recommend testing the link. Dynamic data will not yet be displayed on your Shopify page but it's worth testing the link now. Navigate down to your Tag Code level (or create a Batch and Tag Code now under this Tag Group if you haven't already).

You can copy the link from the NFC Encoding URL and paste this directly into a Browser. This should automatically redirect through to your Shopify Product Page.

In the example below, we've got a Tag Code URL of 'https://t.ixkio.com/kerf5dda'.

Adding Dynamic Data to your Landing Page

Now we need to add dynamic data to your landing page. This will enable data stored in ixkio to be dynamically displayed on your Shopify Product Page.

Add Data to ixkio

In this simple example, we will use a 'CUID' (Customer Unique ID). Add an ID into your Tag Code for testing. We've used 'ID123457' :

Add Field onto your Shopify Page

Within Shopify, open your product page for editing. Add some additional text to indicate the Product ID, perhaps something like :

Now we need to edit the HTML code for this page to allow the dynamic entry of the data. Click on the <> button on the Content menu and add the code :

So the result looks like this :

And save.

What you are doing here is telling Shopify to add the 'CUID' from ixkio between the 'span'. This can be formatted however you like and you can also dynamically add links, images and more. For the moment, we'll just do simple text.

Test Link again

Now copy the Tag Code URL again into a browser and check that the data is being passed through correctly. If it's all working, then you should see :

Where the 'ID123457' is now being dynamically taken from the Tag Code and placed into the page.

And you are done !

Advanced Features

CodeLink is a powerful system and all Tag Code related data can be dynamically transferred via Core and Extended data fields (including Digital Product Passport Data, Scan Counts, Assignment Dates, System Data, Action Data, etc, etc).

The CodeLink system has been designed to allow flexibility in the integration with regards to how the process displays to your users. You can keep the default settings or you can modify in part or in full as follows :

1. The Default Display HTML

If you choose to include the Default Display HTML, then the CodeLink javascript code will attempt to display a solid white overlay with black text. You can change :

Verification Text In your CodeLink Code settings, you can modify the text that is displayed on the white overlay while the check is taking place. This field allows the <br> HTML line break for a little additional formatting.

Verification Text Pause This allows you to lengthen the time the Verification Text message is displayed.

2. Modifying the Default Display HTML

You can make changes to the Default Display HTML by adding your own CSS styles. The Default Display HTML consists of two DIV elements. An outer element that is displayed as the overlay with an ID of #ixtb-overlay and an inner DIV which displays the text with an ID of #ixtb-txt.

You may need to add !important to any CSS to ensure that it overwrites the Default Display HTML.

3. Replacing the Default Display HTML

You can replace the Default Display HTML completely. Change the settings for your CodeLink Code so that 'Default Display HTML' is not included.

You can now add your own code to provide the user experience that you prefer. In many cases you can provide the same overlay DIV but by coding this HTML yourself you can set it immediately to overlay your page - preventing any slight flicker as the page loads.

The CodeLink javascript will set the #ixtb-overlay to hidden when the check is complete and will also update the #ixtb-text with the relevant text.

If you have set the CodeLink Fail URL, then the CodeLink javascript will still redirect.

4. Full Replacement

The CodeLink javascript will also call a function during the process - on error and on pass. You can create your own javascript function to handle the display and user experience.

The function call is made to :

Where {data} is a javascript object containing the status. For most implementations not using NFT+, this will be similar to :

Note that no function call is made during the script load, only on the responses.

CodeLink Fail/Pass Codes

Depending on your configuration, CodeLink will send Fail/Pass codes either

• As a message directly to the user (Default HTML with no Fail URL) or

• Included in the Fail URL redirect (if you have selected 'Add Error Codes' in your settings) or

• As a parameter in the function call (if you are handling the display yourself).

These codes are :

Errors with Javascript Integration

If you have an error with your CodeLink javascript integration then we will display messages as alerts - ie, pop-ups onto your screen. These errors can be caused by :

• Not incuding your Tracebook Code in the javascript URL src

• Not using a valid Code in the javascript URL src

• Using a deleted Code

These alerts will only happen if there is a error with the CodeLink javascript line added to your page. Once set, your users would never see an alert.

Advanced Settings

It is also possible to set the Authentication Text directly into the javascript embed. We don't recommend doing this under normal use as it's easier to manage via the Console. However, if you need to display different messages, then this is an option.

Use data-text in the script source code.

For example :

This will overrule any settings made in your CodeLink Code console configuration.

During the configuration of the CodeLink system you may wish to check the different scenarios and how they present themselves. We recommend the following procedure :

Testing an Invalid Key

The CodeLink Keys are passed in the redirect from ixkio to your website using the query string parameter ixr, for example :

You can test for an invalid key scanning the tag so it lands on your auth page on your website. Now edit the URL so that you remove a character from the key, for example :

This will then register as an Invalid Key and you can test the response.

Testing for no Key

Once you have implemented the CodeLink setup, try to access your landing page without any key in the URL. So remove the ixr= and just enter the URL.

This will simulate someone trying to access your page directly.

Testing for a Re-used Key

Scan as you would normally to get the key pass response on your landing page. Now refresh the page directly in the browser.

If you refresh the page very quickly - within seconds - it should allow the key to pass. This is an important allowance as potential delays on the redirect between ixkio and your website caused by slow internet connections can create problems.

If you refresh the page after a number of seconds, you should get an expired code response.

If you wait a longer time (until the next day for example) and then refresh, you will see a no code found response.

Overview

CodeLink is a powerful system designed to :

1. Allow the dynamic passing of NFC Tag data from ixkio to your website.

2. Prevent direct page hits on your website authentication landing pages when using authentication NFC tags.

1. Data Link

Using CodeLink allows you to pass data stored in ixkio to your landing page to be dynamically displayed. If you are using Shopify, you can use the Shopify CodeLink app to simplify this process.

Ultimately, this allows you to create a single 'authenticated' or similar landing page on your website and then dynamically show information related to the product scanned.

2. Landing Page Protection

The problem

When using ixkio in Redirect Mode with authentication NFC tags, the user will scan the tag, arrive at ixkio - where we will do the authentication check and apply any Rules - and then immediately redirect the user to your website.

However, as the user is ultimately linked through to an authentication page on your website, it could be possible to copy that URL - the one on your site - directly onto a tag. In doing so, they would bypass the ixkio authentication and land directly on your 'authenticated' page. Anyone scanning the tag may not be aware of this.

The solution

With CodeLink, we provide you with a line of javascript code to add to your authentication landing page(s).

This code checks that the access to that page came from an immediate ixkio redirect. If it passes, then your authentication page will display. If it fails, then you can choose whether to display a message or redirect the user to a failed authentication page.

Using CodeLink

CodeLink is now available on all Flex plans for both standard and authentication tags.

It's a flexible system which is designed to allow easy plug and play, but can be modified easily to suit your design requirements as you prefer.

If you are using Wix with standard NFC tags (such as NTAG213 or iCODE SLIX) then the process is similar to authentication NFC tags. You can still :

• Dynamically pass and display data from ixkio to Wix

• Protect the page so that it can only be viewed from ixkio

A note on Page Protection

CodeLink can help protect the page from views that haven't come from ixkio. This can be useful to prevent a view of the landing page if someone hasn't scanned your NFC tag. However, the page protection wouldn't stop someone sharing the link from the NFC tag itself. If you need full tag > page protection then you need to use authentication NFC tags.

Setting up CodeLink

First step is to set up CodeLink on Wix and ixkio.

Create a CodeLink code within ixkio

Navigate to Main Menu > Control > CodeLink.

Click 'Create New CodeLink Code'.

For this example, we will just use CodeLink to transfer data from ixkio to Wix. So, give the CodeLink a name (just used internally for your reference), change 'Default Display HTML' to 'Do Not Include' and leave everything else. Then click Add.

Adding CodeLink to Wix Pages

Create the landing page

The next step is to add CodeLink to your Wix Page. For this example, let's create a product landing page called 'product-page'. To start with, just add some simple text, perhaps like this:

Add CodeLink to the page

Now navigate to the Setting page on your Wix dashboard and scroll down to custom code, in the advanced section.

From here click the 'Add Custom Code' button, and paste your JavaScript code from codelink into the space at the top. Choose a name e.g. Codelink, select the option marked 'Choose Specific Pages' and chose the page(s) you want to enable Codelink on. This will then add the CodeLink code specifically to that page. Note that CodeLink is only added to the pages you specify. Don't add CodeLink to your whole website - just the landing page from the tag scan. Select 'Head' as the codes location and keep Code Type as 'Essential'.

Add the Redirect Link to your Tag Codes

Now we need to redirect our tags through to this page. In our example, our landing page is 'https://demo-ixkio-codelink.wix.com/pages/product-page'.

Within ixkio, we have created a Wix Folder, a Wix Tag Group, Batch and a Tag Code. Navigate to the Tag Group level and add the destination URL into the Rule Set Default URL and Save Changes:

This will redirect all scans on all tags within this Tag Group to this page.

Enable CodeLink for this Tag Group

CodeLink can be enabled and disabled for each Tag Group. In this same Tag Group, we want to enable CodeLink so navigate to Tag Group Function Panel > CodeLink Tab

Change Status to Enabled, Data Link to Core & Extended and leave NFT Data as off (if you are on Alpha plan).

The Data Link part is allowing Tag Code Core data (Tag Name, UID, CUID) and Extended Data (that you create) to be dynamically passed through to your Wix landing page.

Test the Link

At this stage, we recommend testing the link. Dynamic data will not yet be displayed on your Wix page but it's worth testing the link now. Navigate down to your Tag Code level (or create a Batch and Tag Code now under this Tag Group if you haven't already).

You can copy the link from the NFC Encoding URL and paste this directly into a Browser. This should automatically redirect through to your Wix Product Page.

In the example below, we've got a Tag Code URL of 'https://t.ixkio.com/kerf5dda'.

Adding Dynamic Data to your Landing Page

Now we need to add dynamic data to your landing page. This will enable data stored in ixkio to be dynamically displayed on your Wix Product Page.

Add Data to ixkio

In this simple example, we will use a 'CUID' (Customer Unique ID). Add an ID into your Tag Code for testing. We've used 'ID123457' :

Add Field onto your WixPage

Within Wix, open your product page for editing. Add some additional text to indicate the Product ID, perhaps something like :

Now we need to edit the HTML code for this page to allow the dynamic entry of the data. Click on the <> button on the Content menu and add the code :

So the result looks like this :

And save.

What you are doing here is telling Wix to add the 'CUID' from ixkio between the 'span'. This can be formatted however you like and you can also dynamically add links, images and more. For the moment, we'll just do simple text.

Test Link again

Now copy the Tag Code URL again into a browser and check that the data is being passed through correctly. If it's all working, then you should see :

Where the 'ID123457' is now being dynamically taken from the Tag Code and placed into the page.

And you are done !

Advanced Features

CodeLink is a powerful system and all Tag Code related data can be dynamically transferred via Core and Extended data fields (including Digital Product Passport Data, Scan Counts, Assignment Dates, System Data, Action Data, etc, etc).

Ixkio can support multiple user logins. As with all ixkio features, it's a flexible system to allow for a range of use cases.

Users can be found under Management > Users

Basic Multiuser Concepts

Users

Account Master

Every account has an Account Master which is the primary user account and one which is created when the account is set up. This User cannot be removed.

Account Administrators

Account Admin users have the same full permissions over tag management as the Account Master. Each Account can have up to 5 Admin Users.

Controlled Users

Each Account can have up to 25 Controlled Users. Controlled Users must be members of a User Group. Depending on permissions, Controlled Users can access ixkio with a user/password login on the Console, with a user/password login on Locus or with an Authentication Card.

User Groups

Each Account can have to 5 User Groups. Each User Group has :

• Permission Settings Controls permission to either view, edit, edit & create or edit, create & delete (full control).

• Access Settings Controls access to the system by either Console & Locus or Locus only.

Access Cards (Beta)

Users can access either Locus or the Console by first scanning an Access Card instead of, or as well as, using a username and password. Access Cards are authentication grade (usually NTAG424) keyfobs or cards that can be provided associated with a Controlled User.

Setting Up Multiusers

Overview

The ixkio multiuser system allows access via both user sign-on and Access Cards. Because of this multi-access facility, management of users is slightly different.

One important aspect is that the only User that can set or change all passwords is the Account Master. Account Admin users can only change Controlled User passwords - they cannot change their own password or other Account Admin passwords.

If a Controlled User loses or wishes to change their password, then they must do so via the Account Master or an Account Admin. If an Account Admin User wishes to change their password, then they must do so via the Account Master only.

Account Admin Users

Admin Users have the same complete level of access and control over Tag Management as the Account Master. However, Admin Users have different rights over Users :

Admin Users cannot

• Create or delete other Admin User accounts

• Change the Account Master or other Admin Users login/passwords

• Change the status of other Account Admin Users

Admin Users can

• Create new User Groups

• Edit User Groups

• Add, remove or modify Controlled Users

• Change login/passwords on any Controlled Users

• Change the status of Controlled Users

Creating Admin Users

To create an Admin User, navigate to Account Management on the main menu, then Users. Click 'Add User' to access the 'Add User' screen. The settings :

User's Name For your internal use only. This will allow you to manage users but is also the name that will appear on Event logs so that you can monitor which users have made changes.

User's Type Admin or Controlled > Set to Admin

Login Name / Email Users cannot reset their own passwords so there's no requirement to use an email address - but it can be if you feel it easier to manage.

Password As always, ensure you use the most secure password you can.

Managing Admin Users

Status You can Deactivate or Delete an account from the status dropdown.

Creating Controlled Users (User Groups)

Controlled Users

Controlled Users have an adjustable amount of access and control over the Account.

Each Controlled User must be a member of a User Group, therefore you need to create a User Group first and then create a Controlled User.

Create a User Group

Navigate to Account Management on the main menu, then 'User Groups'. Click 'Add User Group' to launch the Add User screen. You can edit your User Group at any time.

User Group Name For your internal use only. This will allow you to manage users but is also the name that will appear on Event logs so that you can monitor which users have made changes.

Access This controls whether the user has access to both the Console and App, or just App.

Check Function This controls whether the user has access to the Check Function in the ixkio mobile app.

Locus This controls whether the user has access to the Locus tool suite in the ixkio mobile app.

Console Permissions Controls the amount of access the user will have. Full permission includes the ability to delete elements. Edit Data only allows the user to change element data such as a Tag Name, CUID or Extended Data data. Edit All allows the user to change the names of the elements themselves as well as settings such as Rules.

Console Permission Level This changes the level to which the user has permission. For example, users with Tag Group level permission can make changes (as authorised by their Group Permissions) at the Tag Group, Batch and Tag Code levels. Whereas, a user with Tag Code level permissions can only make changes at the Tag Code level.

Status You can Deactivate or Delete an account from the status dropdown.

Creating Controlled Users

Once you have created a User Group, you can create a Controlled User. Navigate to Account Management on the main menu, then Users. Click 'Add User' to access the 'Add User' screen. The settings :

User's Name For your internal use only.

User's Type Admin or Controlled > Set to Controlled

User Group The User Group to which this User should belong. You can edit a User at any time and transfer them to another User Group.

Login Name / Email Users cannot reset their own passwords so there's no requirement to use an email address - but it can be if you feel it easier to manage.

Password As always, ensure you use the most secure password you can. Account Masters or Account Admins will need to provide passwords to Controlled Users. The ixkio platform will not email or provide it to them automatically.

Managing Controlled Users

Status You can Deactivate or Delete an account from the status dropdown.

Managing Users

Once a user has been created, Account Masters can change all users passwords, user groups and status. Account Admins can change all Controlled Users passwords, user groups and status.

Changing Status

It's possible to change the Status of any single user or a User Group. The 'inactive' status will prevent any user login. If you change a User or User Group status to inactive while the User is logged in, they will instantly be restricted from any further actions.

Deleting Users

You can delete a User by changing their status to 'Delete' from their User Details screen (navigate to Account Management on the main menu, then 'Users', then click on the User's Name). You will be prompted to confirm and then you can delete.

Deleting User Groups

To delete a User Group, you must first delete all Users within that Group. Then change the status to 'Delete' and confirm.

Additional Notes

Logout Period

The logout period is set in hours. However, the actual hours for 1 day is 22 hours and the actual hours for 5 days is 110 hours.

This is so that a user effectively being asked to log in each day wouldn't accidently pick up the last minutes of the previous day if the log in time was slightly different.

The 5 day period assumes a Monday morning log in which would last until late on Friday. Therefore, the hours are less than a full 5 x 24 hour period.

Statistics can be downloaded at the Active Folder, Tag Group, Batch and the individual Tag level. Navigate to your chosen level e.g. Folder Data / Tag Group Data / Batch Data / Tag Data Panel > Stats Tab.

From here, select a date or a range of dates you're wanting to download. Then select Download Stats. This download will be in a CSV file.

CSV Download

Statistics include:

Introduction

The SmartAccess system is an easy to use way to control the way a tag will Respond on either the Direct or Redirect Response Modes.

SmartAccess is a registration free system and is designed for store, warehouse or supply chain users who need to access product information on NFC tags that shouldn't be available via non-authorised scans.

SmartAccess uses the Rules system to control what Response is provided.

SmartAccess is an option Module that can be activated via Main Menu > Admin > Plan Details.

Setting up SmartAccess

The ixkio mobile app is available for Android and iPhone.

Access to the mobile app is only available with a user account. On Flex accounts, this is always the master user. On Flex Pro and Flex Alpha, you can create additional app only users with specific permissions.

This full featured app provides four core features :

Encode

You can encode NFC tags with Tag Codes created within the ixkio console. The encoding system is designed for large scale deployment and can handle multiple users encoding Tag Codes from different Batches at the same time.

The ixkio mobile app can encode both standard tags such as NTAG213 or iCODE SLIX, and also the NTAG424 authentication NFC tags.

Additionally, the app can encode using Custom Domains in Redirect Mode or customer based URL in API response mode.

The Android version allows for 'continuous encode' for even faster encoding and tag deployment.

Assignment

The ixkio app allows for fast assignment of NFC tags for both small scale and large scale deployments.

Features include multiple users, continuous assignment (Android) and 'switch', which allows the dynamic change of assignment batch using a built-in QR code scanner.

Check

The check feature allows app users to check the status of the NFC tag including it's current Batch, Tag Group, Tag Name and - if using authentication tags - an authentication check.

Locus

Locus is a powerful and flexible system which allows the update of Tag data from the app. If enabled within the Console, a tag scan will then allow a change of data including both Core and Extended data fields.

Locus also provides the ability to associate an NFC tag with QR code data using the built in scanner.

Overview

For Redirect and Direct Response users, the usual domain name encoded onto the tags is the ixkio tag management URL : https://t.ixkio.com.

However, on all our Flex Direct and Flex Redirect plans, you can also use your own domain and map this to ours.

You need to create a CNAME on your domain, for example 'auth.yourdomain.com' or 'tap.yourdomain.com' which maps/points to https://t.ixkio.com. You can do this through the company that hosts your company domain.

We recommend speaking to your domain holding/hosting company if you need advice on setting this up.

Once the CNAME has been set, contact us via email at mail@ixkio.com for us to configure this on your Account.

Ixkio will create an SSL certificate for you free of charge for your domain on our platform.

Using a Custom Domain with API

You cannot currently use a Custom Domain for accessing either the Response API or the Management API.

In both these cases, your end user would not be aware of the ixkio domain in any event so it's highly unlikely that API Mode users would need or require a Custom Domain.

If you are using the ixkio API Response mode for authentication, it's still possible to use the ixkio mobile app to encode your NTAG424 tags.

In this case, the tags will be encoded with your domain name to go to your server first. However, the keys will still be loaded into the ixkio platform against each tag.

Setting the Encode Domain

Main Menu > Management > Advanced Settings > API Encoding Settings Panel

This field uses the subtags system to dynamically substitute tag data during encoding as follow :

CUID

The CUID Core Data field must be set on your console for each tag before you encode your tags. Encoding with the {cuid} subtag will take your Tag CUID and encode it permanently onto each tag. It's important to understand that if you then change the CUID in the console, the Tag encoding CUID will not dynamically change.

Encoding your Tags

You can now encode your Tags in the usual way with the App. Simply, create 'unencoded' Tag Codes within a Batch, enabled encoding from the 'Encode' Tab of the Batch Function panel. Tap the Encode Function on the App and encode.

Your NTAG424 Tag will be encoded with your URL, the encryption key will be automatically generated and stored against your Tag Code.

Example

Assume that your landing page URL is :

https://authnfc.com/auth?tagid=abcd1234&count=000001&code=abcd1234abcd1234

Where you are taking the parameters of the tagid (in this case the xuid from ixkio), the count and the code to pass to our authentication API. You would enter into the console :

https://authnfc.com/auth?tagid={xuid}&count={count}&code={code}

These Management API documents details how to use the ixkio API to change Tag Code Status, Assignment, NFT Data and Default Response.

Using Management API

The Management API system can currently be used to remotely modify a Tag Code's status and/or a Tag Code's Default Response. The Tag Code must have already been created in the Console.

Tag Code Status for any of the Response Modes (Redirect, API or Direct Response) can be changed to either Active or Inactive. Default Response can be modified for either the Redirect or API Response Modes.

Accessing the Management API

The ixkio API Management endpoint is located at :

PATCH https://api.ixkio.com/v1

You can access the Tag Code by using either the XUID or your AID along with a CUID or UID of the Tag Code with a PATCH request as follows :

XUID

Example : PATCH https://api.ixkio.com/v1/x/{xuid}

CUID or UID

Example : PATCH https://api.ixkio.com/v1/a/{aid}

along with your CUID or UID in the PATCH request HEADERS, for example :

ix_c: {cuid}

or

ix_u: {uid}

Parameters

The management API accepts the following parameters :

ix_dr

Options : URL (redirect mode), Response (API mode) or empty.

Action : Updates the Default Response for a Tag Code. If Tag Code is inheriting Response from the Tag Group, it will break the link and set the Response. If the parameter is empty, it will remove the Response and Revert the Ruleset to the Tag Group level.

Example 1 :

'ix_dr' => ''

This will remove any Tag Code response and Revert the Ruleset to the Tag Group level.

Example 2 :

'ix_dr' => 'https://seritag.com'

This will set the Response for the Tag Code to https://seritag.com

ix_status

Options : Active, Inactive

Action : Will change the Status of the Tag Code to either Active or Inactive.

ix_assigned

Options : Assigned, Unassigned

Action : Will change the Status of the Tag Code to Assigned or Unassigned. If set to Assigned, the Assigned Date field will be updated.

ix_cuid

Options: Unique CUID appropriate data

Action: Will update the CUID of the Tag Code to the sent value.

API Response

The API will respond 200 OK with either the following JSON :

{
    "xuid":"<<yourxuid>>",
    "status":"success"
}

or an error message in the format :

{
    "xuid":"<<yourxuid>>",
    "status":"error",
    "error":
    {
        "type":"MgmtAPIError",
        "message":"Invalid Status",
        "code":"e44328",
        "detail":""
    }
}

Additional Tag Codes

If you're reaching your limit for Tag Codes, additional Tag Code packages can be added to your monthly/annual Flex or Flex Pro Plan at any time.

There a multiple packages to choose, from 5,000 to 250,000 additional Tag Codes per month.

Click here to view our additional Tag Code prices.

Contact us to discuss.

Additional Tag Scans

Ixkio offer a fair use policy on tag scans. We appreciate that campaign launches can cause month by month fluctuations in the number of scans required. Therefore, we allow a 300% overage in any single month on scans.

However, any consistent overage on a month by month basis will require purchase of either a High Usage or Enterprise Usage upgrade. These are only available on the Flex or Flex Pro plans.

Contact us to discuss.

Remove Tag Codes

If you have purchased additional Tag Codes and no longer need them, simply delete the codes you no longer need. Once you've removed the additional Tag Codes to the amount that you want, contact us and we will amend your monthly/annual pricing.

Current Plan Details

Main Menu > Admin > Plan Details

Screen will display your current plan and subscription (annual or monthly) along with the next renewal date of your subscription.

The Plan Allowances displays the number of Tag Codes included with your plan and the number of monthly allowed Tag Events (scans + API calls).

Changing Plans

You can usually upgrade from Flex or Flex Pro to Flex Pro or Flex Alpha. Contact us with your account details and we will check the settings on your account to confirm.

In some cases it is also possible to downgrade from Alpha or Pro. However, some Tag Code settings may need to be modified. Contact us for confirmation.

Current Usage

Main Menu > Admin > Current Usage

Screen displays your current Tag Code usage and current Monthly Tag Events (scans + API calls).

To increase your Tag Event allowance, we can offer High Volume and Enterprise upgrades. Please contact us for more information.

Overview

Ixkio uses a third party payment processor called Paddle for subscription billing to save us from the complexity of international tax. Paddle should provide the invoices/receipts for your payment directly.

If you have any problems with payment or receipts, please contact us first and we can solve your problems. Contacting Paddle can result in delays as they will contact us.

FAQ

Can I pay by bank transfer?

Yes. However, do not open an account via ixkio.com. Contact us and we will open and process the account for you.

If you are based in the UK, we can invoice you directly and you can pay by bank transfer direct to us.

If you are based outside the UK, we will invoice you through our payment processor - Paddle. You can still pay by bank transfer in either GBP, USD or EURO but payments will be made to Paddle rather than to us.

How do I access my invoices?

For customers on regular subscription, you can access your invoices through Paddle.

If you paid through Seritag and are in the UK, then we will have sent you an invoice on payment. If you need a copy, just contact us.

How can I upgrade my subscription?

To upgrade your subscription, give us a call or email us and we can talk you through your options. Contact us here.

How do I cancel my subscription?

Just drop us an email or give us a call. We will usually quickly verify your request but don't worry - we aren't going to mess you about and hassle you to stay.

We have many clients who use the platform for short periods for events, trade shows, festivals, etc. Your subscription can be cancelled at any time so it's no problem if you use the account for a short period and need to close it. Clearly, we always hope to see you back again !

User Privacy

Account Holder Privacy

Ixkio will set a cookie for the purposes of managing account access when you log in. It is only used for this purpose and you can safely delete this cookie when not using the console or Locus.

We only store user information related to the Account holder for the purposes of account management such as billing and account maintenance. We will not contact you for marketing, promotion or similar reasons and your email will not be transferred outside our company (unless we are legally required to do so).

Any information entered regarding other users in a multiuser configuration is treated the same way.

Third Party Tag Scan Users

Ixkio do not set cookies or store any personally identifiable information for non-account users scanning any tags, QR codes or links directly linked to the ixkio platform.

Where we provide information such as geo data, we do so only at a generic level (such as a country) and the IP address or other information on which we base this data is not stored anywhere on our systems in association with either the Tag Code or the Account.

We may store IP data across the whole system in general but only for the purposes of system/server/network security. Any storage is completely anonymous and not related in any way to any specific event, account, tag, QR code or user.

Timezone

Main Menu > Management > General Settings > Account Settings Panel

By default, the timezone will be set on UTC (Coordinated Universal Time), which is the same as GMT. However, you can change the timezone to your region here.

Any change to the time zone on this setting will apply to all previous dates stored (tags scans, created dates, etc) as well as all future dates and times.

Account ID

Main Menu > Management > General Settings > Account Information Panel

The Account ID (AID) can be used in requests alongside a Tag Code UID or your CUID.

Navigate to the Main Menu, Click the Account Management drop down then click Account Settings. Your Account ID will be in the Account Information panel.

Clusters are used to classify and filter Batches in larger configurations. Clusters are created at the Tag Group level and can then be applied to Batches either when the Batch is created or later.

Creating Clusters

Navigate to your chosen Tag Group and then Tag Group Function Panel > Clusters Tab. Enter the name for your Cluster and click on Add. Each Tag Group can have up to 25 Clusters. Clusters are not shared between other Tag Groups.

Applying Clusters

When creating Batches

Once a Cluster has been created, it will be available as an option when created a Batch via the Tag Group Function Panel > Add Batch Tab. You don't need to select a Cluster and you can change or remove the Cluster after the Batch has been created.

Within a Batch

You can set or remove a Cluster from within a Batch by navigating to Batch Data Panel > Cluster Tab.

Filtering by Cluster

On the Tag Group screen, once a Cluster has been created, an additional column will be visible on the Batches table within the Batch Panel. Additionally, a drop down allows you to filter by Cluster

Cluster Subtags

The Cluster associated with a Tag Code (via the Batch) can be displayed dynamically within a Redirect, via the API Response or via CodeLink using the subtag - {cluster}. More information on creating dynamic links using subtags.

Using Clusters

The purpose of using Clusters is to help organise structures with larger numbers of Batches. You can use Clusters however you choose. However, if you are using Clusters to help track the release of multiple Batches of tags, there's two approaches for this :

Using Clusters as Product definitions

Consider a scenario for a Product hierarchy where you have, say 'Jeans' as an Active Folder, 'Style A' as your Tag Group and then multiple colours of Style A.

You might choose to create a separate Batch for each colour of Style A so that you can organise the Tags. You can then use Clusters to define each colour and the Batch Name to define the Batch release (assuming that you might create more than one release of tags).

In this way, you can dynamically include the colour on the API/Redirect/CodeLink.

Using Clusters as Release definitions

Alternatively, using the same scenarion as described above, you may choose to define the Batch Name as the colour and then use Clusters as - for example - the Release. So if you issue two sets of tags for a particular colour then you can use Cluster to define Release 1 and Release 2 so you can track which tags were sent out when.

Which works best ?

In the experience we have had with customers to date, we would recommend using the Cluster as the Release definition.

Cluster Groups

We are currently Beta testing with a limited number of clients Cluster Groups. Cluster Groups allows you to define up to 5 different sets of Clusters (rather than current one). In this way, you can define Batches in more granular detail such as 'size', 'leg length', etc.

Cluster Groups will to go to full release in May 2025.

The check feature allows app users to check the status of the NFC tag including it's current Batch, Tag Group, Tag Name and - if using authentication tags - an authentication check.

Many of ixkio's customisable elements can be found as Modules within your Trial or Full account.

All available modules are found under Admin > Plan Details

Adding new modules

Select the modules you wish to add using the tick boxes next to each module. As you make your decision you will see your new pricing update at the bottom of the screen.

Once you have made your decision, select Update Modules to complete the process and access your new features.

Trial Account

You are free to access additional modules during your trial period and to explore whether they are right for your full account.

Removing existing modules

Modules can be removed by deselecting and then updating your plan details.

You can encode NFC tags with Tag Codes created within the ixkio console. The encoding system is designed for large scale deployment and can handle multiple users encoding Tag Codes from different Batches at the same time.

The ixkio mobile app can encode both standard tags such as NTAG213 or iCODE SLIX, and also the NTAG424 authentication NFC tags.

Additionally, the app can encode using Custom Domains in Redirect Mode or customer based URL in API response mode.

The Android version allows for 'continuous encode' for even faster encoding and tag deployment.

Changing User Settings

Main Menu > Admin > Your Settings

Edit you User Name or login email and click 'Update'.

The User Name is only used internally on your account and setting this can be useful if you decide to go to a multiuser config in the future as it will appear in the event logs.

Changing Password

Main Menu > Admin > Password

Enter your current password and enter your new password twice to change. As with all passwords, we strongly recommend using a long, mixed letter/number combination for maximum security.

There are two different counting methods within the ixkio platform : Chip Count and Scan Count. By default, only the Scan Count is displayed on the interface.

Scan Count

This is the count of the number of times that the ixkio software has responded to a request. So, simply, the number of times the software has redirected a tag scan or has responded via the API.

Chip Count (previously called Tag Count)

This is the count of the number of scans as recorded on the NFC chip itself.

Many NFC chips, such as the NTAG213, have the ability to store the number of times the chip/tag has been scanned. This count can be dynamically added to the URL on the chip as the tag is scanned. This is a special feature that needs to be enabled when the tags are encoded and cannot be added later.

For ixkio to be able to record this count, this feature must be enabled on the chip during encoding and then passed to the ixkio software using the query parameter 'n', for example :

If you are using Authentication Tags then the Chip Count will be enabled by default.

Why the Counts can be different

The Counts aren't always the same - this is normal.

Chip Count is greater than the Scan Count

Every time the chip/tag is scanned, the chip counter will increase. In some cases, such as an iPhone scan, a notification will pop up on the screen after scan. If the user doesn't tap this notification and cancels - or perhaps doesn't have internet connection - then the scan won't reach our servers.

Our servers will not update at this stage as they won't know about the scan. However, on the next successful tag scan, our servers will record the Chip Count (which will now be, for example, 2) but will only have made a single response. Therefore, the Chip Count will be 2 and the Scan Count only 1.

Scan Count is greater than the Chip Count

This can often happen if a user revisits a URL scanned from a tag - without actually scanning the tag. It can also happen in cases where QR Codes are being used on the same Tag Codes as NFC tags.

Why Chip Count is hidden

In the substantial majority of standard tag (not authentication tag) use cases, the Chip Count is not enabled and not used. To keep the interface as clear as possible, the Chip Count is hidden unless it is required.