FAQ & help center for pet welfare in India

The platform uses OTP-based authentication. During signup, you provide username, email, phone, role, and consent fields. OTP is sent to your email for verification. Returning users use login and verify with OTP to receive access tokens.

Phone is your account identity anchor and email is used for OTP delivery, communication, and account recovery workflows. Both are verified to reduce impersonation and fraud.

Use resend OTP. If the previous session is stale, restart login/register to create a fresh OTP session. The system invalidates older OTP hashes when new ones are issued.

No. Email, phone, and username uniqueness checks are enforced. If one is already in use, update your details or use login for that account.

Access tokens expire by design. Re-authentication protects account safety, especially for rescue/adoption and profile operations that involve sensitive records.

Check spam/promotions, confirm the email entered is correct, and wait a short cooldown before requesting another OTP. If repeated attempts fail, contact support with the email, phone, and timestamp.

In most cases yes, but high-trust fields may require re-verification. Any change to identity anchors should trigger security checks to prevent account takeover.

No. Pet owners have lighter onboarding. NGO/Vet/Volunteer flows include role-specific profile sections and document checks before full activation.

Typical statuses include Registered, Profile Completed, Documents Uploaded, Under Review, and Active. Until Active, some role-specific actions may be restricted.

You can correct details and re-submit required fields or documents. Use support if the reason is unclear.

Your account has one primary role at a time for workflow integrity. If you need a role change, contact support and provide verification details.

Review time varies by role, document quality, and queue volume. Incomplete or unclear submissions take longer, so upload readable and accurate details the first time.

Some baseline features may be visible, but role-sensitive actions (for example listings, rescue operations, or certain profile capabilities) can remain restricted until activation.

Full name is your human-readable identity on profile views. Username is unique and used in public profile URLs and account references.

The form checks username availability while typing and re-validates on submit to avoid race conditions.

Public profiles are available at /profile/{username}. Guest users can open these links without login.

Yes. Share actions are designed to use /profile/{username}, not /my-profile.

Yes. Public profile payloads are intentionally limited and should not expose private contact data by default.

Your public URL is tied to the current username. After rename, share the new link to avoid broken bookmarks and old references.

No. Public pages are designed for controlled visibility and generally show only selected identity and profile context, not private operational history.

Signed-in users whose accounts have listing permission can create and manage adoption listings. Access is role-agnostic at the product level—adopter, volunteer, vet, NGO, or other roles can list when that capability is enabled for the account.

Self-application is blocked to prevent misuse and preserve trust in adoption workflows.

Common statuses include Submitted, UnderReview, Approved, and Rejected. Listers can review details and update status based on policy.

Yes. Adoption applications support question-based inputs managed in master data, and required responses are validated.

Incoming application routes require authenticated roles and listing ownership checks. Unauthorized access returns permission errors.

Yes, subject to platform rules. Core listing fields can usually be updated, but major changes should remain transparent to applicants to keep trust intact.

Status transitions should be reflected in applicant-facing views. If communication is delayed, applicants can check their dashboard or contact support for clarity.

Rescue workflows prioritize fast reporting, role-based visibility, and status progression so teams can coordinate from report to closure.

Yes. Rescue workflows are designed around case updates and team handoffs, so timeline continuity is preserved.

Where needed, approximate location fields are captured to route rescue support while minimizing unnecessary precision in public contexts.

Visibility is role- and workflow-dependent. Sensitive data should remain scoped to involved responders and authorized stakeholders.

Operationally yes, where workflow supports it. Reassignments should preserve audit context so future responders understand what has already been done.

Use timeline and location context to deduplicate related reports where possible. This helps avoid fragmented response and duplicated field effort.

No. Payment instruments are handled by integrated payment providers. Platform records store transaction references and operational metadata.

Contact support with transaction ID, amount, and reason within the published refund window. Requests are reviewed case-by-case.

If funds are already disbursed to campaigns/rescue operations, reversal may not be possible. Final decision depends on transaction state and policy.

See /privacy-policy (Privacy & Refund Policy section) for current refund process details and timelines.

Use the transaction reference from your receipt or payment confirmation screen. Support can cross-check status using this ID and event timestamp.

Sometimes provider callbacks are delayed. Wait briefly, refresh your transaction history, and contact support with payment reference if status remains unclear.

Public profiles intentionally expose limited fields (for example name/username, role, bio, broad location context) and should not expose private contact channels.

Use in-app reporting/support channels. The platform supports moderation workflows, including user reports and review statuses.

Yes, you can request deletion. Some records may be retained for legal, payment, or security obligations for a limited duration.

OTP verification, token expiration, guarded endpoints, and role checks are used to reduce unauthorized access.

Only according to your consent choices and applicable law. Operational and safety notifications may still be sent where service-critical.

Update editable fields in profile settings. For protected records, raise a support request with clear correction details and any supporting documents.

Confirm you used the latest OTP, correct email+phone pair, and that the code is not expired. If needed, request a fresh OTP and retry.

Usernames are globally unique. Choose another handle; availability checks run live and again on save.

Verify the exact username in /profile/{username}. Username typos, stale links, or recent renames can cause 404.

Refresh the page/session and retry. If cache appears stale across devices, contact support with the account and timestamp of update.

Use Contact Support and include steps to reproduce, expected vs actual behavior, timestamp, and screenshots.

This usually means your session expired or your current role lacks permission for that action. Re-login first, then verify role eligibility for the feature.

Search matches question/answer text. Try shorter keywords, alternative terms, or clear punctuation-heavy phrases for broader results.