Nametag Integration for Slate

Overview

The Nametag and Slate by Technolutions integration verifies applicant identity during the admissions lifecycle. When an applicant reaches a stage you choose, Nametag verifies their real-world identity with a government ID and a live, deepfake-resistant selfie, then writes a pass/fail signal back onto the Slate person/application record.

Nametag stores no applicant personal data in Slate — only the verification signal, a Nametag reference, and a timestamp. Applicant identity documents never enter Slate.

How it works

1. A Slate automation rule or scheduled query notifies Nametag when a matching applicant needs verification (an HMAC-signed request to Nametag).
2. Nametag mints a single-use, expiring verification link bound to the applicant’s Slate person GUID and round.
3. The applicant completes government-ID + Deepfake Defense liveness on the Nametag hosted flow.
4. Nametag writes the outcome back to Slate: nametag_identity_status (verified / failed / review / pending), nametag_verification_id, nametag_verified_at, and the Identity Verification checklist item.
5. Your Slate rules decide what a failed or review result holds (decision release, registration, or financial-aid disbursement). Nametag never blocks anything on its own.

Before you start

In Slate, you’ll need:

• A Slate Administrator (All Access) service account dedicated to this integration.
• An Open API key (Database → Import and Data Processing → Integration Center → Open API).
• Permission to create a Source Format, a query/automation rule, and a checklist item / custom fields.

In Nametag, you’ll need an administrator account with access to Integrations. (The Slate integration is enabled per organization; if you don’t see it, contact Nametag support.)

Setup takes about 20 minutes, and nothing goes live until you activate it.

Step 1 — Connect to Slate

1. In Nametag, go to Integrations → Add integration → Slate by Technolutions.
2. Enter your Slate host, the service-account username / password / token, and the Open API key. Choose the data region that matches your Slate instance (US / Canada / EU).
3. Nametag runs a read test against the Slate Open API and shows a green check when the connection works. If it fails, see Troubleshooting.
4. Copy the signing key Nametag shows you — you’ll paste it into Slate in Step 3. It is shown only once.

Credentials are encrypted and never displayed again. You never enter a Nametag key into Slate or into the Nametag console — the credentials you provide are your own Slate-side credentials.

Step 2 — Choose who it covers

Pick the population (for example, first-time aid applicants, all submitted applications, or only applicants flagged for review), the round / term, and the decision stage that should require verification. Start narrow — one round — and widen later. These values describe the query you build in Slate; they contain no applicant data.

Step 3 — Set when it runs, and import the Slate blueprint

1. In Slate, create the blueprint the wizard describes:
   • custom fields nametag_identity_status, nametag_verification_id, nametag_verified_at;
   • an Identity Verification checklist item;
   • a Source Format web service that receives the result from Nametag (paste its URL into the wizard’s Write-back step);
   • a query/automation rule that POSTs to Nametag when a matching applicant needs verification.
2. In the query/rule’s request headers, include the signing key from Step 1 (X-Nametag-Signature-Key) plus an X-Nametag-Timestamp and an X-Nametag-Signature (an HMAC-SHA256 of the request body) so Nametag can confirm the request really came from your Slate instance.
3. Choose how applicants are reached: Slate rule / query POST (Slate emails the applicant the returned link via a merge field) or applicant email link.

The wizard shows the exact field names and values to paste at each point.

Step 4 — Review and activate

Confirm the population, trigger, and write-back configuration on the review screen, then Activate. Matching applicants are now asked to verify automatically.

What your Slate rules do with the result

Nametag writes the result to nametag_identity_status and updates the checklist item. Nametag does not block anything on its own. Use your standard Slate rules to decide what a failed or review result should hold — for example, an identity hold that pauses decision release or aid disbursement until the field reads verified. Because Slate processes imports on a queue, a result can take a few minutes to appear.

Managing the connection

The Slate integration detail page in Nametag shows connection status and current configuration, and lets you test the connection or disconnect. Disconnecting purges the stored Slate credentials and stops Nametag from accepting further events.

Troubleshooting

• Connection test fails: confirm the service account has the Administrator (All Access) role, the host is a correct https:// URL (no trailing path), and the Open API key is active.
• Results aren’t appearing in Slate: Slate imports process roughly every 15 minutes — allow time. Confirm the Source Format web service is enabled and the service account can write the fields. A write is accepted immediately and applied on Slate’s queue.
• Applicants aren’t being asked to verify: confirm the query/rule matches your chosen population/round and that the signature headers are present. Check the integration is Active.
• An applicant is stuck: a verification request expires after about 168 hours; expired requests move to review so staff can follow up.

Need help? Contact Nametag support with your institution name and the affected applicant’s Slate reference. Never share the applicant’s ID documents — Nametag already holds the verified identity.