Mementom for developers
Build private recognition and authorization.
Start with the working Aster integration, then use the API reference for the exact requests, identifiers, and results your application sends and receives.
Start here
See it. Understand it. Build it.
The developer area keeps the working demonstration, human explanation, and machine-readable contract together without mixing them into the end-user FAQ.
Integration flow
One request. One protected result.
Your application describes the exact right it wants checked. Mementom handles private proof in its protected window and returns only the result your application is allowed to receive.
- Your server creates a challenge.
Send the application, anonymous customer session, action, resource, consequence, and return details.
- Your browser opens Mementom.
Open the short-lived authorization URL in the protected Mementom popup. Your page never receives the person’s image, phrase, or derived numeric key.
- Mementom verifies private proof.
The person provides the matching original image for the phrase Mementom presents. The browser derives the numeric key again; the original image is not uploaded.
- Your server consumes the result.
Retrieve or receive the opaque completion, validate it, and consume it once for the exact challenge.
Developer FAQ
The implementation questions.
What is the application ID?
It identifies one registered application operated by your company. A company can have more than one application. The API returns the ID when the application is created; your server stores it and sends it when creating challenges.
Where does the customer session ID come from?
Your application creates and owns its anonymous customer session identifier. It should be stable enough to reconnect the same browser or customer relationship in your own system without containing a name, email address, phone number, or other direct identity.
What are the challenge ID and gate request ID?
Mementom creates these opaque IDs when your server creates the request. Store them with your pending action so the returned result can be matched to the exact request. Do not generate or interpret Mementom IDs yourself.
When should the backend start waiting for a result?
Create and persist the pending challenge before returning the authorization URL to the browser. Your server can then receive a webhook or poll by the stored request ID. Because the request exists first, opening the popup does not create a race.
What can the company see?
Your application sees the context it sent, opaque relationship and request IDs, lifecycle status, and the scoped result. It never sees the protected window, image, phrase, key-ring password, numeric image evidence, or proof details.
What does the Aster demo show?
It shows a customer-facing requesting site alongside a developer message log containing only the browser and server messages an Aster developer would send or receive. Use it to understand the sequence before working from the API reference.
Work with us
Bring one real use case.
Tell us what a person should be able to recognize, unlock, approve, or continue—and what your application should receive after private proof succeeds.