Privacy & document handling

Scope and contact

This notice covers FourAPI. Abdimajid AHMED ALI operates the FourPoint Technology project and can be contacted at support@getfourpoint.com for privacy enquiries. The main FourPoint website and other services have separate privacy notices.

FourAPI processes developer applications, invitation-only accounts, security checks, support messages and document conversions. No marketing subscription is created by applying or accepting an invitation. No payment details are collected by the current free service.

What information we collect and why

Applications require first name, last name, email, a project description and acknowledgements of individual-access conditions and privacy information. The operator reviews them manually to assess requested access and send invitations. Applying does not create an account, reserve a place or grant platform ownership. Anonymous resubmission cannot overwrite an existing application. Do not include confidential documents, passwords, API keys or sensitive personal information in a description.

Activated accounts store a profile name, verified email, account/access status, invitation and review information, and versions and timestamps of accepted terms and privacy acknowledgements. Names can be corrected in Profile; the invitation email is read-only there. This information provides the requested service and administers access.

Passwords, password changes, email verification and optional authenticator enrolment/verification are handled directly by Supabase Auth. They are not sent to the FourAPI conversion/account API. The portal displays a private authenticator setup QR/key during enrolment. Do not share setup keys or one-time codes. Owner operations require authenticator verification; sensitive developer account/key operations also require it when enabled.

API-key records contain the key name, prefix, hash verifier, creation time, optional expiration and revocation status/time. Complete keys are shown once rather than stored in FourAPI tables. No-expiration keys remain subject to revocation and account restrictions. Expired keys cannot authenticate new catalogue requests or conversions.

Conversion metadata records the account when applicable, a pseudonymous key/capability identifier, selected tool, UTC timing and processing state, plus daily quota counters. Documents, uploaded filenames and full credentials are not intentionally recorded in those tables or application logs. Server failures produce a minimal hosting log containing an event label, HTTP status, bounded error code and random request reference for troubleshooting; no document contents, email addresses, full credentials or request URLs are included. Hosting-provider log retention applies separately. Playground conversions share the account’s existing allowance and create the same metadata, not a new account or permanent key.

Contact forms collect name, email, message and privacy acknowledgement to respond to the enquiry. Service email-delivery records and owner audit records support administration and security. Requested access and enquiries support the steps and service you request; security checks and restricted review records support the legitimate interest in safely operating the service. Acknowledging a notice is not consent to marketing or a waiver of rights.

Uploaded documents and converted results

The twelve hosted conversions receive document bytes over HTTPS and return converted output. FourDOC sends these bytes directly to the FourAPI endpoint, rather than through a FourPoint website conversion proxy. Existing browser-only FourDOC tools have a separate on-device processing flow. Hosted document bytes are processed by FourAPI’s Python engines on Render; they are not sent to an external conversion vendor or an AI model for training.

The conversion implementation intentionally creates no uploaded-document, converted-result or server-download document files. Input and output pass through process memory, in-memory buffers and anonymous Python worker pipes. The response uses Cache-Control: no-store. Separate worksheet files are returned inline in the same response, not retained behind later download URLs.

The conversion worker exits after completion or is killed if its processing exceeds the configured 60-second deadline. Upload and response-transfer time are separate. The parent process can hold document bytes while validating and sending the response; Python and the operating system determine later memory reuse. There is no verified promise of complete secure erasure or deletion within exactly 60 seconds. Hosting buffers, operating-system swap, crash dumps, infrastructure logs and provider backups have separate controls and lifetimes.

There is no retained server result to retrieve later, so another conversion may use another allowance. The playground holds result blobs in the browser until cleared, navigation away or page closure; it revokes its download URLs when clearing. Downloaded files remain where the recipient saves them. Files retained by a developer’s own application are governed by that application’s practices. We cannot delete those copies by clearing a FourAPI account.

Retention and deletion of metadata

Conversion request metadata older than 30 days is removed by the existing owner-dashboard cleanup. Aggregate daily service/form counters have a 30-day housekeeping window; website counter cleanup runs when hosted website usage is reserved. These are request-driven operations and can be delayed by inactivity, not guaranteed deletion exactly on a scheduled day.

Email-delivery records older than 90 days and key verification records more than 90 days after revocation are eligible for the existing owner-dashboard cleanup. An expired key is unusable but is not automatically classified as revoked or erased; revoke it or close the FourAPI account to start the applicable removal flow.

Pending applications become eligible after 180 days from creation; declined/revoked applications after 180 days from review. Owner audit records become eligible after 180 days. Resolved contact-form messages become eligible 180 days after resolution. Open messages remain until resolved or handled through a rights request. An unactivated profile created only for a removed unsuccessful application is removed with it when it has no other dependencies.

Active profiles remain until account closure. Approved legacy applications remain with their account; new revoked application records follow the 180-day review policy. Expired invitation reservations release capacity but do not by themselves erase selected applications. Email correspondence outside the contact-form database is reviewed separately while needed for an enquiry, follow-up, legal obligation or dispute.

Account deletion requires password reconfirmation, authenticator verification when enabled and typing DELETE. Once the deletion transaction succeeds it removes the FourAPI profile, applications/invitations, API keys, personal conversion history, allowance records and associated contact messages, and releases developer access. Owner accounts must transfer responsibilities first. Already admitted requests may finish; future admission fails.

FourAPI-only deletion deliberately does not delete the Supabase authentication identity, separate waitlist records, downloaded documents, provider backups or separately retained security audit records. Contact support to request closure of the sign-in identity or other services as well; dependencies and provider retention require separate handling. Revoking developer access is different from deleting a profile.

Providers, security checks and storage

Render hosts the static portal and Python API. Supabase handles authentication and the FourAPI database within the selected project, which also contains separate waitlist records. Brevo handles configured invitation, recovery and service-email delivery. Cloudflare provides domain delivery and Turnstile checks. These providers receive the connection and service information required for their roles; their infrastructure logs, subprocessors, backups, locations and transfer safeguards have separate lifetimes that the operator must verify and maintain.

Turnstile receives browser and connection information for application/contact checks and public FourDOC conversion-session checks. Public FourDOC access uses a short-lived, one-use, tool/origin-bound capability and does not create an account or consume a developer place. The signed-in playground uses a separate 90-second, one-use capability bound to its verified account, tool and portal origin. Token verifiers are held in bounded process memory; expiry prevents use but does not certify secure memory erasure.

The portal keeps essential account sessions in this tab’s sessionStorage, with page-memory fallback when storage is unavailable. Signing out clears the portal session; browser restoration can have separate effects. No advertising or audience-analytics script is included in the FourAPI portal. Brevo may record delivery, opening and click events depending on configured provider tracking; FourAPI does not import open/click webhooks for advertising or recipient profiling. Provider tracking settings must be reviewed separately.

Your rights and contact

Depending on the processing and applicable law, you may request access, correction, erasure, restriction or portability, or object to processing. Consent can be withdrawn where consent is the legal basis. Contact support@getfourpoint.com. We respond without undue delay, normally within one month, explaining any permitted extension. You may complain to the relevant supervisory authority, including the CNIL in France.

Developers are responsible for their own users’ notices, authority to process documents and applicable controller/processor arrangements. The data-processing information page is not an executed processing agreement or a certification of GDPR compliance. Do not submit customer personal data without the arrangements required for your use.