How it works Features Pricing API Log in Start free

Security overview

Last updated: 7 May 2026

1. Overview

This page summarises how Aptly handles security across our infrastructure, the data we process, and the controls we have in place. It is intended for technical reviewers, IT teams, and anyone evaluating Aptly for use in a corporate hiring workflow. For full legal terms see our Data Processing Agreement and Privacy Policy.

Aptly is operated by Black Wolf Analytics (Pty) Ltd, a South African company. The Aptly platform is hosted in Frankfurt (EU Central) on Render.com infrastructure.


2. Hosting and infrastructure

The Aptly application and database are hosted on Render.com, in their Frankfurt (EU Central) region. Render is SOC 2 Type II certified and ISO 27001 certified. Their current attestations are listed on Render's security and compliance page.

Custom domain TLS termination is handled by Render's edge infrastructure (which uses Cloudflare). Certificates are issued by Let's Encrypt or Google Trust Services and renewed automatically. All HTTP requests are redirected to HTTPS.


3. Encryption

In transit. All connections between users, integrators, and the Aptly platform are encrypted using TLS 1.2 or higher. This applies to the web app at app.aptly.pro, the marketing site at aptly.pro, and the API at api.aptly.pro.

At rest. Aptly's PostgreSQL database is hosted on Render's managed Postgres service, which encrypts data at rest using AES-256. The same encryption applies to backups. Backups are retained for up to 35 days under Render's standard backup policy.


4. Authentication

App users. Passwords are hashed using bcrypt via the passlib library. Plain-text passwords are never stored or logged. Authenticated sessions use JSON Web Tokens (JWT) with a 30-day expiry, signed with HS256. Users may also sign in with Google via the standard OAuth 2.0 authorisation code flow.

API integrators. The Aptly Intelligence API authenticates requests via a per-account API key passed in the X-API-Key header. API keys are generated by SHA-256 hashing on creation; the full key is shown to the user once and the hash is stored in the database. Aptly cannot retrieve a lost key; lost keys must be revoked and replaced. Each account may hold up to 5 active API keys.


5. Data flow on the API path

When a candidate CV is submitted via POST /api/v1/screen:

  1. The request is validated against the API key, then against the request schema (job spec non-empty, 1-200 candidates, unique candidate references).
  2. The first 10,000 characters of each CV are sent to Anthropic's Claude API for scoring. Anthropic does not retain or train on API inputs (see Anthropic's API terms).
  3. Scoring results (score, verdict, match reasons, gaps) are stored in an api_jobs record, alongside the original candidate_ref. The CV text itself is not persisted to the candidates database on the API path.
  4. Results are made available via GET /api/v1/jobs/{job_id} polling or delivered to the integrator's webhook endpoint if webhook_url was supplied. Webhook delivery is attempted up to 4 times (initial attempt plus 3 retries with 5s, 30s, and 120s backoff).
  5. Results expire 72 hours after submission. Expired records are inaccessible via the API and are periodically purged.

Embeddings are not generated on the API path. The candidates database is not written to. The CV text exists only in memory during scoring and in the request and response payloads.


6. Data flow on the app path

When a recruiter uploads a CV through the Aptly web app:

  1. The file (PDF, DOCX, or text) is received as a multipart upload. Text is extracted in memory; the original file bytes are not written to persistent storage.
  2. The extracted text is sent to Anthropic's Claude API for scoring against the job specification.
  3. A vector embedding is generated for the candidate using OpenAI's text-embedding-3-small model. OpenAI contractually does not retain or train on API inputs.
  4. The candidate record (name, email, phone, CV text, embedding, scoring results) is stored in the candidates table, scoped to the recruiter's organisation.
  5. The candidate record is retained for the lifetime of the organisation's account, allowing the recruiter to search past candidates against new roles.

Recruiters can delete individual candidate records, screening histories, or jobs from within the app at any time. Account-level deletion is covered in section 8.


7. Sub-processors

Aptly uses the following sub-processors to deliver the Service. Full details, including DPAs and Standard Contractual Clauses where applicable, are in our Data Processing Agreement.


8. Data retention and deletion

Account data, including candidate records, screenings, and applications, is retained for the lifetime of the organisation's account. On a verified deletion request, the account is deactivated immediately and hard-deleted from the production database within 30 days. Backups containing the data are retained for up to 35 days and are subject to the same deletion timeline once they roll out of the backup window.

API job results submitted via POST /api/v1/screen are retained for 72 hours, after which they become inaccessible and are periodically purged.

Full retention and deletion terms, including legal exceptions required by Stripe and South African tax law, are in section 9 of our Data Processing Agreement.


9. Data subject rights

Aptly's processing of personal data is subject to the South African Protection of Personal Information Act (POPIA) and the EU General Data Protection Regulation (GDPR). Candidates and account holders have rights of access, rectification, erasure, restriction, and portability under both regimes.

Requests can be made to hello@aptly.pro. We respond within 30 days. Full details of how requests are handled are in our Privacy Policy.


10. Incident response

Security issues, suspected vulnerabilities, or data incidents should be reported to security@aptly.pro.

In the event of a confirmed personal data breach, Aptly will notify affected Controllers and supervisory authorities within 72 hours of becoming aware of the breach, in line with GDPR Article 33 and POPIA section 22. Notifications will include the nature of the breach, the categories and approximate number of affected data subjects, the likely consequences, and the measures taken or proposed to address the breach.


11. What we don't do


Questions about anything on this page? Email security@aptly.pro.