Impinj R700 Reader Setup

This guide explains how to add an Impinj R700 reader to Tagnet as a cloud-managed device and configure the reader's IoT Connector to post tag data to Tagnet. You create it in Tagnet, copy the generated ingest URL and credentials into the reader's web UI, and tag reads begin flowing into the scan-event pipeline.

Part of: Cloud Reader Setup — Impinj-specific workflow.

Looking for local management instead? If Tagnet can reach this reader directly on your network, it can manage the reader for you: deploying its read configuration, and starting, stopping, and rebooting it on demand, with no manual reader-side setup. See Impinj R700 Local Management. A cloud-managed reader set up with this guide can be converted to local management later without losing its history.

What's in scope for this guide

• Creating a cloud-managed R700 device in Tagnet
• Copying the ingest URL + HTTP Basic credentials into the reader's IoT Connector
• Verifying that tag reads and heartbeats are arriving

Because Tagnet can't reach a cloud-managed reader directly, reader-side configuration (antenna selection, power, read settings) stays on the reader and is managed through its own web UI, using the Profile Presets menu covered in Step 3 below.

Prerequisites

• Tagnet access with Contributor or Admin role
• Access to the R700's web UI and admin login
• The reader's hostname (e.g. impinj-14-54-b1); this is used to verify incoming data

Finding the hostname: log into the reader's web UI. The default hostname is impinj-XX-XX-XX, where the XXs are the last three octets of the MAC address. Operators can customize it on the reader.

Step 1: Add the reader in Tagnet

1. Navigate to Devices in the main menu
2. Open the Add menu and choose Device
3. Choose Cloud managed

This opens a single form page, not a multi-step wizard. If your organization has more than one site scope, an Availability section leads the form; choose the site that will own the reader, which decides which device types and groups the rest of the form offers. Single-site deployments skip this and route the reader there automatically.

• Basics: Name (a descriptive name for this reader) and Reader model (select Impinj R700)
• Connection: Hostname (required for an R700; enter it exactly, max 63 characters, unique across your R700 readers) and MAC address
• Reader configuration: no options apply to an R700 today; this section shows an informational note instead of fields
• Organization: optional Device type and Device group

4. Click Create reader at the bottom of the page.

Once created, the page switches to show the Ingest Endpoint and credential values you need in Step 2. Keep this page open; you'll copy from it into the reader's web UI.

Finding credentials later: navigate to Devices, open the reader, and go to the Connection info tab.

Step 2: Configure the IoT Connector on the reader

1. Open a browser to the R700's web UI and sign in. The default login is root/impinj.
2. If this is a new reader, be sure to set the Operating Region by using the Change Region button. Choose FCC Part 15.247 for US and Canada. Reboot the reader for the change to take effect.
3. On the home page, also verify that the RFID Interface is set to Impinj IoT Device Interface. If the reader is configured for LLRP Interface, use the Change Interface button to switch to IoT.
4. Navigate to Event Reporting → Webhook.
5. In the Webhook configuration tab, modify the following settings:
   • Enable Webhook Output: check this box to enable the webhook integration.
   • Server URL: copy from Tagnet's Connection info → Endpoint → Endpoint URL
   • Port: leave blank
   • Verify TLS: enable only if the Tagnet server presents a TLS certificate the reader can validate, such as a publicly trusted certificate on a cloud-hosted Tagnet. Leave it disabled for on-prem servers running on a self-signed certificate: a certificate the reader cannot verify blocks all event delivery.
   • Username: copy from Tagnet
   • Password: copy from Tagnet (click the eye icon to reveal)
   • Event Batch Limit: enter 1000. The reader's default of 10,000 produces large payloads that can stale-buffer tag reads and add server memory pressure; 1,000 gives Tagnet smaller, more frequent batches for responsive workflow triggering. See Tuning event batching below if you need different values.
   • Batch Linger: leave blank (defaults to 1000 milliseconds). This flushes any queued events every 1 second, which is the cadence Tagnet's connectivity health expects.
   • Event Buffer Size: leave blank (defaults to 100000). This is the reader's internal overflow buffer and only matters during extended network outages.
   • Enable Retry / Initial Timeout (s) / Max Timeout (s): leave blank to use defaults. Retry is what lets the reader resend batches Tagnet did not acknowledge, such as those sent while the Tagnet service is restarting. Tagnet processes the resent reads as new reads. If your site only acts on current reads, see Reads while the service is stopped before leaving retry on.
6. Click Save to save the changes and enable webhook reporting.
7. In the top app bar, the Webhook status indicator should turn green indicating that the reader has connected to Tagnet. A red status indicator indicates an error connecting. Click on Webhook to see further details.

An optional but suggested step is to navigate to Network → NTP and Add Static NTP Server using pool.ntp.org. This will ensure the reader clock is in sync.

Step 3: Deploy a profile to start RFID scanning

1. Navigate to the Profile Presets menu.
2. There should be a default profile which can be cloned or a new profile can be created using the Create button.
3. This guide does not detail the settings available in the profile, however there are several settings that should be enabled to ensure proper functionality. Both are found in the Event Configuration section:
   • Include Reader Hostname: this must be enabled as Tagnet validates the hostname and credentials for all inbound payloads
   • Tag Inventory Included Fields: at minimum enable the following options, however all fields can be included.
     • Antenna Port
     • EPC Hex
     • Last Seen Time
     • Peak RSSI
     • Frequency
     • Phase Angle
   • Enable Activation Event: leave this disabled. Tagnet no longer needs this setting to track antenna status. Antenna connection state is now derived from the tag reads themselves (see About antenna connection status below). On a reader with more than one antenna, enabling this option causes the reader to emit hundreds of antennaActivation events per second while muxing between antennas, which is a significant amount of network traffic for no benefit. Tagnet will accept and silently discard these events if the setting is left on, but turning it off reduces bandwidth and log noise.
4. Click Save after configuring your operational parameters.
5. At this point the profile should have a Start option which will enable RFID scanning.
6. In the top app bar, the Reader status icon should turn green to indicate it has started.

Step 4: Verify data is flowing

1. In Tagnet, return to the Devices page.
2. Present a tag to the reader.
3. The device LastSeen timestamp should update within a few seconds.
4. Open the Live Reads tab of the Devices page, or the reader's own Ingest data tab, to see incoming tag reads.

Troubleshooting

Tagnet rejects data with "Device identity mismatch"

The hostname field in the reader's outbound payload must match the Hostname you entered when creating the device. Open the reader's web UI, confirm the current hostname, and update the Tagnet device record if it has changed.

Reader's connector shows 401 Unauthorized

• Re-copy the username and password from Tagnet's Connection info, with no leading or trailing spaces.
• Confirm the reader is using Basic authentication (not Bearer / API key).
• Verify the reader's clock is reasonably in sync with UTC. Large time skew is logged by Tagnet.

No data arriving at all

• Confirm the endpoint URL ends in /api/v1/ingest/impinj.
• Check the reader's outbound network path to the Tagnet host.
• If the Verify TLS webhook setting is enabled and the Tagnet server uses a self-signed certificate, the reader refuses to deliver events. Disable the setting, or install a certificate the reader can validate.
• In the reader UI, check the IoT Connector status page for error messages.

Heartbeats but no tag reads

• Confirm the reader's Start Preset or Mode is running and antennas are connected.
• Verify the antennas are within range of the tag.

How Tagnet interprets payloads

Reader sends	Tagnet does
Array of tagInventory envelopes	Persists each as a TagReadEvent, routes through scan rules and workflows, and marks the antennas that produced reads as connected on the reader dashboard
Empty array []	Treats as a heartbeat: updates LastSeen and counts it toward the reader's connectivity uptime on the Device Health card of the Home page
inventoryStatus event (reader starting or stopping)	Updates the reader's operational state (Scanning / Idle). When the reader transitions to Idle, all antennas are reset to a disconnected state
Only antennaActivation events (antenna muxing with no tags in range)	Accepted and silently discarded; see the Enable Activation Event note in Step 3
Other payload shapes	Logs a warning and ignores the payload (the reader is not refused)

About antenna connection status

Tagnet's reader dashboard shows which antennas are connected and how many are in use. For R700 readers, this list is built from the antennas that produce tag reads, not from the reader's antennaActivation events.

How it works:

• A tag read on antenna N marks that antenna as connected. The first time Tagnet sees a read coming from antenna port 3, it flips port 3 to "connected" on the reader dashboard.
• When the reader transitions to Idle, all antennas are reset to disconnected. The next time the reader starts scanning and produces reads, the antenna list rebuilds from scratch.

Why this design. The R700's IoT Connector does not provide an efficient way to report current antenna connection state. The available signal, antennaActivation events, fires every time the reader switches between antennas (hundreds of times per second on a multi-antenna reader), which is far too much data to persist and adds no real information: muxing through a port doesn't prove a tag-producing antenna is cabled there. Driving antenna status from actual tag reads is cheaper and more meaningful: if a port is reading tags, it's connected to a working antenna in the right place.

Known limitations of this approach:

• Antennas that don't read tags won't appear as connected. If a port is physically connected but hasn't been in range of any tag since the reader started, it will stay "disconnected" in the dashboard until it produces a read.
• Physically unplugged antennas stay "connected" until the next Idle. If an antenna was reading tags and is then unplugged while the reader is still running, Tagnet has no way to detect it. The entry will persist as "connected" until the reader transitions to Idle, which resets the whole list.

Tuning event batching

The reader's Event Reporting → Webhook page exposes three batching controls that together decide when the reader ships events to Tagnet. The recommended values in Step 2 work well for most deployments. This section explains what each setting does so you can tune them if your environment needs different tradeoffs.

Setting	Reader default	Recommended for Tagnet	What it controls
Event Batch Limit	10,000	1,000	Max events packed into a single HTTP POST. Hitting this limit flushes the batch immediately.
Batch Linger	1,000 ms	1,000 ms (default)	Max time the reader waits before flushing the queue. When the linger elapses, a batch is sent even if the batch limit hasn't been hit (an empty batch is sent if nothing is queued, which is what Tagnet uses as a keep-alive).
Event Buffer Size	100,000	100,000 (default)	Internal queue size on the reader. When this is exceeded during a sustained outage, the oldest events are dropped and replaced with an OverflowEvent marker.

Why we recommend a smaller Event Batch Limit. At the reader's default of 10,000 events per batch, each POST can carry 2–4 MB of tag-inventory JSON. Larger batches mean:

• Higher end-to-end latency for workflows. A scan event isn't actionable until the batch it's in reaches Tagnet. Smaller batches reduce worst-case staleness.
• Larger blast radius on a failed request. If a batch fails to deliver, every event in it is delayed. A 1,000-event batch loses 10× fewer events on failure than a 10,000-event one.
• More server memory pressure per request. Tagnet accepts up to 10 MiB per Impinj POST, so reader-default batches still work, but smaller batches are cheaper to process.

When you might want to increase it: extremely high-throughput environments (10,000+ reads per second sustained) where HTTP request overhead becomes significant. Raise the Event Batch Limit gradually and keep each POST under 10 MiB.

When you might want to decrease Batch Linger: if you need sub-second reaction time in your workflows, drop the linger to 500 or 250 ms. The tradeoff is more frequent (mostly empty) batches during idle periods.

Security notes

• The ingest endpoint uses HTTP Basic authentication over TLS. Don't screenshot the Connection info panel.
• The password is encrypted at rest in Tagnet. If the reader is replaced, regenerate the password from the device's Overview tab and update the reader's IoT Connector configuration.