Getting API access

What it takes to go from a Wefunder login to a working application.

1. Open the developer portal

Sign in and open wefunder.com/developers.

• If you already edit a company or manage a syndicate on Wefunder, the portal opens immediately. Running your own company or syndicate is the access grant.
• Otherwise the portal shows a request-access form. Submit it there; the portal is where your request status lives. A teammate invited into an existing organization needs no waitlist step.

2. Create an application

Applications → Create. The form first asks what you are building:

• Sync a company's investments fills in the scope set the Sync Investments guide needs, with one optional tick for investor names and emails. It makes the app a confidential client with no redirect URI: installs and tokens come from the portal, nothing goes through OAuth, and no callback server is needed. It also asks whether you sync your own company or clients', and tells you which reviews that implies before anything is created.
• Manage my syndicate fills in the scope set a syndicate lead needs: read:syndicates and write:syndicates (members, applications, invites, deals and their investors, statistics, portfolio), read:installations / write:installations, and read:webhooks / write:webhooks for the syndicate_member.* events, with one optional tick, write:comments, to draft deal Q&A and comments you approve before they post. It is the same confidential, no-redirect-URI shape as the sync preset: after Create, open the app's Installations page, install it on your syndicate, mint the token, and call GET /syndicates. That token is syndicate-owned: it holds at most the syndicates pair and reaches the syndicate endpoints, their intents, and this app's webhook endpoints. The installations pair and write:comments are for the personal token the You row mints (installing programmatically, drafting comments as yourself); a syndicate-owned token cannot propose a comment. Creating SPVs or funds through the API is the invite-only Partner preview, not part of this preset; investing stays with the investor. If you only want to ask your syndicate questions, the hosted MCP server needs no app at all.
• Something else is the full form: a name, the scopes your app needs, whether it is a confidential or public client, and a redirect URI. The redirect URI is required for a public (PKCE) client, whose only grant is the authorization-code flow. A confidential client may leave it blank when nobody will authorize through OAuth (installs from the portal or an install link, client credentials); such a key cannot use the authorization-code flow until you give it a redirect URI from the app page.

You receive a sandbox client (pk_test_ / sk_test_) and a live client (pk_live_ / sk_live_) together. The live secret (sk_live_) is shown once, so store it before you leave that screen; the test secret (sk_test_) stays retrievable from the app page. Creating an app records your acceptance of the acceptable-use and attribution rules; read them first if you will display offerings to the public.

Only need the public catalog? Leave every scope unticked. The app is created with read:public alone and a confidential client, no redirect URI and no user consent: use the client-credentials grant from your server. Users can never authorize such an app, so it can never reach user data.

Three things to know before you press Create (the form says the first one too):

• Most of an application is fixed at creation. There is no rename. Scopes can be added and removed from the app's page while the app is active, approved or not; an added scope reaches users and installs only through a fresh consent or a re-install, and a removed scope is taken away from every install and token at once. Each key's redirect URI and client type can be changed from the app page by an organization owner or admin; the one rule is that a public (PKCE) key must keep a callback, so a key with no callback cannot become public and a public key cannot drop its callback. A changed redirect URI applies to the next authorize request. If you need a shape the portal cannot give you, create a replacement app, install it and re-authorize users on it, cut your integration over, and only then disable the old app. An app that has been approved, issued a live token, or installed anywhere cannot be deleted, only disabled; disabling revokes all of its tokens immediately. See Changing scopes.
• Only self-serve scopes can be picked, listed with the deal catalog first and each write: under its read:. Program-tier scopes (attribution) and the Partner API preview scopes are not in the list; Wefunder adds them to your app as part of those programs. See Scopes.
• read:investors:pii is a self-serve tick, granted per install. An install carries it when the installer manages your organization, or when Wefunder has approved your app for investor PII (request that review from the app's page; it covers installs by founders outside your organization). See Scopes.

3. What your live keys can do on day one

• A client_credentials token holds read:public only: the deal catalog and public company pages.
• A user who authorizes your app grants it their own view, within the scopes they consent to.
• Your app can be installed on the companies and syndicates your own organization's members already edit or manage, from the app's Installations page in the portal or with POST /installations.

4. App review

Installing your app on someone else's company or syndicate requires the app to be approved. Submit it for review from its page in the portal. Until then the install link works only for people who manage your organization, and only on records they administer.

5. Installing on a company or syndicate

An installation is what routes a company's webhook events to you and mints the company-owned token your integration reads that company with. The portal is organized per application: pick the app in the sidebar and open its Installations page (wefunder.com/developers/apps/<id>/installations). Three paths, same result:

1. Your own company or syndicate, or you. The Installations page lists you, the companies you edit, and the syndicates you manage. A company or syndicate has an Install button that opens the consent page for that one; consent, and you are back on the page with the new install listed and Mint token showing the company-owned token once. The You row mints a personal token on the spot, recording your own install of the app. Either way, no OAuth flow against yourself.
2. Founder link. Pick who the link is for on the same page and copy it. For a company or a syndicate it is https://wefunder.com/apps/app_…/installations/new?target_type=company (or target_type=syndicate); append &state=<your id> to correlate it. If you already know which one it's for, add &target=syndicate:syn_… (or &target=company:co_…) and the page asks about only that one, provided the person signed in can install on it; otherwise they get the full list. The founder signs in, picks their company, and consents, and the install appears on the Installations page, where Mint token works the same way. For a person the link is your app's OAuth authorize URL for its live key; they sign in, authorize, and land at your redirect URI with a code, and the install appears once your app exchanges it. A public (PKCE) key has no fixed link, since the code challenge is per sign-in; build that URL in your app.
3. Programmatic. If your staff already edit the client's company, connect one of them with read:installations write:installations, call GET /installations/eligible, then POST /installations.

The page shows active installs first, paged, with revoked ones one click away. Webhooks, Logs and Events in the sidebar are scoped to the same app; switch to All apps in the app switcher for the organization-wide view.

A step-by-step first install, from the portal and from the API: Install your app. Tiers, scope rules, and revocation: Installations.

Partner SPV preview

Creating SPVs and invite links through the API is an invite-only preview with its own review. (Hosted investment sessions left the preview and are open to any installed app.) Join the waitlist and describe the SPV use case; Wefunder enables the preview per application. See the Partner API overview.

Next steps

1. Authentication
2. Sandbox
3. Webhook setup