Security at Feedalto

Last updated: August 2026

Feedalto captures open-house and buyer activity for real estate professionals and, when an agent connects one, synchronises the qualified part of it into their existing CRM. That means we handle two kinds of sensitive data: consumer contact information collected at an open house, and credentials to systems we do not own. This page describes how both are protected.

Infrastructure and hosting

Feedalto runs as a containerised ASP.NET Core application on Microsoft Azure, with data in Azure SQL Database and files in Azure Blob Storage. We do not operate our own datacentres or physical hardware; physical and environmental security is inherited from Microsoft Azure and covered by their compliance programme.

• Application and database are deployed in Azure and administered through Azure role-based access control.
• Azure SQL Database encrypts data at rest by default (Transparent Data Encryption).
• Azure Blob Storage encrypts data at rest by default (AES-256, service-managed keys).
• Application diagnostics and availability monitoring run through Azure Application Insights.

Encryption in transit

• All traffic to www.feedalto.com is served over HTTPS. Plain HTTP requests are redirected.
• HTTP Strict Transport Security (HSTS) is enabled in production, so a browser that has visited us once will not downgrade to HTTP afterwards.
• All outbound calls to CRM providers and other third-party APIs are made over HTTPS.
• Outbound webhook subscriptions must use HTTPS. Plain-HTTP destinations are rejected at the point of subscription, not silently downgraded — the payload contains a consumer's name, email and phone number.

Secrets management

No production secret is stored in source control. Configuration files contain only non-secret values — endpoints, feature flags, publishable keys — with the secret entries left blank and annotated with the name of the vault secret that supplies them.

• All application secrets live in a dedicated Azure Key Vault and are loaded at startup.
• The application authenticates to Key Vault as a service principal using a client certificate, or by managed identity. The certificate password is supplied at runtime through the environment and is never committed.
• The service principal is granted the minimum Key Vault role required to read secrets.
• A missing secret causes the dependent feature to report itself unavailable rather than falling back to an insecure default.

Authentication and access control

• Passwords are never stored. Feedalto uses ASP.NET Core Identity, which stores a salted PBKDF2 hash with per-user salts.
• Session cookies are HttpOnly and SameSite-constrained, so they cannot be read by page scripts and are not sent on cross-site requests.
• Mobile apps authenticate with short-lived JWT access tokens plus a separate refresh token. Access tokens are validated for issuer, audience, lifetime and signature, and the token type is checked explicitly so a refresh token cannot be presented as an access token.
• Roles and permissions are resolved through a single centralised capabilities service rather than being re-derived at each call site, so an authorisation rule cannot drift between two screens that ought to agree.
• Tenant isolation. Every query for agent-owned data is scoped by the signed-in user's identity taken from the authenticated principal — never from an identifier supplied in a form or URL. Record identifiers say which record; they never establish whose it is.
• Requests for a record belonging to another account return the same response as a request for a record that does not exist, so the API cannot be used to confirm that another agent's data is present.
• Cross-site request forgery protection is applied to state-changing form posts, with the antiforgery key ring persisted outside the container so it survives restarts and is shared across instances.

How Feedalto handles CRM credentials

This is the part that matters most to a CRM partner, so it is described in detail.

• OAuth 2.0 wherever the provider supports it. Feedalto uses the authorization code flow, with PKCE (S256) where the provider supports or requires it. Agents authorise Feedalto on the provider's own consent screen; Feedalto never asks an agent for their CRM username and password.
• Minimum necessary scopes. We request only the scopes a connector actually uses. Where an optional capability's scope is not granted, that capability is skipped and reported to the agent — the connection is not failed and the scope is not re-requested opportunistically.
• Tokens are encrypted at rest using ASP.NET Core Data Protection with a key ring held in Azure Blob Storage, on top of the database's own at-rest encryption. Encryption and decryption pass through a single component, so every place a CRM credential can be read or written is enumerable in the codebase.
• Tokens never reach the browser or the mobile app. Connection records are projected into view models that contain no credential field, so there is no code path by which a token could be serialised to a client.
• Tokens never appear in logs. Integration logs record the HTTP method, the request path without its query string, the status code, the duration and a correlation identifier. Request and response bodies are never logged.
• CSRF protection on the OAuth handshake. The state parameter is a signed, tamper-evident value carrying a nonce, the initiating user, the target provider and an issue time. It is validated for all four on the callback and expires after fifteen minutes.
• Refresh and rotation. Tokens are refreshed ahead of expiry. Where a provider rotates refresh tokens, the new token is always persisted.
• Disconnect revokes. Disconnecting calls the provider's revocation endpoint where one exists, deletes the stored credentials immediately, and cancels any queued work for that connection.
• Per-agent, never pooled. Each agent's connection is separate. There is no shared or blanket credential that could reach more than one CRM account.
• Rate limits are respected. A provider's Retry-After is honoured as sent, and the connection is skipped until that window passes rather than being retried against.

What Feedalto sends to a connected CRM

Feedalto sends a deliberately narrow record, and the narrowness is enforced in code rather than by policy: connector code can only read a fixed, provider-neutral contact structure, so it cannot transmit a field that was never placed in it.

Sent: name, email, phone, lead source, the properties the person visited with dates, whether they submitted feedback and a summary of it, whether their identity was verified at check-in, whether they stated they are working with another agent, whether they asked to be contacted, an engagement score, the agent's own notes on the record, and a link back to Feedalto.

Never sent: family or household collaboration notes, lender advice threads, internal Feedalto analysis, other agents' data, payment information, or any record belonging to a different Feedalto account.

Consent state travels with the record. If a visitor did not give express consent to be contacted, that fact is stated in what we send, because the CRM is where outreach actually happens and an agent whose CRM does not know should not be left to assume.

Automatic synchronisation is off by default on every new connection. Nothing leaves Feedalto until an agent turns it on, and buyers who indicated they are already represented by another agent are excluded by default even from a manual send.

Feedalto's own API and webhooks

Agents can issue API keys so platforms such as Zapier can read their data and subscribe to events, without any external system being given database access.

• API keys are generated from a cryptographically secure random source and stored only as a SHA-256 hash. The key is displayed once, at creation, and cannot be recovered afterwards — only revoked and replaced.
• Keys carry explicit scopes, are rate limited per key, and can be revoked at any time. Revoking a key also disables the event subscriptions it created.
• Keys are accepted in an authorization header only, never in a query string, so they do not end up in server logs, proxy logs or browser history.
• Outbound webhooks are signed with HMAC-SHA256 over a timestamp and the request body, using a per-subscription secret. Because the timestamp is part of the signed material, a captured delivery cannot be replayed outside the receiver's tolerance window.
• Subscription destinations are validated before any data is sent: HTTPS is required, and loopback, private-range and link-local addresses are rejected to prevent server-side request forgery.
• HTTP redirects are not followed on integration or webhook traffic, so an authorization header or a consumer's data cannot be forwarded to an unintended host.
• Write operations honour an idempotency key, so a retried request does not create duplicate records.

Application security

• Database access is through a parameterised data-access layer; user input is never concatenated into queries.
• Public sign-in and lead-capture forms are protected by rate limiting, timing and honeypot checks, and CAPTCHA verification.
• User-supplied content rendered in email is sanitised against HTML injection.
• Uploaded documents are validated before processing, and files are stored in private containers. Access is granted only through short-lived, expiring signed URLs — no uploaded file is publicly readable by URL.
• Dependencies are managed through NuGet and updated as part of ongoing maintenance.

Logging and audit

• Security-relevant events — account creation, integration connections, credential issuance and revocation, and signed-document activity — are recorded with timestamps in UTC.
• Every integration operation carries a correlation identifier that appears in our logs and in the outbound request, so a single event can be traced end to end and matched against a partner's own logs.
• Logs deliberately exclude credentials, tokens and request bodies.
• Electronically signed real-estate documents are recorded in an append-only audit ledger that survives deletion of the working record, so the provenance of a signature remains demonstrable.

Data retention and deletion

• Agents can disconnect any CRM integration at any time. Disconnecting revokes and deletes the stored credentials immediately.
• Any user can request deletion of their account and personal data at feedalto.com/Home/DataDeletion, without signing in and without installing the app.
• User-uploaded files are stored under a path keyed to the owning account, so deleting an account removes their files as a single operation rather than a search.
• Integration delivery history and diagnostic logs are retained on a rolling window and then purged automatically. Records of deliveries that failed are retained longer, because "what did not reach the CRM" is the question asked afterwards.
• Deleting data in Feedalto does not delete anything already synchronised into an agent's own CRM. That data is under the agent's and the CRM provider's control, and requests relating to it should be directed there.

Sub-processors

Feedalto relies on the following categories of service provider. See our Privacy and Cookie Policy for how personal data is handled.

• Microsoft Azure — hosting, database, file storage, key management, monitoring
• Amazon Web Services (SES) — transactional and notification email
• Twilio — SMS and voice notifications
• Stripe — subscription billing and payments
• Google — mobile push notifications, and AI services used for document and listing content processing
• CRM providers connected by the agent — data is sent only to a CRM the agent has explicitly connected, under the rules they configure

Feedalto does not process or store full payment card numbers. Card data is handled directly by Stripe.

Certifications and compliance

We would rather be accurate than impressive, so this section states our position plainly.

Feedalto has not completed a SOC 2 Type II or ISO 27001 certification. We do not claim one, and any document suggesting otherwise did not come from us. Our security posture rests on the specific technical controls described above, on the compliance programme of Microsoft Azure for the underlying infrastructure, and on the practices set out in our Privacy and Cookie Policy.

Feedalto supports agents' own regulatory obligations in the areas our product touches: express written consent capture for contact permissions, notice acknowledgement records for open-house disclosures, and audit trails for electronically signed documents. These are tools for the agent's compliance; they are not a substitute for their own legal advice.

Partners and brokerages conducting a vendor security review are welcome to request further detail at support@feedalto.com. We will answer a questionnaire directly rather than pointing at a certificate we do not hold.

Reporting a vulnerability

If you believe you have found a security vulnerability in Feedalto, please tell us at support@feedalto.com with Security in the subject line. Include enough detail to reproduce the issue. We aim to acknowledge reports within three business days.

We ask that you give us a reasonable opportunity to investigate and remediate before public disclosure, and that while testing you do not access, modify or retain data belonging to anyone other than yourself, degrade the service for other users, or use social engineering or physical attacks against our staff or providers. We will not pursue action against researchers who follow these guidelines in good faith.

Feedalto does not currently operate a paid bug bounty programme.

Changes to this page

This page describes controls in the live Feedalto platform and is updated when those controls change. The date at the top reflects the most recent revision. For the legal terms governing use of Feedalto, see our Terms of Service; for how we collect and use personal data, see our Privacy and Cookie Policy.