Skip to main content

Platform Overview

How access is organized around the Wefunder API. Four ideas do all the work.

Organizations are developer accounts​

An organization is the account you manage in the developer portal. It owns your applications, their OAuth clients and secrets, your webhook endpoints, and your team. Think of it as an Apple Developer account: it owns your apps and your team, not the users or the marketplace.

An organization does not own product data. Companies, offerings, investments, users, and syndicates are global Wefunder records. No organization gets a private partition of them. See Organizations.

Access flows through people and installations​

Your app reads or writes a company, offering, or syndicate for exactly one of two reasons:

  • A user authorized it. The token acts as that person and can see what they can see, capped by the scopes they granted.
  • It is installed on the company or syndicate. A founder or syndicate manager connected your app, and the installation carries a tier and a scope list. See Installations.

In both cases the effective permission is the person's or installation's role on the record, intersected with the token's scopes. Scopes only ever narrow. See Access model.

Server keys read public data only​

A client_credentials token has no user behind it, so it receives only the public scopes: the deal catalog under /explore, /offerings/{id}, and /companies/{id}. Everything else needs a user-authorized or installation token. See Authentication.

Sandbox is a separate world​

Every organization gets its own sandbox realm on wefunder-sandbox.com, reached through the same api.wefunder.com host with _test_ credentials. Nothing in it touches live data. See Sandbox for the walkthrough and Sandbox mode for how the isolation works.

Pages in this section​

Was this page helpful?