Your records go org to org.
Not through us.

Your data never touches our database

When SwiftPort syncs a record, it reads the record from your source org via Salesforce API, maps the fields in memory, and immediately writes it to your target org via Salesforce API. Nothing is persisted on our infrastructure. Not a field value, not a record ID mapping, not a name. We store only sync configuration (which fields to map), execution logs (timestamps, record counts, error codes), and encrypted OAuth tokens.

We orchestrate — we never hold

Most integration platforms act as a data broker — your records flow into their platform, get transformed, then flow back out. That means your customer data lives on a third-party server momentarily. SwiftPort's architecture is different: our worker reads a batch of records from Salesforce, maps them in memory, and sends them directly to the target org in the same process — there is no intermediate storage step.

Bank-grade encryption at rest

OAuth access tokens and refresh tokens that grant access to your Salesforce orgs are encrypted using AES-256-GCM before being stored in our database. The encryption key is stored separately from the encrypted data. Even in the event of a database breach, your Salesforce credentials cannot be decrypted without the separate key.

Your password never comes near us

You connect your Salesforce org through the standard OAuth 2.0 authorization flow — the same flow used by Salesforce's own tools. You log in directly on Salesforce's login page, not ours. SwiftPort never sees your username or password. We receive a scoped access token that you can revoke at any time from within Salesforce. PKCE (Proof Key for Code Exchange) is enforced on every authorization request, protecting against authorization code interception attacks.

Your data is architecturally inaccessible to others

Every table in SwiftPort's database has Row Level Security (RLS) policies enforced at the database engine level. This means that even if a bug existed in our application code, a customer's sync configurations, connected orgs, and logs are inaccessible to any other customer. The isolation is enforced by the database, not just application logic.

No record ID mapping table — ever

To track which records have been synced and avoid duplicates, SwiftPort uses Salesforce's native External ID mechanism. A custom field (SwiftPort_Source_Id__c) is created on your target object in Salesforce, and Salesforce itself handles the find-or-create upsert logic. This means we never maintain a table mapping source record IDs to target record IDs — another potential source of sensitive metadata that we simply don't store.

Access that expires and can be cut off instantly

Salesforce OAuth tokens expire and are automatically refreshed using refresh tokens stored in encrypted form. You can revoke SwiftPort's access to your org at any time from Salesforce Setup → Connected Apps, or directly from the SwiftPort portal. Revoking access immediately prevents any further sync operations for that org.

Access only what's needed — nothing more

SwiftPort requests only the OAuth scopes required to read from your source org and write to your target org. We don't request admin permissions, metadata access beyond field creation, or any scope that isn't directly needed for sync to function. You can inspect exactly what was granted from Salesforce Setup → Connected Apps at any time.