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

and Active Folders, which contain important settings like the Response Mode and act as the top of the organisational tree for managing your tags.

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

Ixkio supports both Redirect (dynamic links) and Direct Response for your NFC tags:

Redirect

When tapped, your tags will link to the ixkio management system and then instantly redirect to your destination page. You can then change this destination whenever you like or create automated rules to change the destination based on a wide range of criteria (such as number of scans, phone type, etc)

Direct Response

When tapped, your tags will link to the ixkio management system and we serve a landing page directly to the user. You can use our page builder to actively create pages on the fly containing unique product or other data.

Dynamic

You can also create a combination of the two. For example, authorised users might see a Direct Response page with product manufacturing data, then regular users will be Redirected to your product website.

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

The Basics

Ixkio is designed to allow the management of large scale tag deployments - but can easily be used to manage just a handful of tags.

This is how tags are organised :

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

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 (Redirect, Direct or Dynamic).

• Active Folders cannot be inside another Active Folder.

• Extended Data (for example, product data such as colour, size, etc) 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/Tags at the Tag Group level.

• Extended Data 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.

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.

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

You can encode a Tag Code onto as many NFC tags as you want but they will be managed the same way. If you want to manage each single NFC tag on it's own, encode a unique Tag Code on each one.

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 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 recommend using Batches for each set of tags you release.

Ixkio no longer provide an off-the-shelf API Authentication plan. Ixkio will continue to support Flex API users and can provide support and advice.

If you are interested in using Ixkio as a backend authentication system for your NTAG424 tags via API, then please contact us and we can discuss bespoke options.

These API response mode help pages are here to assist our legacy API plan users.

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.

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 .

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 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.

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.

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

Overview

Tag Group settings will be dependent on the selected and other settings.

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. Small projects may only need a single Tag Group. TapStart accounts have just one Tag Group.

Important Tag Group settings :

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

Overview

At least one Active Folder is required. Active Folders have important settings but are also used to manage structures.

Important Active Folder settings :

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:

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

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 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.

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 .

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.

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.

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.

Typically this data can be included with the response using Dynamic Response Subtags.

• Batch Name

• Tag Group Name

• Chip Count (if enabled)

• Scan Count

• Date Created

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:

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.

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 instantly redirect to your destination web page. 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

allow tag scans to be redirected via ixkio to your website/page based on criteria that you decide such as number of scans.

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.

Subtags & Datamerge

Ixkio allows the active creation of redirect links using system data. You can construct entire URL using data dependent on the user, system or location of the tag within the ixkio structure.

Subtags allows data to be included within the URL. Datamerge allows data to be included onto the URL.

For example :

Subtags

Let's say you have a tag in a Batch called 'blue'. You create a rule with the URL : https://authnfc.com/t-shirts/{batch}

When the tags is scanned, the Batch name 'blue' is actively included into the URL to create :

https://authnfc.com/t-shirts/blue

There's a large list of available subtags which allow you to create complex and powerful active links - either for changing landing pages or for website/Google analytics.

.

Datamerge

Datamerge allows you to append data to the end of a URL. Let's say you have a URL such as :

https://authnfc.com/t-shirts/blue

When the tags is scanned, datamerge can add data onto the end as a query string, such as :

https://authnfc.com/t-shirts/blue?size=medium

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

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

This will then identify the Tag Code within the platform.

Encoding multiple NFC Tags with one XUID

In many use cases, a single Tag Code would be encoded onto a single NFC Tag allowing for full control over each and 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.

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 :

or

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 'Form'.

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

on the QR Code and use :

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.

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

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 :

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 at the Tag Group Rule level.

Introduction

The SmartAccess system is a powerful way to allow different users to see different content when scanning the same NFC tag.

For example, authorised users might be presented with a page containing product information, service history or similar. Regular users might see your marketing page from your website.

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

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

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.

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 .

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 .

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 !

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).

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.

For example, if you store a serial number for your product on a Tag Code as your , then this data can be dynamically passed via CodeLink and then displayed on your page.

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.

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 using the subtag - {cluster}.

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.

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.

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.

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

New Active Folders

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

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.

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.

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.

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.

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

Changing User Settings

Main Menu > Admin > Your Settings

Meta Data is additional data or information associated with a Tag Code.

This might be directly associated with a specific Tag Code, or it might be inherited data from the Batch, Tag Group or Folder the Tag Code is in.

There are four types of Meta Data: Core, Extended, System and Action.

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 2 Extended Data fields can be created with Flex plans, but more can be added using the Extended Data Module.

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

• Batch Code

• Tag Group Name

• Chip Count (if enabled)

Action Data

Action Data is typically transient data associated with a Tag Code at the point of scan. This data is available to be included using . This data is also typically stored with Scan data and is available in stats.

• OS - android/iOS

• Browser

• Country

• Time Zone

Overview

Datamerge adds Meta Data onto the Redirect Response.

Let's say you have a URL such as :

https://authnfc.com/t-shirts/blue

When the tags is scanned, datamerge can add data onto the end as a query string, such as :

https://authnfc.com/t-shirts/blue?size=medium

Extended Data is additional data that you have added into ixkio related to your Tag Group or individual Tag Code. You need to create the data fields themselves at the Active Folder level and then set the data for those fields at the Tag Group or Tag Code level. You can find out more about .

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.

For example, assume you had created an field 'Colour' and have set the value of this at the Tag Group (or Tag Data) level as 'Blue'.

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 :

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 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 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.

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.

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.

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

• API responses can also include information

• All API requests must be on https

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

Preparing the data file

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 Subtags or Datamerge.

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

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 .

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.

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).

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.

Rules

The selection of will vary depending on your tag type (authentication or standard) and your plan (some Rules are not available on the TapStart plan). The most common are :

• 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.

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.

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

What is a Response Mode ?

Ixkio has two Response modes : Redirect and Direct Response.

With the Redirect response mode (often called dynamic links), users scanning your tag are redirected to another page - usually your website. With Direct Response mode, users scanning your tag will see a page created by ixkio.

You can create advanced rules (if you want) to allow some users to be redirected and some to see direct response pages.

All our plans offer both Redirect and Direct Response.

The Response Mode is set at the Active Folder level - you can choose from Redirect (all tags in that folder will be Redirect), Direct Response (all tags will have a page displayed by ixkio) or Dynamic (all tags can be configured with rules so tags can do either).

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.

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 :

(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 :

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 :

If the authentication fails, the response would be :

An error in the request would be, for example :

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 :

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 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.

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.

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 (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.

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 :

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 options.

There's three stages to setting up CodeLink :

• Create a CodeLink Code

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 :

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

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 :

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

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.

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

Multiuser features are available as a Module which can be purchased from within your account or trialled before you purchase a full account.

Users can be found under Management > Users

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.

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.

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.

Overview

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

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 :

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 for a Tag Code can be edited directly here. The Core Data include the Tag Name, the chip UID and your CUID (customer unique ID). All of these are optional.

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 have created any fields, then data for them can be entered directly for each Tag Code. If default data for an Extended Data field is entered at the Tag Group level, it will display here with an 'inherited' notice.

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.

NFT settings can also be set via and file upload.

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