Hi Pi team,
I am building on PiVerify (account: Pi Logistics) and have hit a blocker where a valid, freshly generated sandbox API key is rejected as inactive. I have ruled out all client-side causes and believe this is a server-side key-activation issue. Details below, plus two scope questions and one bug report.
The blocker: 401 on a valid sandbox key
Calling POST /api/v1/kyc_sessions with a sandbox key returns:
401 {"error":"Invalid or inactive API key"}
What I have verified on my side (all ruled out):
- The key is present and read correctly by my server at request time.
- It is 52 characters, begins with
sbx_, no leading or trailing whitespace.
- It is the exact key shown as active on my API Keys page (matched by last 4 characters against what I saved at generation).
- I regenerated the key once and retried; same result.
- Base URL used:
https://backend.piverify-czgzri81fq2lioqn.staging.piappengine.com
- Authorization header format:
Bearer sbx_...
Notably, the hosted dashboard flow works: I have two applicants that reached approved status in sandbox (created via the portal UI). But programmatic API calls with my sandbox key have never authenticated. This suggests API access for my account may not be activated, even though key generation and the hosted flow are enabled.
Could you check whether sandbox API access is active for my account, or whether there is an activation step I am missing?
Two scope questions (blocking my production planning)
-
Non-Pioneer verification. The session API takes only my own external_user_id, with no Pi account reference, and the sandbox applicant flow never prompts for a Pi login. Does this mean PiVerify can verify a person who is not an existing Pioneer, given a valid ID? Or is a Pi account required at some step in the production hosted flow?
-
Ghana Card support. Does PiVerify accept the Ghana Card as a verification document in production? (Confirmation ask; my couriers are in Ghana where it is the primary national ID.)
Bug report
The "Contact Us" form in the PiVerify portal does not send: submitting returns no confirmation and the message does not appear to go through. This is why I am raising these here, following the precedent of A2U issues raised on this repo.
Thanks for any guidance.
Hi Pi team,
I am building on PiVerify (account: Pi Logistics) and have hit a blocker where a valid, freshly generated sandbox API key is rejected as inactive. I have ruled out all client-side causes and believe this is a server-side key-activation issue. Details below, plus two scope questions and one bug report.
The blocker: 401 on a valid sandbox key
Calling
POST /api/v1/kyc_sessionswith a sandbox key returns:401 {"error":"Invalid or inactive API key"}What I have verified on my side (all ruled out):
sbx_, no leading or trailing whitespace.https://backend.piverify-czgzri81fq2lioqn.staging.piappengine.comBearer sbx_...Notably, the hosted dashboard flow works: I have two applicants that reached
approvedstatus in sandbox (created via the portal UI). But programmatic API calls with my sandbox key have never authenticated. This suggests API access for my account may not be activated, even though key generation and the hosted flow are enabled.Could you check whether sandbox API access is active for my account, or whether there is an activation step I am missing?
Two scope questions (blocking my production planning)
Non-Pioneer verification. The session API takes only my own
external_user_id, with no Pi account reference, and the sandbox applicant flow never prompts for a Pi login. Does this mean PiVerify can verify a person who is not an existing Pioneer, given a valid ID? Or is a Pi account required at some step in the production hosted flow?Ghana Card support. Does PiVerify accept the Ghana Card as a verification document in production? (Confirmation ask; my couriers are in Ghana where it is the primary national ID.)
Bug report
The "Contact Us" form in the PiVerify portal does not send: submitting returns no confirmation and the message does not appear to go through. This is why I am raising these here, following the precedent of A2U issues raised on this repo.
Thanks for any guidance.