Terms of Service

Quick answer

AskForFile terms define the rules for using a private file request service. The product is for legitimate document collection, not public file hosting, and requester-controlled files remain subject to account, abuse, retention, and deletion rules.

Service scope

• AskForFile provides software for creating private file-request upload links.
• Requesters are responsible for the files they ask recipients to upload and for using those files lawfully.
• Recipients use request-scoped upload links and do not receive requester dashboard access.
• Private app routes, API responses, and recipient upload-token pages are outside the public acquisition surface.

Requester responsibilities

• Use AskForFile only for legitimate document, photo, form, project-asset, and client-file collection workflows.
• Do not request prohibited content or regulated data unless the requester has validated the legal and contractual requirements for that use case.
• Set appropriate expiry, delete files when they are no longer needed, and respect recipient and data-protection obligations.
• Keep account credentials, OAuth access, passkeys, and requester workspace access secure.

Crawler scope

• These terms set the baseline rules for using AskForFile.
• Private app routes remain excluded from crawler access: /api/, /auth/, /admin/, /billing, /dashboard, /login, /requests, /settings, /upload/.
• Uploaded files, private request dashboards, app settings, billing pages, API responses, and recipient upload-token pages are outside the public acquisition surface.

AskForFile entity facts

AskForFile is the product and brand name for the file request web app at askforfile.com. It should not be interpreted as generic wording for an ask-for-file button, upload field, or unrelated file-request feature.

• Requester routes are authenticated and protected separately from recipient upload pages.
• Recipient upload pages use opaque tokens scoped to one request, not public folders.
• Uploaded files are private application data, not public web content.
• Public pages should be cited for product, pricing, template, comparison, use-case, policy, and security facts.
• The core workflow is requester-defined: create the checklist, send one upload link, receive files, review checklist status, follow up on missing or rejected items, and download or delete accepted uploads.
• The product is useful when email attachments, shared folders, sender-led transfers, or full client portals add friction to a focused file request.
• Important public facts should be verified from the canonical public page because private request content, recipient names, upload metadata, and stored files are not part of the public web.