Fundrise · Authentication Profile

Fundrise Authentication

Authentication

Fundrise secures its APIs with http across 2 declared security schemes, as derived from its OpenAPI definitions.

CompanyFinancial ServicesInvestingReal EstatePrivate CreditVenture CapitalAlternative AssetsWealth ManagementFintechEmbedded Investing
Methods: http Schemes: 2 OAuth flows: API key in:

Security Schemes

PartnerBasicAuthentication http
scheme: basic
ClientBearerAuthentication http
scheme: bearer

Source

Authentication Profile

Raw ↑
generated: '2026-08-04'
method: searched
source: openapi/fundrise-connect-openapi.yml
docs: https://connect.fundrise.com/#tag/Authentication
notes: >-
  Baseline derived by 0-working/derive-authentication.py from the published OpenAPI 3.1.0,
  then upgraded from the Authentication tag of the Fundrise Connect documentation, which
  documents the two-subject model, the token exchange, the credential-handling
  obligations, and the per-partner access-control layer that the securitySchemes block
  alone does not express.

summary:
  types:
  - http
  http_schemes:
  - basic
  - bearer
  api_key_in: []
  oauth2_flows_declared_in_spec: []
  oauth2_in_practice:
  - refresh_token
  model: two-subject
  access_request: https://fundrise.com/connect-api/contact
  contact: connect@fundrise.com

schemes:
- name: PartnerBasicAuthentication
  type: http
  scheme: basic
  subject: Partner
  rfc: RFC 7617
  description: >-
    "PartnerBasicAuthentication is enforced by HTTP Basic Authentication. A Partner
    username and password will be provided by Fundrise support. The Partner password
    should be stored securely. At a minimum, it should be encrypted at-rest and access
    restricted to services making requests to the Fundrise API. The Partner password
    should not be exposed to a Client or any of their devices. If the password is
    compromised please contact Fundrise support."
  credential_issuance: Fundrise support (connect@fundrise.com)
  self_service: false
  rotation_policy: not-published
  operations:
  - GetAccessToken
  - GetOfferings
  - GetHistoricalNav
  - GetOfferingDocuments
  - CreateClient
  sources:
  - openapi/fundrise-connect-openapi.yml

- name: ClientBearerAuthentication
  type: http
  scheme: bearer
  subject: Client
  rfc: RFC 6750
  description: >-
    "ClientBearerAuthentication is enforced by HTTP Bearer Authentication and requires an
    OAuth access token. Since access tokens are scoped to specific Clients, they identify
    and authenticate the Client in a request. Access tokens can be obtained in Get Access
    Token requests by using the refresh token flow. OAuth refresh tokens are issued on
    Client Creation and scoped specifically to that Client. The refresh tokens will not
    expire and should be stored securely after Client creation. At a minimum, refresh
    tokens should be encrypted at-rest and access restricted to services making requests
    to the Fundrise API. Refresh tokens should not be exposed to a Client or any of their
    devices."
  bearer_format: not-published
  operations:
  - CreateShareLiquidationRequest
  - CancelShareLiquidationRequest
  - GetLiquidationAcknowledgments
  - GetInvestmentAcknowledgments
  - GetHoldings
  - GetClient
  - UpdateClient
  - PlaceInvestment
  - CancelInvestment
  - GetTaxForms
  - GetTransaction
  - GetTransactions
  sources:
  - openapi/fundrise-connect-openapi.yml

token_exchange:
  operation: GetAccessToken
  path: /v1/oauth/token
  method: post
  auth: PartnerBasicAuthentication
  grant: refresh_token
  request_field: refreshToken
  response_schema: OAuth2AccessTokenResponse
  response_fields:
  - accessToken
  - refreshToken
  - scope
  - tokenType
  - expiresIn
  refresh_token_source: CreateClient
  refresh_token_expiry: none
  access_token_expiry: returned as expiresIn; no fixed value published
  note: >-
    A genuine OAuth refresh-token exchange is modelled in the spec as a plain http bearer
    securityScheme rather than an oauth2 scheme with declared flows, so generated clients
    receive no flow metadata, no tokenUrl, and no scope list. Declaring it as oauth2 with
    a clientCredentials or custom flow would make the contract self-describing.

separate_consumer_oauth_surface:
  discovery: https://fundrise.com/.well-known/openid-configuration
  http_status: 200
  authorization_endpoint: https://fundrise.com/oauth/authorize
  token_endpoint: https://api.fundrise.com/oauth/token
  scopes_supported:
  - openid
  - offline_access
  response_types_supported:
  - code
  token_endpoint_auth_methods:
  - client_secret_basic
  note: >-
    This is Fundrise's consumer-facing OAuth/OIDC authorization server, discovered
    anonymously and distinct from the Connect partner API's own token operation. It is
    recorded here and in scopes/fundrise-scopes.yml because it is the only place Fundrise
    publishes named scopes. The discovery document omits issuer, jwks_uri,
    subject_types_supported and id_token_signing_alg_values_supported, so it is a partial
    rather than conformant OIDC discovery document.

authorization:
  model: scheme-per-operation plus per-partner allowlist
  scopes: see scopes/fundrise-scopes.yml
  documented_statement: >-
    "To ensure a safe, secure platform, Fundrise imposes strict access controls to all
    APIs. As such, there may be services or capabilities documented that are inaccessible
    with current permissions. Contact the support team via connect@fundrise.com to gain
    permissions for additional endpoints."
  note: >-
    Endpoint-level authorization is expressed by which of the two schemes an operation
    requires, plus an out-of-band per-partner permission grant. A 403 on a documented
    operation is expected behaviour under this model, not a defect.

credential_handling_requirements:
- Partner password encrypted at rest.
- Client refresh tokens encrypted at rest.
- Access to both restricted to the services making API requests.
- Neither ever exposed to a Client or a Client device.
- Compromise reported to Fundrise support.

gaps:
- The OAuth exchange is not declared as an oauth2 securityScheme, so flows and scopes are invisible to tooling.
- No bearerFormat is declared, so token structure (JWT or opaque) is undocumented.
- Refresh tokens never expire and no rotation or revocation mechanism is published.
- No mutual TLS, no request signing, and no key rotation policy documented for Partner Basic credentials.
- The OIDC discovery document is incomplete against OpenID Connect Discovery 1.0.

x-evidence:
- fetched: '2026-08-04'
  url: https://connect.fundrise.com/
  http_status: 200
  note: OpenAPI 3.1.0 and the Authentication tag narrative.
- fetched: '2026-08-04'
  url: https://fundrise.com/.well-known/openid-configuration
  http_status: 200
  content_type: application/json