Question 1

What is PTERI?

Accepted Answer

PTERI (the Privacy Trust Engine) is Kakr Labs' platform for identity and authorization — for people, AI agents, and existing enterprise systems. Instead of passwords, API keys as bearer secrets, or "trust once, allow forever" sessions, PTERI verifies every identity and authorizes every sensitive action with a cryptographic signature, produced at the moment the action happens. The core idea: if a secret can be typed, it can be phished; if it can be stored, it can be breached. PTERI replaces that model with challenge–response signatures from a key that never leaves your device. What PTERI actually does Authentication — signing in is a signed challenge from your device key, gated by biometrics, not a password Authorization — sensitive actions (payments, role changes, deletions) require a fresh signature over the exact action being taken, so the proof and the approval are the same thing AI agent identity — agents can hold their own cryptographic identity and be required to produce a valid signature before acting, instead of inheriting a human's static credentials Developer APIs & SDKs — a REST API and client SDKs for building identity, authentication, and authorization flows into your product The technology Private keys are generated and held entirely on your device — Kakr Labs' infrastructure can verify a signature but never sees, stores, or can reuse the key that produced it. See how authentication works and how authorization works for the concrete mechanics.

Question 2

Why passwordless: the problem PTERI is solving

Accepted Answer

Almost every account-takeover, phishing, and credential-stuffing incident traces back to the same design flaw: a reusable secret that can be typed, copied, or intercepted — a password, an OTP code, a session token, an API key sent as a bearer credential. What this causes in practice Phishing pages that just ask for the password or OTP directly Credential stuffing — reused passwords tested across many sites Session hijacking — steal the token, skip the login entirely "Trust once, allow forever" — an approved session can keep acting long after the human stopped paying attention, including being handed off to an AI agent with no re-verification PTERI's approach Remove the reusable secret entirely. Every sign-in and every sensitive action is a fresh, single-use cryptographic signature tied to that exact moment and that exact action — there's nothing for a phishing page to capture that would be useful anywhere else.

Question 3

Creating a developer account and your first API key

Accepted Answer

To start building with PTERI's API: Register at pteri.org/register and confirm your email From your Developer Dashboard, generate an API key Set it as an environment variable, e.g. PTERI_API_KEY , rather than hardcoding it anywhere that might get committed to source control Every API request sends this key in the nodeUrlOrApiAccessKey header (no Bearer prefix). See getting started with the API for the first calls to make once you have a key. The Free tier ($0/month, no credit card required) is enough to explore the API — 3 API calls/sec, 1 agent identity, MFA for up to 5 accounts. See plan tiers and limits when you're ready to scale up.

Question 4

The PTERI Wallet app

Accepted Answer

The PTERI Wallet app is your identity device — it holds your private key and signs the challenges PTERI sends when you sign in or approve a sensitive action. It's the same mechanism described in how authentication works . What it's used for Approving sign-in challenges with a biometric-gated signature Approving payment intents and other sensitive actions (see how authorization works ) Holding your PTERI identity key, independent of any single device or backup you haven't yet made Because your key never leaves the device, losing the device means losing access unless you've backed up your recovery phrase — see recovering account access before you need it.

Question 5

Setting up and managing your account

Accepted Answer

Creating a PTERI account starts at pteri.org — there's a free tier with no credit card required, so you can explore before committing to a paid plan. Getting set up Go to pteri.org/register and create your account Confirm your email address From your Developer Dashboard , generate your first API key (see creating your first API key ) What lives in your Developer Dashboard Generating and managing API keys Monitoring your usage against your plan's rate limits Upgrading, downgrading, or cancelling your plan (see managing your subscription ) Linking your identity Your account itself (email, dashboard, billing) is separate from the device-based identity PTERI uses for authentication and authorization — see how authentication works for how the two connect once you're signing requests with your PTERI key. Since there's no password to lose, back up your recovery phrase or enable encrypted cloud backup now — see recovering account access for why this matters before you need it.

Question 6

Recovering account access

Accepted Answer

PTERI doesn't have passwords, so there's no "forgot password" flow — and that's deliberate. Because your private key never leaves your device and Kakr Labs never has a copy of it, we cannot recover your identity, reset your key, bypass your biometrics, or sign on your behalf — even if you ask us to. It's a tradeoff: slightly more responsibility on you, in exchange for a much stronger guarantee that no one else — including us — can act as you. Recovering access to a new device Install the PTERI Wallet app on your new device Restore your identity using either your recovery (mnemonic) phrase or an encrypted cloud backup (iCloud/Google Drive) Sign an authentication message to prove control of the restored key Re-register the device This only works if you saved your recovery phrase or enabled encrypted backup before you lost access. If you don't have either, there is currently no path back into that specific identity — set up a backup now if you haven't already, from your app's security settings. If you're locked out of your support.kakr.ai account Separately from your PTERI identity key, your support portal login (used to track tickets here) is a normal email + password account. If you forget that password, use Forgot your password? on the sign-in page — that's unrelated to your PTERI identity and is fully self-service.

Question 7

Enterprise plans and how to reach us

Accepted Answer

Enterprise Pteri is $299/month: 300 API calls/sec, unlimited agent identities, MFA for up to 200 accounts, custom SLA, white-label options, and dedicated support — on top of everything in the Free and Pro tiers. See plan tiers and limits for the full comparison. How to reach us about Enterprise There's currently one path in, regardless of what you need — a demo, pricing, a technical question, or a partnership: the contact form on kakr.ai , which has a "Reason to Contact Us" dropdown, or contact@kakr.ai directly. We respond as quickly as we can — no formal response-time SLA is published today. Being upfront about what's not published yet: there's no formal SLA, uptime commitment, or per-plan support-tier document available today, and no separate named account-manager process — Enterprise conversations happen directly through the contact channel above. If your evaluation needs a formal SLA in writing, say so in your message and we'll work it out directly.

Question 8

How authentication works

Accepted Answer

PTERI authentication is challenge–response with a device-held signature , not a password or a FIDO2/WebAuthn credential. App requests authentication PTERI issues a random challenge Device key signs it after biometric approval Signature verified → session issued Diagram: the authentication flow described below. (An illustration we made, not a product screenshot.) The flow An app or service requests authentication PTERI's backend generates a challenge — a random, short-lived value The challenge reaches your device You approve via your device's biometrics Your device signs the challenge with your private key The signature is sent back and verified against your known public key Once verified, the backend issues its own session — it never saw or handled your private key at any point Because the key never leaves your device and each challenge is single-use, there's no reusable secret for a phishing page or a breached database to expose. For developers API requests authenticate with the nodeUrlOrApiAccessKey header — either your API access key (a JWT, sent raw with no Bearer prefix) or a dedicated node URL on Enterprise plans. Signing and verification are exposed directly as API operations: /api/Address/sign-message and /api/Address/verify-message . See getting started with the API for a working request sequence.

Question 9

MFA and device verification

Accepted Answer

PTERI doesn't use traditional MFA — there's no authenticator app, no TOTP secret, no SMS code. If you're used to that model, here's the closest equivalent and how it actually works. Device key + eSIM-bound device Signs a challenge One-time value derived from the signature PTERI verifies signature + eSIM binding Diagram: how a step-up code gets derived without a shared secret. (An illustration we made, not a product screenshot.) eSIM identity binding A PTERI-linked account can be bound to a device identity key, which is bound to a device's eSIM. When step-up verification is needed, the device signs a message with its private key and derives a one-time value from that signature — not from a shared secret sitting on a server. The signed payload is sent to PTERI, which verifies the signature against the known device identity and confirms the eSIM binding before marking the device "verified." Moving to a new device If you get a new phone, there's no MFA reset request to file. Install the PTERI Wallet app, restore your identity from your recovery phrase or an encrypted cloud backup , sign an authentication message to prove control, and re-register the device. See recovering account access for the full steps — and back up your recovery phrase now, before you need it. Why this instead of TOTP/SMS? Shared TOTP secrets can be phished or leaked from a server-side database; SMS can be intercepted via SIM-swap. Deriving the one-time value from a device-held signature removes the shared secret entirely — there's nothing sitting on a server that, if breached, would let someone else generate valid codes.

Question 10

How authorization works

Accepted Answer

PTERI treats authorization differently from most systems. There's no roles table being checked against a permissions list at request time — the signature over the specific action is the authorization . Intent payload (amount, destination, parameters) Device key signs that exact payload One signature proves: ✓ genuinely authorized ✓ parameters unaltered ✓ can't be replayed Diagram: how one signature covers authenticity, integrity, and replay protection at once. (An illustration we made, not a product screenshot.) Bound intent Take a payment as an example. The intent — amount, destination, network, any privacy parameters — is assembled into one payload, and your device key signs that exact payload . The resulting signature proves three things at once: the action was genuinely authorized, its parameters weren't altered after the fact, and it can't be replayed as a different action later. Identity, intent, and authorization aren't three separate checks — they're bound into one cryptographic proof. Step-up authorization for sensitive actions Sensitive actions — role changes, payouts, deletions — always require a fresh challenge and a new signature at the moment of the action. There's no "already trusted" state that persists from an earlier login; a session being active doesn't by itself authorize a new sensitive action. Admin and privileged access Administrative authority is modeled as an identity with a defined scope of permissions, rather than a separate role-based trust system layered on top. Every privileged action still requires its own signed intent from that identity.

Question 11

PTERI's model for AI agent authority

Accepted Answer

A growing share of actions online are initiated by AI agents rather than a human at a keyboard, and most of today's security model wasn't built for that — an agent that inherits a static API key or a long-lived session can act far beyond what anyone actually intended, with no way to verify after the fact whether a given action was genuinely authorized. AI agent wants to act Receives a scoped challenge Produces a valid signature No signature, no action Diagram: the proposed model for agent authority. (An illustration we made, not a screenshot of a working integration.) PTERI's proposed model Agents are treated as principals with their own cryptographic identity , not as an extension of a human's credentials. Before an agent acts, it receives a scoped challenge for that specific action and must produce a valid signature for it — no signature, no action. This is the same challenge–response and bound-intent model described in how authentication works and how authorization works , applied to an agent instead of a person. Where this stands today This is the architectural direction Kakr Labs has published for AI agent authority — as of this writing, there isn't yet a published agent-registration endpoint, a dedicated agent credential type, or a step-by-step integration guide. If you're evaluating PTERI for an AI-agent use case, reach out via a support ticket (Technical / API category) or contact us directly for the current state of this capability.

Question 12

PTERI Intelligence and MCP

Accepted Answer

MCP (Model Context Protocol) is an emerging standard for connecting AI assistants to external tools. PTERI Intelligence's published direction is to expose its capabilities through MCP using five tool namespaces, each requiring explicit authority to invoke: MCP client PTERI Intelligence (planned) identity.* tx.* privacy.* message.* observe.* Diagram: the planned tool namespaces. (An illustration we made, not a screenshot of a running MCP server.) identity.* — identity discovery and status queries tx.* — transaction construction, signing, broadcasting privacy.* — confidential/privacy-preserving transfers message.* — message signing and verification observe.* — status and confirmation tracking The stated design goals: strict input schemas, tools that require explicit authority to invoke, deterministic output that can be logged and audited, and no path for a tool call to escalate permissions, touch a private key, or act outside its declared scope. What's not available yet As of this writing there's no published MCP server URL, no installable package, no client configuration file, and no tool-call examples or schema definitions — this is a named model for future tooling, not a connectable integration today. If MCP support is central to your evaluation of PTERI, please open a ticket (Technical / API category) so we can point you to the current state.

Question 13

Getting started with the API

Accepted Answer

Once you have an API key (see creating your first API key ), every request authenticates with the nodeUrlOrApiAccessKey header — your API key as a raw value, no Bearer prefix. A typical first sequence POST /api/Wallet/create with {"walletName": "..."} — creates your identity anchor and confirms your key and connection work POST /api/Address/create (needs the walletName and an encryptedPassphrase header) — generates an address under that identity GET /api/Address/address-balance — checks a balance Signing and verifying messages — the mechanism behind authentication and authorization — are their own endpoints: /api/Address/sign-message and /api/Address/verify-message . Response format Every response is wrapped as { successful, message, data } . Importantly, a failed operation can still come back as HTTP 200 with successful: false — always check that field, not just the HTTP status code. See common API errors for the specifics. Base URL Use the base URL shown in your own dashboard/API reference for your account and plan — it can vary (Enterprise plans use a dedicated node URL instead of the shared endpoint).

Question 14

SDKs and supported languages

Accepted Answer

PTERI's client SDKs are generated from a single OpenAPI specification across 11 languages. As of this writing, two are published to a package registry: JavaScript/TypeScript — liaas-js on npm TypeScript — pteri-sdk on npm The remaining generated SDKs (Python, Go, Java, C#, Ruby, PHP, Dart, Rust, Kotlin) are source-available rather than published to a package manager — check your developer dashboard for the current list and build instructions. None of the generated SDKs ship a default base URL, so you'll need to configure yours explicitly regardless of language.

Question 15

Understanding the API response envelope

Accepted Answer

Every PTERI API response, success or failure, is wrapped the same way: { "successful": true, "message": "...", "data": { ... } } The important part for error handling: a failed request can still return HTTP 200 with successful: false and an explanatory message . If your code only checks the HTTP status code, you can miss real failures. Always check successful first, and surface message in your own error handling.

Question 16

Integrating PTERI into your application

Accepted Answer

The primary way to integrate PTERI into an existing product today is through its REST API and client SDKs — see getting started with the API and SDKs and supported languages . If you're looking specifically for a pre-built connector into an existing SSO/IAM system, or a webhook-based integration, we don't have a dedicated one published yet — everything currently goes through the general-purpose API. If your use case depends on one of these, let us know via a support ticket (Technical / API category) — that kind of demand directly informs what we build next.

Question 17

Plan tiers and usage limits

Accepted Answer

Current plans (confirm exact pricing on kakr.ai , since tiers do change): Free — $0/month, no credit card required. 3 API calls/sec, 1 agent identity, MFA for up to 5 accounts, self-custody identity access, all platforms (Android, iOS, Web). Best for personal testing and first integrations. Pro — $49/month. 30 API calls/sec, up to 10 agent identities, MFA for up to 25 accounts, a verified agent badge (coming soon), PTERI lifetime payments, and priority support. Best for developer studios and startups running agent fleets. Enterprise Pteri — $299/month. 300 API calls/sec, unlimited agent identities, MFA for up to 200 accounts, custom SLA, white-label options, and dedicated support. Best for mid-market and regulated organizations — see Enterprise plans and how to reach us . Need something outside these tiers? Contact us via a support ticket (Billing category) or contact@kakr.ai .

Question 18

Managing, upgrading, or cancelling your subscription

Accepted Answer

Subscriptions are managed entirely from your Developer Dashboard at pteri.org/Developer/Dashboard/Subscriptions . From there you can: Upgrade or downgrade your plan Manage billing details Generate and manage API keys Monitor your usage against your plan's limits If you run into an issue you can't resolve from the dashboard, submit a ticket under the Billing category and we'll help directly.

Question 19

PTERI's threat model — what's protected and what isn't

Accepted Answer

PTERI treats security as a property of architecture , not a layer bolted on afterwards. Threats eliminated by design Credential theft and replay attacks — there are no shared secrets to steal Phishing of passwords or OTP codes — there are none Impersonation by infrastructure — the platform can verify but never sign on your behalf AI forgery — proofs require a private key that never leaves your control Explicitly out of scope PTERI does not protect against: Compromised devices User-approved malware Physical coercion Keep your device secure and review every approval request before you sign it.

Question 20

Key custody and biometrics — who holds your keys?

Accepted Answer

PTERI is zero-custody : private keys are generated on your device, protected by biometrics (FIDO2), stored in hardware-backed storage when available, and never leave the device . Kakr Labs' infrastructure can verify your signatures but cannot impersonate you and cannot recover your keys. This is why verification is deterministic: either the correct key signed the action, or it didn't. Why determinism matters Traditional security is probabilistic — risk scores, heuristics, "suspicious login" guesses. PTERI verification is deterministic cryptographic proof at action time, which removes whole classes of false positives and social-engineering attacks.

Question 21

Service status and uptime

Accepted Answer

PTERI runs on Google Cloud infrastructure. No specific uptime percentage or SLA is currently published for any plan tier, including Enterprise — see Enterprise plans and how to reach us if you need one in writing. Check live service status any time at kakrlabs1.statuspage.io .

Question 22

Reporting a security vulnerability

Accepted Answer

Found a potential security issue in PTERI, the PTERI Wallet app, our APIs, or this support portal? Please report it to us directly rather than disclosing it publicly first — this keeps everyone, including other customers, safe while we investigate and fix it. Vulnerability reports get their own dedicated path, separate from ordinary support tickets — use Report a Security Vulnerability rather than the general ticket form. How to report Use the Report a Security Vulnerability form — this routes it separately from general support instead of sitting in the same queue as a billing question. Or email contact@kakr.ai with a subject line starting with "SECURITY:" . Machine-readable reporting details are also published at /.well-known/security.txt (the emerging standard security researchers' tools check automatically). What to include A clear description of the issue and its potential impact Step-by-step instructions to reproduce it Any relevant request/response data, screenshots, or proof-of-concept code The component affected (wallet app, API, support portal, etc.) and, if applicable, an account or address used for testing Responsible disclosure guidelines To keep this a good-faith process for everyone: Only interact with accounts and data you own, or that you have explicit permission to test Don't access, modify, or exfiltrate data beyond what's strictly needed to demonstrate the issue Avoid actions that could degrade service for other users (no automated scanning or load-testing against production without prior written permission) Give us a reasonable window to investigate and remediate before any public disclosure We review every report that comes in through these channels. For anything else — account help, billing, general questions — please use the regular support ticket flow or ask our AI assistant.

Question 23

Common API errors and how to resolve them

Accepted Answer

"My request returned 200 but nothing happened" Cause: the request failed logically, not transport-wise. PTERI wraps every response as { successful, message, data } , and a failure can still be HTTP 200 with successful: false . Check that field before assuming success — see understanding the API response envelope . "401/403 on every request" Cause: the nodeUrlOrApiAccessKey header is missing, malformed, or sent with a Bearer prefix it doesn't expect. Send your raw API key (or Enterprise node URL) as the header value directly. "Address creation fails" Cause: POST /api/Address/create requires both the target walletName and an encryptedPassphrase header — a common mistake is sending one without the other. Still stuck? Submit a ticket under Technical / API with the exact request you sent (redact your API key) and the full response body.

Question 24

"Challenge expired" or "invalid signature" during sign-in

Accepted Answer

PTERI authentication issues a short-lived challenge that your device key signs — see how authentication works . A couple of things commonly break this: "Challenge expired" The challenge has a short window on purpose — it's part of what prevents replay. If your device took too long to prompt for biometrics, or you approved it after stepping away, request a new sign-in attempt rather than trying to reuse the same challenge. "Invalid signature" This usually means the signature was produced by a different key than the one PTERI has on record for that account or address — for example, signing with the wrong identity, or attempting to sign in after restoring a different identity than the one originally registered. Confirm you're using the identity that was originally linked to the account; if you've restored the wrong one, see recovering account access . Still stuck? Submit a ticket under Account & Access with the approximate time of the failed attempt.

Question 25

MFA is not working: first checks

Accepted Answer

Before opening a ticket, run through these — they resolve most MFA sign-in problems on their own: Is the device online? Your device needs connectivity to receive and sign the challenge — see how authentication works . Is this the right device? Sign-in only works with the identity originally registered to the account. A different device or a freshly restored identity won't match — see recovering account access if you're not sure which one that is. Did the challenge time out? Challenges are short-lived on purpose. If you stepped away before approving, request a fresh sign-in attempt rather than reusing the old one. Legacy TOTP fallback — if your account still has an old authenticator-app code configured, check your device's clock is accurate; TOTP codes are time-based and drift causes mismatches. Still stuck? Submit a ticket under Account & Access — include the approximate time of the failed attempt and whether you were prompted for biometrics at all.

Question 26

Troubleshooting overview

Accepted Answer

Pick the article closest to what you're seeing: MFA is not working: first checks "Challenge expired" or "invalid signature" during sign-in Common API errors and how to resolve them Understanding the API response envelope — the most common cause of "it looked like it worked but didn't" If none of these match, or you suspect a live production issue, check service status first, then see the production incident support process for how to open a ticket that gets picked up fast.

Question 27

Support severity levels

Accepted Answer

Every ticket and vulnerability report is classified using the same four levels, so pick the one that matches honestly — it's what routes your report to the right priority, not a way to jump the queue. SEV-1 — Critical production/security outage. Authentication or the API is down in production, or there's an active security incident. SEV-2 — Major functionality impaired. A significant feature is broken or degraded, but there's a workaround or it isn't fully down. SEV-3 — Normal issue or workaround exists. Most day-to-day bugs and questions. SEV-4 — General question, documentation, or billing. Nothing time-sensitive. Choosing a severity does not create a contractual response-time guarantee — no formal SLA is published today outside individually agreed Enterprise contracts (see Enterprise plans and how to reach us ). It does determine how the ticket is triaged internally. For an active SEV-1, see escalating a critical issue .

Question 28

Production incident support process

Accepted Answer

Check service status first. If there's a known incident, you don't need to open a duplicate ticket — the status page is the fastest source of truth. Classify the severity using support severity levels — SEV-1 for anything actually down in production. Collect safe diagnostic information before you write the ticket: the exact endpoint, the full response body with successful / message / data , the approximate time, and how many requests are affected. Never include your raw API key, a password, or an MFA code — see common API errors for what a useful report looks like. Open a ticket with Product/service set to Technical / API and severity set to match. For an active SEV-1, see escalating a critical issue for how to get it seen fastest.

Question 29

Shared responsibility: what KAKR secures vs. what you secure

Accepted Answer

PTERI's zero-custody, signature-based model (see PTERI's threat model ) removes entire categories of risk from KAKR's side of the line — there's no password database to breach and no shared secret to phish. But security is still a shared job: What KAKR's platform is responsible for Verifying signatures correctly and never storing or reusing a private key Issuing single-use, short-lived challenges that resist replay Publishing service status and responding to reported vulnerabilities (see reporting a security vulnerability ) What you're responsible for Keeping your device and its OS secure — PTERI doesn't protect against a compromised device or user-approved malware Backing up your recovery phrase or enabling encrypted cloud backup before you need it (see recovering account access ) Protecting your API credentials the same way you'd protect any production secret (see creating your first API key ) Reviewing what you're signing — a real signature request is still only as safe as your attention to what it says it's approving

Question 30

Security incident communication overview

Accepted Answer

If a security incident affects the platform, the fastest source of truth is the status page — check service status and uptime for how to follow it. Being upfront about what's not formalized yet: there is no separately published incident-communication policy or guaranteed customer-notification timeline today. If you're evaluating KAKR for a use case that requires a formal incident-notification commitment in writing, say so via the Enterprise contact channel and we'll work it out directly. To report a security issue yourself, see Report a Security Vulnerability .

Question 31

Enterprise security and compliance resources

Accepted Answer

For a security questionnaire or procurement review, start with: PTERI's threat model — what's protected by design, and what's explicitly out of scope Key custody and biometrics — the zero-custody model in detail Responsible disclosure guidelines and the vulnerability reporting path Service status Being upfront about what's not published yet: KAKR does not currently hold or claim SOC 2, ISO 27001, HIPAA, GDPR-certified, or similar compliance certifications. If your review requires evidence of a specific certification, say so via a support ticket (Enterprise category) so we can tell you the current state rather than leaving the question unanswered.

Question 32

KAKR getting started guide

Accepted Answer

The shortest path from nothing to a working integration: Understand what you're building on. Read what is PTERI? and, if it's new to you, why passwordless . Create your account and first API key. See creating a developer account and your first API key — the Free tier needs no credit card. Make your first API calls. Follow getting started with the API — a connectivity check, then creating an identity and an address. Understand authentication and MFA before you build a login flow around it — see how authentication works and MFA and device verification . Check plan limits against what you're building — see plan tiers and usage limits . Before you go live , run through the production readiness checklist . Stuck at any step? Submit a ticket or ask Kai from any page.

Question 33

Production readiness checklist

Accepted Answer

Before switching a real integration on, confirm: Security Your production API key is stored as an environment variable or secret, never hardcoded — see creating your first API key You have a plan for rotating and revoking credentials if one is ever exposed You've read PTERI's threat model and shared responsibility so you know what's on you vs. the platform Operational Your code checks the successful field on every response, not just the HTTP status — see understanding the API response envelope You've tested authentication end-to-end, including the failure paths — see test authentication before production You know your plan's rate limit and have basic retry/backoff handling — see rate limits and safe retry behavior You've bookmarked the status page and know your support severity levels before you need them

Question 34

Test authentication before production

Accepted Answer

Before relying on PTERI authentication in production, verify with a non-production account: The happy path. Request authentication, approve the challenge with biometrics, confirm your backend receives a valid, verified session — see how authentication works . An expired challenge. Let a challenge time out on purpose and confirm your app handles the resulting error gracefully rather than hanging — see "challenge expired" or "invalid signature" . A declined or failed signature. Confirm your app shows a clear retry path rather than a dead end. MFA/device verification , if you use it — see MFA and device verification — including what happens if the device is offline. Once these all behave the way you expect, move on to the rest of the production readiness checklist .

Question 35

Troubleshoot MFA enrollment

Accepted Answer

See MFA and device verification for how enrollment is supposed to work. If it's not going smoothly: "Enrollment won't complete" Confirm the device has a working internet connection and that biometrics are actually enabled on the device — enrollment needs both to sign the initial binding challenge. "eSIM binding fails" eSIM-bound step-up verification depends on the device's own eSIM being active. If you've recently changed carriers or eSIM profiles, that binding may need to be redone from your device's security settings. Still stuck? Submit a ticket under Account & Access with the device type and approximately when enrollment was attempted.

Question 36

MFA reset and recovery

Accepted Answer

PTERI doesn't have a separate "MFA reset" step distinct from restoring your identity — the two are the same mechanism. If you have your recovery phrase or an encrypted cloud backup This is fully self-service — follow recovering account access to restore your identity on a new or existing device and re-register. If you don't have either Being upfront about where this stands today: because your private key never leaves your device and Kakr Labs never holds a copy, there is currently no guaranteed self-service path back into that specific identity without a backup. If this happens to you, open a ticket under Account & Access — our team will look at what's possible case by case, but a resolution can't be promised without your original key material. The best fix is prevention: set up a recovery phrase or encrypted cloud backup now, before you need it.

Question 37

Change or replace an authentication factor

Accepted Answer

"Changing your authentication factor" in PTERI means moving your identity to a new device. If you still have access to your current device: Install the PTERI Wallet app on the new device Restore your identity using your recovery phrase or encrypted cloud backup — see recovering account access Sign an authentication message on the new device to prove control, then re-register it Once confirmed, treat the old device as no longer authoritative for this identity — if it's lost or you no longer trust it, see responding to a suspected compromised account If you no longer have access to the current device or its backup, see MFA reset and recovery .

Question 38

Respond to a suspected compromised account

Accepted Answer

Rotate or revoke API credentials immediately if any may have been exposed — see rotating and revoking API credentials. Re-register your device identity if you believe your device itself (not just an API key) may be compromised — see changing an authentication factor . Since PTERI's model requires a fresh signature for every sensitive action, an attacker without your physical device and biometrics cannot act as you going forward, even if something else was exposed. Review recent activity in your Developer Dashboard for anything you don't recognize. Escalate to us — open a ticket under Account & Access with severity SEV-2 or higher if you believe an action was taken without your authorization. If the root cause looks like a platform vulnerability rather than a lost device or exposed key, use Report a Security Vulnerability instead.

Question 39

Rotate an API credential

Accepted Answer

Generate a new API key from your Developer Dashboard, without deleting the current one yet. Deploy the new key to your application's environment variables (e.g. PTERI_API_KEY ) rather than hardcoding it — see creating your first API key . Validate that requests using the new key succeed — check the successful field per understanding the API response envelope , not just the HTTP status. Revoke the old key — see revoking an API credential — once you've confirmed nothing is still using it. Rotate on a regular schedule as a matter of hygiene, and immediately any time a key may have been exposed — see responding to a suspected compromised account .

Question 40

Revoke an API credential

Accepted Answer

Revoke a key from your Developer Dashboard when: You're completing a rotation and have confirmed the replacement works The key may have been exposed — committed to source control, logged, or shared An integration that used it is being decommissioned Revocation takes effect immediately — any request still using that key will start failing authentication (see common API errors ). Make sure nothing production-critical still depends on it before you revoke.

Question 41

Rate limits and safe retry behavior

Accepted Answer

Each plan has a request-rate limit — see plan tiers and usage limits for current numbers (Free, Pro, and Enterprise tiers differ significantly). Design your integration to stay under your plan's limit rather than bursting against it. Safe retry behavior Never retry in a tight loop — use exponential backoff between attempts Always check the successful field in the response envelope before deciding whether to retry — see understanding the API response envelope ; retrying a request that already logically failed for a non-transient reason just wastes your rate budget If you're consistently hitting your limit, that's a signal to check whether you need a higher plan rather than retrying harder For the exact shape of a rate-limit response, check your API reference — it isn't duplicated here to avoid this article drifting out of sync with the real behavior.

Question 42

Move an integration from test to production

Accepted Answer

Generate a dedicated production API key rather than reusing a test one — see creating your first API key Confirm the base URL you're calling — Enterprise plans use a dedicated node URL instead of the shared endpoint (see getting started with the API ) Re-run the checks in test authentication before production against the production credential before routing real traffic to it Finish the rest of the production readiness checklist

Question 43

Legacy application integration guide

Accepted Answer

An older application doesn't need a full rewrite to adopt PTERI — the integration path is the same REST API and SDKs described in integrating PTERI into your application , added incrementally alongside whatever authentication your app already has. A common approach: keep your existing session/login system in place initially, and introduce PTERI-backed authentication or step-up authorization for the specific actions or flows that need it most, before expanding further. Being upfront about what's not published yet: there's no dedicated legacy-migration tool or pre-built adapter for common older auth systems today — if your architecture has constraints that make this tricky, open a ticket (Technical / API category) and describe your setup; that's exactly the kind of case that should inform what we build next.

Question 44

Open an effective support ticket

Accepted Answer

The ticket form asks for a specific set of fields because each one saves a round trip: Business email — where we reply; use the one linked to your account if you have one Company/organization — helps us route Enterprise-adjacent questions correctly Request type & product/service — routes the ticket to the right queue immediately Severity — see support severity levels ; be honest rather than optimistic or alarmist Error code & approximate incident time — lets us find the exact failure faster than a vague description Description — what you were doing, what you expected, and what happened instead is worth more than a one-line summary Never include passwords, MFA codes, API secrets, access tokens, private keys, or other credentials in a ticket — see the warning on the form itself. If a screenshot or log would help, link to it rather than pasting raw secrets.

Question 45

Escalating a critical issue

Accepted Answer

Check service status . If it's a known incident, you're already being tracked. Open a ticket with severity set to SEV-1 — Critical production/security outage (see support severity levels ), and a subject line that makes the impact obvious. Include the exact failing request/response (redact any secrets), the approximate time it started, and how widespread the impact is. If it's a suspected security issue rather than an outage, use Report a Security Vulnerability instead — it's reviewed by the security team directly, not the general queue. Being upfront about what's not published yet: marking a ticket SEV-1 gets it triaged with top priority internally, but it is not a contractual response-time guarantee — no formal SLA is published outside individually agreed Enterprise contracts (see Enterprise plans and how to reach us ).

Question 46

Set up MFA on your support account

Accepted Answer

This covers MFA for your support.kakr.ai account — the email + password login you use to track tickets here. It's separate from the device-key authentication your PTERI product identity uses; see how authentication works for that model. Sign in to My Account and open the Security tab. Click Enable PTERI 2FA . A 6-digit verification code is emailed to your account address. Enter the code and click Activate 2FA . What happens after that On future sign-ins, after your email and password, you'll be sent a fresh verification code by email and asked to enter it before your session starts — see MFA and device verification for how the underlying verification works. Turning it off From the same Security tab, disabling 2FA requires your current password plus a fresh verification code sent to confirm the change — this two-step confirmation exists specifically so a stolen password alone can't disable your protection. Trouble enrolling? See troubleshoot MFA enrollment .

Question 47

Phishing-resistant authentication overview

Accepted Answer

"Phishing-resistant" describes an authentication design where there's no reusable secret — no password, no OTP code, no session token typed into a form — for a fake page to capture and reuse. PTERI's device-key, challenge-response model is built this way from the ground up; see why passwordless for the problem this solves and how authentication works for the exact mechanics. What makes it phishing-resistant, specifically The private key never leaves your device — there's nothing to type, so nothing for a phishing page to ask for Every challenge is single-use and short-lived, so even a captured challenge–response exchange can't be replayed later or elsewhere A signature is scoped to the exact action it approves — see how authorization works — so a signature obtained under false pretenses for one action can't be repurposed for another Rolling it out For an existing application adding this model, see integrating PTERI into your application and the legacy application integration guide if you're not starting from scratch. If something goes wrong See "challenge expired" or "invalid signature" for the two most common failure messages, and recovering account access if a device is lost.

Question 48

Protect an API credential

Accepted Answer

Never hardcode it. Set it as an environment variable (e.g. PTERI_API_KEY ) rather than pasting it into source — see creating your first API key . Never commit it to version control , including in config files, notebooks, or commit history you think you've since removed — a rotation is cheaper than trying to fully scrub git history. Never paste it into a support ticket, chat message, or log statement. If you need to show us a request, redact the key first — see safe diagnostic information without sharing secrets . Scope access so only the services that need the key can read it — e.g. via your platform's secrets manager rather than a shared config file. Rotate on a schedule , not just when something goes wrong — see rotating an API credential . If you believe a key has already been exposed, don't wait for the next scheduled rotation — see responding to a suspected compromised account and revoking an API credential now.

Question 49

API error code reference

Accepted Answer

This reference covers the error patterns already documented in this knowledge base — it isn't a full enumeration of every possible response your API reference might return, so check your dashboard's API reference for anything not listed here. What you see Likely cause Fix HTTP 200, but successful: false The request failed logically, not at the transport level Check the message field — see understanding the API response envelope 401 / 403 on every request Missing, malformed, or Bearer -prefixed nodeUrlOrApiAccessKey header Send your raw API key as the header value, no prefix — see common API errors Address creation fails Missing walletName or encryptedPassphrase header on POST /api/Address/create Send both together "Challenge expired" The sign-in challenge's short window elapsed before it was signed Request a new sign-in attempt — see challenge expired or invalid signature "Invalid signature" Signed with a different identity than the one on record Confirm you're using the originally registered identity, or see account recovery Still stuck? Submit a ticket under Technical / API with the exact request and full response body (redact your API key first).

Question 50

Understanding KAKR error messages

Accepted Answer

Whenever a request doesn't do what you expected, check these in order: The successful field , not just the HTTP status — a logical failure can still be HTTP 200. See understanding the API response envelope . The message field — this is where the explanation lives when successful is false . Whether it's a known pattern — check the API error code reference and common API errors before assuming it's novel. Authentication-specific messages like "challenge expired" or "invalid signature" have their own dedicated article: challenge expired or invalid signature . If none of that explains it, submit a ticket with the full response body — see safe diagnostic information without sharing secrets for what's safe to include.

Question 51

Safe diagnostic information without sharing secrets

Accepted Answer

The fastest way to get a ticket resolved is to include the full failing request and response — but a few things should never leave your machine: Never include Your raw API key, password, MFA code, or recovery phrase Another user's personal data beyond what's strictly needed to demonstrate the issue Safe to include The exact endpoint and method (e.g. POST /api/Address/create ) The full response body, including the message field — see understanding the API response envelope The approximate time the request was made Your API key's last few characters only , if you need to reference which key was used — never the full value Redacting a request before sharing it Replace the key's value with something obviously fake, like PTERI_API_KEY=***redacted*** , before pasting a request into a ticket, a log, or anywhere else. See also protecting an API credential .

Browse support articles

All topics