igpapi — Instagram private API Simulator for Node.js (API reference) 4.14.0
    Preparing search index...

    Variable TwoFactorApprovalTicketSchemaConst

    TwoFactorApprovalTicketSchema: brand<String, "TwoFactorApprovalTicket"> = ...

    The two-factor screens carry the server-issued values of their flow as opaque tickets: a ticket is a branded string a screen holds and passes on, and the values it stands for — the challenge, the entrypoint and picker screen instances, the QPL pairs the calls must echo — live in the process's ticket registry (tickets.two-factor.registry.ts, one value per runtime layer), exactly as the recovery screens keep their issued params. A ticket issued in one runtime layer is not resolved in another; a screen resolves the same values again on every action, so a repeated action works. A ticket is client state, never a trail argument: the trail records only the edge and the person's input, and a retrace takes the edge again over fresh state. A ticket cannot be re-derived without the answer that issued it, so continuing a 2FA step in another process needs the checkpoint to carry the registries, which its android.two-factor-tickets part does. The login answer's entrypoint handoff is not a ticket and is not issued by any screen: a retrace that starts after that answer must be given it as a precondition, because only the login answer can produce it.