Tablet and kiosk signing

Kiosk mode is for controlled in-person signing at a front desk, rental counter, check-in area or service counter.

Watch it done: A signing tablet on your counter (4:49)

Getting the app

The SignSealer app is one app for iPhone, iPad and Android phones and tablets. Until it is listed in the App Store and on Google Play, it is installed like this:

• Android. In the dashboard, Apps & tablets has a Download for Android button for anybody signed in to the business. Open the file on the tablet and allow installs from that source when Android asks. It needs Android 7 or later on an ARM processor, 32-bit or 64-bit; it does not install on an x86 emulator.
• iPhone and iPad. An iOS app cannot be installed outside the App Store. During our beta, a business taking part is offered Apple's TestFlight instead: once we have set the link, Apps & tablets shows Join on TestFlight. Open it on the device, install TestFlight if it asks, then install SignSealer from it. Without it, an iPad can still run a counter from the form's own page in Safari (Waivers and workflows).

The site's App Store and Google Play links send you to each listing from the day it exists, and say so until then.

Updates

A store install is updated by its store. A tablet running the download from Apps & tablets is told on its Home screen when a newer build is offered to your business, with a button back to that page. On Android the download and the Google Play build are signed with different keys, so a tablet moving from one to the other is uninstalled first, which loses its pairing and anything still waiting to send: let the queue empty before you switch.

We can also set the lowest version we support. A tablet below it shows the update card and nothing else, and its kiosk will not start, until it is updated.

Pairing it

The app does nothing until it is paired. In Apps & tablets, Add a tablet: name it and tick the forms it runs, and the page shows an eight-character code, good for fifteen minutes and for one use. Type it on the app's first screen. The tablet trades it for a credential of its own and never holds your API key. Then, on the tablet, set a staff PIN of four to eight digits under Settings: the kiosk will not start without one. A platform pairing tablets for the businesses it runs does the same with POST /v1/devices, under Tablets from your own software on this page.

The PIN guards the app's own screens; the tablet guards the rest. On a counter, lock the tablet to the app with Guided Access on an iPad or screen pinning on Android, and turn off the keyboard's predictive text and suggestions, so it does not offer one customer's name to the next.

Operator model

• Staff setup. Connect the device, choose the workflow and set the staff PIN before entering kiosk mode.
• Signer session. The signer gets one focused form. The device resets between people, and an idle timeout clears abandoned work.
• Offline capture. The device holds the consent and the signature through a connection drop and sends them when service returns.
• Or a QR. If the customer would rather use their own phone, show a QR code at the same counter instead of handing the tablet over.

Device acceptance test

• Enter and exit kiosk with the staff PIN.
• Verify lockout after repeated wrong PIN attempts.
• Leave a form idle and confirm it clears.
• Complete 10–20 signers consecutively and confirm no prior data remains.
• Drop connectivity during signing and verify synchronization behavior.
• Rotate the device and test supported orientations.

Starting with no network

A connection that is down when the customer is already at the counter must not stop the signing. The SignSealer app keeps everything it needs to run its workflow on the device — the published form and its version, the consent and intent wording a signer is shown, the pages of an uploaded PDF — and refreshes it on every heartbeat. With no network on start-up it renders the form itself, takes consent and the signature, and queues the whole signing: the start first, then the consent and signature behind it, each tied to the one before.

When service returns the queue drains in order. The start names the version of the form the customer read (expected_template_version), the date the tablet showed, and the device’s own clock as a claim (captured); the server computes the skew rather than believing it and puts both on the audit trail. If the form was revised in the meantime the start is refused with 409 template_changed, nothing is sealed against words nobody read, and the tablet tells staff which customer needs to sign again on the current form. Your own tablet software does the same with GET /v1/workflows/{id}/bundle, GET /v1/workflows/{id}/pages/{n} and the same two fields on the start, once it is paired as a device (POST /v1/devices/pair): captured is refused with 422 from anything that is not a paired tablet, because it is what lets the tablet keep the date it showed, and the day a document is signed is nobody else’s to choose (00435). The date is kept only when it is a day within a day of the tablet’s own clock and not after today; otherwise the first signature writes the day in.

A signing code at the counter

When the sale is made in your own software (00321), PUT /v1/subjects builds the packet and the receipt carries a ten-character signing code. Set the tablet’s hand-off on Apps & tablets: same device hands the code to the app on the same tablet (signsealer://kiosk?code=…); separate till makes the tablet list who is waiting, by first name and last initial, refreshed on its heartbeat. Either way the customer’s screen shows what the packet owes, each item is signed in turn on the ordinary road — read, consent, photographs, signature — and the list ends complete. A tablet resolves a code with GET /v1/packets/code/{code} and starts an item with POST /v1/packets/items/{id}/start; it never reads a packet’s full detail. A code from another business, a code nobody holds and a malformed one answer the same way.

A photograph as an answer

A template field of kind photo (00342) — the boat before it leaves, the fishing license, the vaccination card — takes a photograph, not text. On the signing page it is a camera button; at the counter the tablet asks for it after consent, with the template’s own label and hint, and with no network keeps it sealed behind the start and sends it in its turn. A required one is needed before the signature. The image is encrypted under the business’s key and kept with the document for as long as the document is kept; the field carries its SHA-256, the trail records photo_supplied, and Documents shows it beside the signer. It is an answer to a question in the agreement, not an identity check of any kind. Over the API: POST /v1/sign/{token}/fields/{key}/photo. The signed PDF prints each photograph after the certificate unless the business turns that off for the template (the sealed PDF).

The last check at the gate

The person who hands over the kayak, opens the gate or drives the bus is the last to see the customer, and the one with the least time. Gate check in the app (from Home, the menu, or the kiosk’s menu behind the PIN) answers one question over the open documents: has everybody on this waiver signed? Search by name or title (a tablet kept to its own documents does not search addresses or numbers); open one and each signer is listed with a tick or a circle. For anyone who has not signed, Show QR to sign mints a fresh signing link on the server — the one they were sent stops working, and the trail records that a link was shown at the gate — and draws it as a QR code the customer scans with their own phone. The screen asks again every few seconds and turns green when the signature lands. It works online only, and says so: the point of the check is what the server knows now.

A link the tablet shows is one whoever holds the tablet could open too, so a tablet shows links only for documents it started, or that its own form started. A tablet at the gate that checks people your booking system emailed needs more: in the portal, under Apps & tablets, set Show links for to every open document for that tablet (or PATCH /v1/devices/{id} with "gate": "account"). The change is on the audit trail; a tablet paired before 24 September 2026 was left at every open document, so nothing that worked stopped working, and can be narrowed the same way. GET /v1/documents/{id}/signers answers link_allowed, so the button is only offered where it will work. A signature made through a link shown this way is assured as link, not by the email that went out before it.

Your own software asks the same way: GET /v1/documents/{id}/signers is each signer’s name and state and nothing else, and POST /v1/documents/{id}/signers/{signer}/link answers a fresh link with its QR code as SVG. A paired tablet’s credential may call both; the whole document, with its text and every address, stays with an API key.

How the tablets are doing

Every heartbeat carries the queue’s shape: how many signatures are waiting on the tablet to be sent, how many the server refused for good, and whether everything captured has been delivered. Apps & tablets shows it beside each tablet as one word — synced, waiting, needs attention, update, or not heard from — so nobody has to walk over to the counter to know. A problem on the tablet (an item the server refused, a screen that failed) is reported as a code, the screen and the step it was on, whether it was online and how deep the queue was: names and numbers, never a message, so never a customer. Your own tablet software can say the same with queue_waiting, queue_refused and synced on the heartbeat and POST /v1/devices/report.

Tablets from your own software

One business pairs its tablets from Apps & tablets in the portal. A platform that runs many businesses does the same over the API, with a key that carries signing:devices, so a tablet goes on each counter from your own back office:

The tablet itself trades the code for its own credential with POST /v1/devices/pair, which takes no key at all: the code is the credential, and what comes back is scoped to that tablet alone. A tablet belongs to one business; a platform with many pairs each business's tablets under that business.