Entrata API Partner Security Requirements & Obligations

Minimum requirements at a glance

• Provide an integration summary and data handling description before onboarding.
• A current SOC 2 Type II (or equivalent independent attestation acceptable to Entrata) is mandatory when specific risk triggers apply such as storing or processing PII.
• Entrata derived data may be used only for the approved business purpose and may not be sold or shared onward except as authorized in writing by Entrata, and may not be used for unauthorized AI/ML training.
• Partners must notify Entrata promptly of security incidents affecting Entrata data, systems, credentials, or integrations.
• Entrata may suspend or deny API access where risk is substantial, unmitigated, or inconsistent with this standard.
• This standard is intended to be incorporated by reference into the partner's API Access Agreement with Entrata.

1. Purpose and Scope

This document defines the minimum security, privacy, and operational requirements for any third party seeking access to Entrata APIs, non-public Entrata systems, or Entrata derived data. Compliance with this standard is a prerequisite to onboarding and to continued access after onboarding. This standard is intended to be incorporated by reference into the applicable API Access Agreement or other written agreement between the partner and Entrata. In the absence of such incorporation, this standard applies as a condition of API access and onboarding.

This standard applies to API partners, vendors, service providers, developers, owners and any disclosed subprocessor or subcontractor that will access, process, store, transmit, or otherwise interact with Entrata data through an integration, whether in sandbox, test, or production environments. References to “partner” in this standard refer to the “Company” as defined in the applicable API Access Agreement.

2. Definitions

Entrata Data
Any non-public data made available through Entrata systems or APIs, including customer, resident, prospect, property, operational, financial, authentication, or support data, as well as any derivative data created from it. For purposes of this standard, ”Entrata Data” includes data that constitutes “Information” or “Confidential Information” as defined in the applicable API Access Agreement, as well as any data derived therefrom that incorporates or could reasonably be used to rederive such data.

Information will not be excluded from the definition of Entrata Data merely because individual elements are publicly known; the specific compilation, context, or association of that information through Entrata systems remains Entrata Data. Entrata Data does not include information that meets an applicable exception to the confidentiality obligations under the partner's API Access Agreement.

PII
Client Personal Information as defined in the applicable API Access Agreement between the partner and Entrata, and any other information reasonably linked to an identified or identifiable person or household, including but not limited to name, email address, phone number, date of birth, and account identifiers.

Sensitive Data
Entrata Data that could create heightened risk if lost, altered, misused, or disclosed without authorization, including all PII (both basic PII and sensitive PII as described in Section 5.7), authentication data, production integration data, regulated data, and resident or prospect communications.

Sensitive Data is a data-handling classification and is broader than 'sensitive PII' as used in the tiered assurance model (Section 5.7); the security and handling obligations in Section 4 apply to all Sensitive Data, while the tiering triggers in Section 5 turn on sensitive PII.

API Partner
Any third party seeking to integrate with Entrata by using an Entrata API, webhook, data feed, or related access mechanism.

Subprocessor
A third party engaged by the API partner that will host, support, transmit, access, or otherwise process Entrata Data or the systems used to process it.

AI/ML Use
Any use of Entrata derived data in connection with artificial intelligence or machine learning (AI/ML), including model training, fine-tuning, model improvement, inferencing, classification, automated decisioning, or similar capabilities.

Common Client

A client of both Entrata and the partner, as defined in the applicable API Access Agreement, on whose behalf and for whose benefit the partner is authorized to access Entrata Data through the integration.

3. Pre Approval Submission Requirements

Before API credentials or production access are issued, the partner must provide enough information for Entrata to evaluate the integration architecture, data handling model, and risk profile. At a minimum, the partner must provide the following, as applicable to the use case:

• A concise integration summary describing the business purpose, endpoints, environments, and anticipated launch scope.
• A description of what Entrata Data will be accessed; whether it will be stored, transformed, cached, or redistributed; and how it will be retained and deleted.
• A declaration of any planned AI/ML Use (as defined in Section 2) involving Entrata derived data.
• A named security contact and incident response contact capable of coordinating with Entrata on technical and security matters.
• Any additional evidence reasonably requested by Entrata to validate controls, such as penetration test summaries, remediation plans, or architecture clarifications.

For any integration that meets a Tier 3 mandatory trigger under Section 5.4 (including access to sensitive PII, a High-Risk Data Write, storage at scale, redistribution, AI/ML Use, or cross-border access):

• A current SOC 2 Type II or equivalent independent attestation when required under Section 5 of this standard.
• A current data flow diagram showing systems, trust boundaries, storage locations, and any onward transfers of Entrata Data.
• A list of all subprocessors, hosting providers, support providers, and development resources that may access Entrata Data, including their geographic locations.

4. Partner Security Requirements and Obligations

The requirements below establish what Entrata considers to be the commercially reasonable minimum baseline referenced in the applicable API Access Agreement. Partners remain responsible for implementing controls appropriate to their specific architecture and for meeting any stricter contractual, legal, or regulatory obligations that apply to the integration.

4.1 Data Use, Minimization, and Confidentiality

• Entrata Data may be accessed and used only for the specific, documented business purpose approved by Entrata.
• The partner must limit data collection, storage, and processing to the minimum amount necessary to deliver the approved service.
• Entrata Data may not be sold, shared onward, combined with unrelated datasets for secondary use, or otherwise disclosed except as expressly authorized in writing by Entrata.
• Sandbox, test, and non production environments must not expose production Entrata Data unless expressly approved and appropriately protected.
• The partner must maintain confidentiality obligations for all personnel and subprocessors with access to Entrata Data.

4.2 Access Control and Credential Management

• Access to systems, API credentials, secrets, tokens, and administrative functions must be restricted to authorized personnel on a least privilege basis.
• Shared or generic administrative accounts should be avoided wherever technically feasible. Individual accountability must be preserved for privileged actions.
• Privileged or administrative access to systems supporting the integration must be protected by multifactor authentication.
• Secrets must be stored securely and may not be embedded in source code, client side applications, or other insecure locations.
• The partner must promptly revoke or rotate credentials when compromise is suspected or when personnel with access change roles or leave the organization.
• The partner must scope all credentials, data access, and write actions to the specific Common Client(s) approved for the integration, and must maintain isolation between Common Clients, including across properties, regions, and client identifiers. Entrata Data of one Common Client must not be accessed, combined, or acted upon for the benefit of another Common Client or of any entity that is not an approved Common Client.

4.3 Encryption and Transmission Security

• Entrata Data must be encrypted in transit using industry standard secure protocols, including TLS 1.2 or better, where supported.
• Entrata Data stored by the partner must be encrypted at rest using strong, industry accepted cryptographic controls.
• The partner must protect keys and secrets from unauthorized access and must implement secure certificate and key management practices.

4.4 Secure Development, Infrastructure, and Vulnerability Management

• Systems used to connect to Entrata APIs must be appropriately hardened, maintained, and monitored.
• The partner must maintain a documented process for identifying, prioritizing, and remediating vulnerabilities in code, infrastructure, dependencies, and internet facing systems.
• Critical vulnerabilities affecting public facing admin interfaces, databases, identity services, or integration components must be remediated without undue delay.
• The partner must not expose internet-facing administrative services, databases, or identity infrastructure in a manner that creates substantial risk to Entrata or its customers.
• Changes to systems supporting the integration should be subject to testing, approval, and rollback controls appropriate to the partner’s environment.

4.5 Logging, Monitoring, and Incident Response

• The partner must maintain logging and monitoring sufficient to detect unauthorized access, misuse of API credentials, substantial configuration changes, and unusual data access patterns.
• Logs relevant to authentication events, privileged activity, security alerts, and Entrata Data access should be retained for a period sufficient to support investigations and legal or regulatory needs.
• The partner must maintain a documented incident response capability and must cooperate with Entrata in investigating incidents related to the integration.
• The partner must notify Entrata promptly, and in no event later than twenty four (24) hours after confirmation, of any security incident that affects Entrata Data, Entrata credentials, systems used to access Entrata APIs, or the confidentiality, integrity, or availability of the integration.
• Following notice, the partner must provide timely updates, containment status, known impact, remediation actions, and reasonable forensic or evidentiary support requested by Entrata.

4.6 Data Retention, Return, and Deletion

• The partner may retain Entrata Data only for as long as necessary to perform the approved service or to meet documented legal obligations.
• Upon termination of the relationship with respect to a specific Common Client, the partner must securely return or delete all Entrata Data related to that Common Client. Upon termination of the API Access Agreement or Entrata's written request, the partner must securely return or delete all Entrata Data.
• If the partner uses backups, archives, or disaster recovery systems containing Entrata Data, the partner must ensure deletion is completed within a reasonable and documented backup lifecycle.

4.7 Subprocessors and Cross Border Access

• The partner must maintain a current inventory of all subprocessors, subcontractors, support organizations, and development resources that access, or may access, Entrata Data or the systems used to process it, including each resource's function and geographic location. The partner must submit this inventory as part of pre-approval submission for higher-risk access (see Section 3); for all other integrations, the partner must make the inventory available to Entrata promptly on request.
• The partner remains fully liable for the acts and omissions of its subprocessors and must ensure that equivalent security, confidentiality, and privacy obligations are contractually imposed on them.
• Regardless of tier or integration risk level, the partner must give Entrata advance notice before adding any new subprocessor, subcontractor, or support resource that will access Entrata Data, or substantially changing a data hosting or support location in a way that affects Entrata risk.
• Access to Entrata Data by subprocessors, subcontractors, or development resources located outside the United States is subject to additional review and may require additional contractual and security conditions. The partner must not relocate access to or processing of Entrata Data outside the United States without prior notice to Entrata.

4.8 AI/ML and Automated Processing Restrictions

• Entrata derived data may not be used in connection with AI/ML Use unless such use has been clearly disclosed, contractually authorized, and approved in writing by Entrata.
• Where AI/ML Use is approved, the partner must maintain data segregation controls, documented use boundaries, and mechanisms to prevent unauthorized reuse of Entrata derived data.
• Unless expressly approved in writing by Entrata, Entrata derived data may not be used to train, fine tune, improve, or validate generalized or public models.
• This restriction applies regardless of whether the AI/ML Use is competitive with the Entrata Platform. For the avoidance of doubt, this Section supplements and does not narrow the use restrictions in the applicable API Access Agreement.

4.9 Messaging, Marketing, and Resident/Prospect Communications

• Partners using Entrata Marketing APIs, SMS APIs, or similar messaging capabilities must implement controls to prevent spam, spoofing, fraud, abusive automation, and unauthorized campaigns.
• The partner is responsible for complying with applicable consent, opt out, and communications requirements associated with the messaging use case.
• Entrata may require additional validation, monitoring, or rate limiting controls before enabling messaging related integrations.

5. Tiered Assurance Model and Independent Assurance Requirements

Entrata applies a risk tiered assurance model to API partners. Assurance requirements are determined based on the sensitivity of Entrata Data accessed, whether the partner stores or redistributes such data, whether the integration permits write access or other actions that could alter Entrata records or workflows, whether Entrata derived data is used in AI/ML enabled processes, and whether subprocessors or support resources have cross border access to Entrata Data. This approach is intended to align review effort with actual risk and to avoid imposing the same evidence burden on every integration regardless of scope.

The table below summarizes Entrata’s tiered assurance model and the corresponding baseline diligence and independent assurance expectations for API partners.

5.1 Tier 1 — Limited Data / Low Risk Integrations

Tier 1 generally applies where the partner accesses only low sensitivity operational, property, unit, or configuration data; does not access PII; does not store Entrata Data except for short lived processing necessary to support the integration; does not redistribute Entrata Data; and does not perform write actions into Entrata systems.

For Tier 1 integrations, Entrata may require a completed intake, integration summary and a security questionnaire or targeted control attestation, as appropriate to the use case. A current independent attestation is not automatically required for Tier 1 unless other risk factors elevate the integration.

5.2 Tier 2 — Basic PII / Moderate Risk Integrations

Tier 2 generally applies where the partner accesses limited PII, such as name, email address, phone number, or similar contact information, typically in read-only, low-risk write, or otherwise constrained use cases, and where the integration does not otherwise create  downstream risk through sensitive processing, broad redistribution, large scale retention, or high risk system permissions.

For Tier 2 integrations, Entrata may require a completed security questionnaire, including a focused questionnaire such as SIG Lite, CAIQ, CAIQ Lite, or an equivalent control questionnaire acceptable to Entrata, together with evidence of core controls such as multifactor authentication for privileged access, encryption in transit and at rest, vulnerability management, incident response capability, and subprocessor oversight. A current independent attestation is not automatically required for every Tier 2 integration, but Entrata may require it where the scale of access, retention model, redistribution pattern, public risk signals, or other factors substantially increase risk.

5.3 Tier 3 — Sensitive Data / High Risk Integrations

Tier 3 applies where the partner handles sensitive PII or other high risk Entrata Data; stores Entrata Data at scale or for ongoing operational use; redistributes Entrata Data beyond the minimum needed to provide the approved service; performs high risk write actions into Entrata systems; uses Entrata derived data in AI/ML related processing, other than an AI/ML Use that Entrata has expressly approved in writing as a narrow use under §4.8 and §5.4(4) (which is tiered on the sensitivity of the data it accesses and may remain Tier 2); or permits access to Entrata Data by subprocessors, contractors, or support resources in ways that substantially increase legal, operational, security, or privacy risk.

For Tier 3 integrations, Entrata requires a full security review and a current SOC 2 Type II or equivalent independent attestation acceptable to Entrata. Providing such documentation does not guarantee approval; Entrata may still require clarification, remediation commitments, contractual restrictions, or compensating controls based on the facts of the integration and the partner’s overall risk posture. 

5.4 Mandatory Independent Assurance Triggers

Regardless of the tier label applied to an integration, Entrata will require a current SOC 2 Type II or equivalent independent attestation acceptable to Entrata where one or more of the following conditions apply:

• The partner obtains, stores, processes, or redistributes sensitive PII or other Entrata Data that creates heightened privacy, fraud, or customer harm risk.
• The partner has write access to Entrata systems in a manner that could substantially affect customer records, resident or prospect information, communications, transactions, account status, screening outcomes, or operational workflows.
  A Low-Risk Data Write, as defined in §5.7, does not by itself invoke the mandatory independent-assurance trigger in §5.4(2), because it cannot substantially affect customer records, resident or prospect information, transactions, account status, or screening outcomes. An integration whose only write access consists of Low-Risk Data Writes is tiered on the sensitivity of the data it reads, and is generally treated as Tier 2, subject to core controls, property scoping, write audit logging, and rate limiting on bulk catalog writes. The presence of any write outside this definition returns the integration to Tier 3. Conversely, any integration that performs even one High-Risk Data Write (§5.7) is Tier 3 and requires the assurance under this Section, regardless of the tier its read access would otherwise imply, and regardless of whether the protected data appears in the request, the response, or only in the record being altered. The Low-Risk Data Write exemption does not apply to any integration that performs a High-Risk Data Write.
• The partner stores Entrata Data at scale, retains it for ongoing operational use, or redistributes it to affiliates, customers, subprocessors, downstream systems, or other third parties beyond the minimum required for the approved service.
• The partner uses Entrata derived data in AI/ML enabled workflows, as defined in Section 2, unless Entrata has expressly approved a narrower use in writing and appropriate contractual protections are in place.
• The partner permits access to Entrata Data by subprocessors, subcontractors, development resources, or support personnel outside the United States where such access substantially increases data protection, regulatory, operational, or incident response risk.
• Entrata identifies substantially adverse security signals during review, including serious unresolved vulnerabilities, leaked privileged credentials, recent relevant breaches or ransomware events, or other indicators that warrant stronger independent assurance before approval.

5.5 Alternative Independent Assurance

Where Entrata determines that a current SOC 2 Type II report is not reasonably attainable for a lower-risk or early-stage API partner, Entrata may, in its discretion, accept one of the following in lieu of SOC 2 Type II: (i) a current ISO/IEC 27001 certification; (ii) a current SOC 2 Type I report as an interim measure, together with a written commitment to obtain SOC 2 Type II within a defined period; or (iii) for lower-risk integrations only, a combination of a completed SIG Lite, CAIQ, or equivalent security questionnaire, a recent independent penetration test summary, and evidence of core security controls acceptable to Entrata. Entrata may impose scope limits, remediation milestones, or other conditions when accepting alternative assurance.

5.6 Enforcement

If no mandatory trigger is present, Entrata may approve an integration based on the assurance level appropriate to Tier 1 or Tier 2. If one or more mandatory triggers are present, the partner must provide the required independent attestation before approval unless Entrata grants a written exception with documented compensating controls and appropriate executive approval, including where Entrata accepts an alternative under Section 5.5. Failure to provide required assurance when triggered may result in denial, delayed onboarding, restricted scope of access, or approval conditioned on specific remediation milestones.

5.7 Clarifying Notes

For purposes of this Section 5, “basic PII” generally refers to limited contact information, such as name, email address, phone number, or similar identifiers, where the integration is otherwise read only, low-risk write or constrained and does not create heightened risk through scale, storage, redistribution or sensitive processing.

For purposes of this Section 5, “sensitive PII” generally includes government issued identifiers, financial account data, payment related data, screening results, authentication data, precise account level records, or other Entrata Data that could reasonably create heightened privacy, fraud, legal, or customer impact risk if accessed, altered, misused, or disclosed without authorization.

High-Risk Data Write. A write operation that creates, modifies, or deletes any of: financial, payment, or ledger data (a transaction); lease or account status, including move-in, move-out, notice, renewal, or cancellation; a screening or application outcome; a customer or resident record; resident or prospect information, including leads; a resident or prospect communication; or authentication, credential, or access-control state. A write is a High-Risk Data Write if it touches any of these, regardless of what other low-risk data it also touches.

Low-Risk Data Write. A write operation that creates, modifies, or deletes only property, unit, catalog, or configuration data (including marketing catalog and listing content), and that does not create, modify, or delete any of the following: individual PII; a customer, resident, or prospect record or its status; resident or prospect information, including leads; a resident or prospect communication; financial, payment, or ledger data; screening or application data; lease or account status; or authentication, credential, or access-control state.

6. Entrata Review and Approval Process

Entrata uses a risk based review process for API partnerships. As part of this process, Entrata may consider external security posture signals, public records such as breaches or enforcement actions, credential leak intelligence, outside in scanning of public facing infrastructure, the sensitivity of data accessed, whether data is stored or redistributed, messaging capabilities, AI/ML usage, and the geography of subprocessors or support resources.

Entrata may also use internal risk management processes and frameworks, including SAFE and FAIR based methods, to support consistent and auditable security decisions.

Possible outcomes include:

• Approved, where the partner demonstrates risk aligned to the integration and the controls described in this standard.
• Approved with Conditions, where limited remediation items or follow up actions must be completed within defined timeframes.
• Requires Additional Security Review, where Entrata needs further evidence, clarification, or remediation before a final decision.
• Denied, where risk is substantial, unmitigated, or inconsistent with Entrata’s requirements or risk tolerance.

7. Denial, Suspension, and Enforcement Conditions

Entrata may deny, delay, or suspend access where risk is substantial, unmitigated, or inconsistent with this standard. Without limiting Entrata’s rights under contract, the following conditions may result in denial or suspension:

• An active or unresolved security incident involving confirmed or likely exposure of sensitive data.
• A ransomware event or comparable compromise within the prior twelve (12) months without demonstrated remediation or evidence that the environment is no longer at risk.
• Evidence of ongoing compromise, leaked privileged credentials, or unpatched critical vulnerabilities affecting systems that could impact the integration.
• substantial misrepresentation of security posture, refusal to participate in Entrata’s review process, or repeated failure to remediate known substantial issues.
• Failure to provide a required SOC 2 Type II or equivalent independent attestation when one of the triggers in Section 5 applies.
• Violation of the approved use case, unauthorized redistribution or AI/ML Use of Entrata derived data, or substantial non compliance with this standard.

8. Ongoing Obligations After Approval

• The partner must maintain the controls represented during onboarding for the duration of the integration.
• The partner must notify Entrata of substantial changes to architecture, hosting location, subprocessor footprint, control environment, ownership, or use of Entrata Data that could affect risk.
• Entrata may request updated evidence of security controls, independent assurance reports, or remediation progress at onboarding, renewal, or when risk signals change.
• Entrata may perform periodic reassessment and may modify access scope, place conditions on access, or require remediation where circumstances warrant.

9. Exceptions

Any request for an exception to this standard must be made in writing and approved by Entrata before the exception is relied upon. Exceptions are limited, time bound, and may require documented compensating controls, additional monitoring, or other conditions determined by Entrata.

Appendix A. Partner Acknowledgment (As Applicable)

Entrata may ask a partner to acknowledge this standard in writing as part of onboarding. The following language may be used as a short form acknowledgment:

“By requesting or using access to Entrata APIs, Partner acknowledges that it has reviewed the Entrata API Partner Security Requirements & Obligations and will maintain controls reasonably designed to comply with them throughout the term of the integration. Partner further acknowledges that Entrata may suspend, condition, or revoke access where substantial risk or non compliance is identified.”

Appendix B. Partner Submission Checklist

Companion to the Entrata API Partner Security Requirements & Obligations (v1.2). This checklist organizes what Sections 3 and 5 already require; it introduces no new obligations.

Use this checklist to prepare your onboarding submission. What you must submit depends on your integration's tier. If any one item in the Tier 3 column applies to your integration, treat the whole integration as Tier 3.

Identify your tier (see Section 5)

• Tier 1: no individual PII; read-only; no storage beyond transient processing; no redistribution; no writes.
• Tier 2: basic PII only (name, email, phone, address); read-only or otherwise constrained.
• Tier 3: any one of the following: sensitive PII; a High-Risk Data Write (Section 5.7); storage at scale; redistribution beyond the approved minimum; AI/ML Use; or cross-border access.

What to submit

Alternative assurance (Tier 3)

If a current SOC 2 Type II is not attainable, Entrata may, at its discretion, accept a Section 5.5 alternative:

• a current ISO/IEC 27001 certification;
• a current SOC 2 Type I report plus a written commitment to obtain SOC 2 Type II within a defined period; or
• for lower-risk integrations only, a completed SIG Lite, CAIQ, or equivalent questionnaire, plus a recent independent penetration-test summary, plus evidence of core security controls acceptable to Entrata.

Notes

• Submit the current version of each document.
• Where an independent attestation's examination period has ended, include a bridge or gap letter covering the interval between the period end and the date of submission.
• Entrata may request clarification or additional evidence at any point during review.

‍