Frequently Asked Questions

The organisation named in the invitation, such as a law firm or compliance team, needs to confirm an employment or education record for an applicant. The applicant has authorised Yaatra to contact the employer, university, or institution that holds the original information.

Genuine Yaatra requests are sent from requests@yaatra.app and open only on app.yaatra.app. The invitation identifies the requesting organisation and the applicant who authorised the request. If you are unsure, contact the requesting organisation using details from its official website, or check directly with the applicant. Yaatra will never ask for payment, your email password, or credentials from another service.

Yaatra is the secure service used by the requesting organisation to obtain a signed record directly from its source. Yaatra coordinates the request, records the issuer’s confirmation, the applicant’s approval, and the relevant timestamps, and then delivers the signed record to the approved recipient. Yaatra is not the source of the information and does not alter what the issuer confirms.

Review the employment or academic information your organisation already holds and confirm whether it is accurate. You may correct or decline the request if necessary. You are not being asked to make a new assessment, give a legal opinion, or vouch for anything beyond your organisation’s own records. Most requests take only a few minutes.

Do not forward the secure link, because it is unique to you. Reply to the requesting organisation so that the appropriate colleague can be invited securely.

There is nothing to install. The first time you use Yaatra, you set up secure access with a short PIN. The PIN keeps the signing step secure, and can be reused for future requests.

You are responsible only for accurately confirming information held in your organisation’s records and for acting within your authority. You are not responsible for the applicant’s case outcome or for the legal decision made by the organisation requesting the record.

Correct the information or decline the request. Do not confirm anything you do not believe matches your organisation’s records. If the issue needs explanation, contact the organisation that sent the request.

No. It is a request, not an obligation. If your organisation has its own verification policy or preferred process, tell the organisation that sent the request.

The record is signed through Yaatra and sent to the applicant for review. The applicant decides whether to share it with the requesting organisation. You will receive confirmation when the process is complete, and nothing further is required unless the requesting organisation contacts you.

Yaatra confirms the source and integrity of an employment or education record: which issuer account signed it and whether the signed content has changed since. The issuing organisation attests to the information in its own records. Yaatra does not independently decide whether the underlying claim is true, whether the issuer has legal authority, or how much weight the receiving organisation should give the record.

The Verifier is the person or organisation requesting the record, such as an immigration attorney, employer, or compliance team. The Issuer is the employer, university, or institution confirming the record. The Applicant is the person whose information is being confirmed and who controls whether the signed record is shared.

First, the Verifier creates a case and names the applicant and issuer. Second, the applicant sets up secure access and explicitly authorises Yaatra to approach the issuer. Third, the issuer reviews, confirms, and signs the record at source. Fourth, the applicant reviews the signed record and approves sharing it. Finally, the signed record appears in the Verifier’s dashboard with its audit history.

PDFs and emails can still form part of an evidence file, but they do not by themselves provide cryptographic proof of source or detect every later alteration. Yaatra adds a source-confirmed, signed record with applicant approval and a timestamped history. It strengthens existing due diligence rather than replacing professional judgement.

No. The applicant must explicitly approve sharing before the Verifier can access the signed record. Until that approval is given, the Verifier cannot access its content. This control is enforced by the workflow, not left only to policy.

A later status check will show that the record is no longer valid. Revocation allows an issuer to withdraw a record if circumstances change. The original signing event remains part of the audit history so that the sequence of events stays clear.

Yes. Key events, including the request, issuer confirmation, applicant approval, sharing, and revocation, are recorded with timestamps. The audit trail is designed to be append-only: later events are added rather than silently replacing earlier ones.

The issuer can review the information it is being asked to confirm. The applicant can review the signed record, and the requesting organisation can access it only after the applicant approves sharing. Credential content is encrypted for authorised recipients, with access controlled through secure keys associated with those recipients.

No. The issuer reviews and confirms the record. Yaatra records the signed content and its associated events; it is not the issuer and does not rewrite the issuer’s confirmation.

Account deletion is handled in accordance with Yaatra’s Privacy Policy and applicable retention requirements. Some case or audit information may need to be retained to preserve records already shared with another party or to meet legal obligations. The Privacy Policy explains the applicable retention and deletion periods.

Yaatra’s Privacy Policy explains what information is collected, why it is used, how long it is retained, and the choices available to users. For a question about a specific request, contact the organisation named in the invitation.

The signature shows that the record was signed using the key associated with the issuer account identified in the credential and that the signed content has not changed since. It does not independently prove that every underlying statement is true or that the signer has legal authority to make it.

Yaatra encrypts credential content using AES-256-GCM. Separate encrypted copies are created for authorised recipients, so access is not controlled through one shared credential-reading key. A recipient’s secure keys are used to open the copy intended for that recipient.

The W3C Verifiable Credentials standard is an open format for expressing claims in a digitally signed credential. Using an open standard supports interoperability and avoids making the credential format dependent on a proprietary document structure.

A compatible verifier can use the credential’s signature and issuer identifier to check its integrity and signing relationship. Current status or revocation information may still need to be resolved through the status service identified by the credential.

Yaatra records the issuer account and signing identifier used for the credential. It may also display signals such as email-domain alignment and information from public business sources. These signals help a Verifier assess consistency; they do not certify the issuer’s legal authority, institutional legitimacy, or the truth of the underlying claim.

The PIN protects access to secure signing or record-opening actions. A recovery code is provided so the user can restore secure access if needed. If secure keys must be replaced, affected records may need to be re-confirmed or reissued so that their signatures remain valid.

Revocation adds a later status event showing that the record should no longer be treated as valid. It does not erase the original signature or silently rewrite the earlier history. This preserves a traceable sequence of issuance, sharing, and later status changes.