How we handle your credentials and data

Encryption at rest

Every credential you enter — your Salesloft API key and each enrichment provider's API key — is encrypted before it's stored, using AES-256-GCM envelope encryption. Each encrypted blob is tagged with the version of the key that encrypted it, so the encryption key can be rotated later without breaking access to anything encrypted under a previous version.

Encryption in transit

All traffic between Pulsar Enrich and Salesloft, your enrichment providers, our email provider, and your browser happens over HTTPS/TLS. We don't accept plaintext connections for any of it.

How credentials are handled

A provider API key is decrypted only in memory, only at the moment we're about to make the API call it's for, and only by the process handling that job. It's never written back out in plaintext, never included in logs, and never re-displayed in the dashboard after you paste it in. Rotating a provider key means revoking the old one and adding the new one; the Salesloft key is updated in place because the whole connection depends on it.

Sign-in

There are no passwords for team accounts. Signing in means entering your Salesloft email; if it matches an active Admin on a connected team, we email a one-time link and a 6-digit code, both valid for 30 minutes. The code is capped at 5 attempts. The link requires an actual click to complete sign-in — we deliberately don't sign you in the moment the link is opened, because some corporate email systems automatically visit links in incoming mail to scan them, which would otherwise burn the one-time link before a person ever saw it.

Tenant isolation

Every table that holds tenant data — connections, credentials, cadence configs, enrichment jobs, audit log — is scoped by a tenant ID, and every dashboard session is bound to one tenant at sign-in. The one exception is our own internal operator login, used by PulsarGTM staff to provide support, which is a separate path not available to customer sign-in. We currently rely on this scoping being applied consistently at the query layer; a dedicated automated test suite that actively tries to read or write across tenant boundaries is in progress.

Webhook verification

Salesloft webhook deliveries are verified with an HMAC signature check against a callback token generated uniquely per tenant at connection time, so a request can't be spoofed as coming from Salesloft without that token.

What we write to Salesloft

By default a waterfall only writes to a field that is currently blank. Overwriting an existing value is an explicit per-waterfall (or, for custom field waterfalls, per-field) setting that you choose. Every write is logged with the provider that produced it, the cost, and the time.

Pulsar Connect and your call data

Connect reads your team's calls from Salesloft: outcome, time, rep, cadence step, the phone field dialled, and the caller ID the call went out on. Prospect phone numbers are pseudonymised with a salted SHA-256 hash before they're stored, and Connect keeps no plain-text copy. Your team's own outbound caller IDs are stored as numbers, because the Caller IDs page reports on them. Everything Connect shows in your dashboard comes only from your own team's calls.

To score numbers, Connect pools call outcomes for the same hashed number across customers, so a number your team has never dialled can still be scored. That pooling happens only through the hash. No customer can see another customer's calls, people, numbers or reports. Connect writes back to Salesloft only its own fields: pulsar_best_number_type, pulsar_best_number_tier and pulsar_best_number_date, and, if you switch it on, pulsar_best_call_time and pulsar_best_call_days. The best-number fields are merged onto what's on the record. Best times go as Salesloft bulk jobs that change only those two fields. Your other custom fields are never touched.

If you switch on wrong-number repair, Connect removes a flagged number from the person's phone field, leaves a note on the person showing only the number's last four digits, and asks Enrich for a replacement. Each person and number is only ever repaired once. If you choose, the removed number and the reason are written to two fields on the person in Salesloft, in the same update that clears it, so the number you paid for stays on your record; Pulsar itself does not keep it. A separate field can show each person's number flags (for example “Mobile phone: Wrong number”), which Pulsar works out from the hashed call history above.

Pulsar Import and your files

To match a file to your Salesloft records, Import keeps an index of each person's and account's match fields: email addresses, domains, LinkedIn URLs and CRM IDs. These are stored only as salted HMAC-SHA-256 hashes scoped to your team, never in plain text, and are only ever compared within your own team. The index is loaded once from Salesloft and kept current by the same sync that serves Connect.

The rows from a file you upload, and the previous values an import replaced (kept so the import can be undone), are deleted 30 days after the import finishes; only the totals are kept. Import writes only the fields you mapped, only when a value actually changes, and reads each record just before writing it so custom fields and tags are merged rather than replaced. Records an import created can be removed again by undoing it.

Recurring imports read a Google Sheet or CSV link you give them, or rows sent to a webhook address that is unique to that import and acts as its secret. Rows sent to a webhook are held only until the next run, minutes later. To skip rows it has already imported, Import keeps a SHA-256 fingerprint of each imported row's mapped values for a year, never the values themselves.

Pulsar Automate

Automate works from data Pulsar already holds: your calls (with prospect numbers hashed, as above), which account each person belongs to, and each account's fields, so it can copy them onto people. For cadence flags it keeps a light record of who is on which cadence (the membership, person, cadence and rep IDs, and when they were added), kept current from Salesloft. For roll-ups from people it keeps the value of only the person fields your Smart Fields use, and forgets them when no Smart Field needs them. It writes only the fields you set up, as Salesloft bulk jobs that change only those fields. A Smart Date is never moved backwards, so a later date typed in by hand is left alone.

Pulsar Insights

Insights works from the calls Pulsar already holds (prospect numbers hashed, as above), plus two light records it keeps from Salesloft: which rep added which person to a cadence on which day, and for each email sent, its ID, sender, recipient's Salesloft ID and cadence, when it was sent and whether it bounced, was opened or got a reply. It never stores email subjects or bodies. Both are kept for about 13 months, then deleted. Dashboards keep only their own settings: their name, tiles and formulas, and who they open on. Insights only reads from Salesloft; it writes nothing back.

Infrastructure

The application, background worker, Postgres database, and Redis queue all run on Railway. We don't run our own servers or data centres; we inherit Railway's platform-level security practices for the infrastructure layer.

Roadmap — what's next, stated honestly

A few things we know are worth doing and haven't shipped yet:

• An automated, DB-backed tenant-isolation test suite that actively attempts cross-tenant reads and writes and asserts they fail.
• Per-tenant credit caps and rate limiting on enrichment jobs.

Reporting a security issue

If you find a security issue, please email security@pulsargtm.com rather than filing it publicly. We'll acknowledge and follow up as quickly as we can.