Skip to main content

Acceptable use, attribution, and branding

These rules are a condition of your API access and apply to every application your organization holds, in sandbox and live, whether it was created before or after this page existed. Creating an application in the developer portal records your acceptance. They exist because the public catalog describes securities offerings: how a third party displays an offering is regulated, and investors on Wefunder trust that their data stays with the company they invested in.

If something you want to build is not clearly allowed here, ask first: Support.

What you may do​

  • Display public offering data — what GET /explore, GET /offerings/{id}, and the public company endpoints return to a read:public token (the anonymous view, the same set an unauthenticated visitor sees on wefunder.com/explore) — in your own product, with a link back to the offering on wefunder.com (its attributes.url) wherever it is shown. A read:explore token acting for a signed-in user returns that user's view, which can include private rounds they were invited to and investor-only content; that is theirs to see, never yours to publish. Show it only to that user.
  • Cache responses for freshness and rate-limit headroom. Hold a response only as long as you need to stay inside the rate limits and keep your display current. The public catalog allows 60 requests a minute per IP, which is enough to refresh every open offering several times an hour.
  • Act on behalf of users who authorized you, within the scopes they granted, for as long as their authorization stands.

What you may not do​

  • Redistribute or resell the catalog. No bulk exports, mirrors, data feeds, or "Wefunder data" products for others to consume. Your users see the offerings in your product; they do not receive the dataset.
  • Scrape or bulk-collect beyond the documented limits. Rotating IPs, keys, or organizations to exceed a rate limit is treated as a violation, not an optimization.
  • Show stale money figures as current. amount_raised, funding_target, and investor_count change by the minute during a live raise. Any figure you display must carry the time you fetched it (for example "raised $412,000 as of 2:15 PM ET") or be refreshed before it is shown.
  • Remove or obscure attribution (below).
  • Imply endorsement. Nothing you build may suggest that Wefunder recommends, ranks, vets, or partners with your product, or with a particular offering, unless we have agreed that in writing.

Attribution​

Every offering you display must be identifiable as a Wefunder offering and must link to its page on wefunder.com.

  • Wording. Use "Via Wefunder", "powered by Wefunder", or "raising on Wefunder". You may use similar wording but never imply that a company has been vetted by, endorsed by, or recommended by Wefunder.
  • Link target. The company's page on wefunder.com: the offering's attributes.url, or company.url on a portfolio position or holding. A Wefunder portfolio, dashboard, or investments page is not a substitute. Do not deep-link to the invest or reserve flow directly, and do not wrap the link in a redirect that hides the destination.
  • Logo. You may show the Wefunder wordmark unmodified, at a legible size, in its original colors or a single flat color, only as part of the attribution. Do not combine it with your own mark, animate it, or use it as your product's icon. Attribution text alone is always acceptable; the logo is optional.

Describing a Reg CF offering​

Most offerings on Wefunder are made under Regulation Crowdfunding. You may show the facts and terms the API reports for an offering, as reported, with a link to its page. You may not add to them: no promotional claims, no investment advice, and no ranking or scoring of offerings. In practice:

  • Allowed: the company's name, logo, and tagline; the security type and exemption (attributes.security.type, or attributes.intended_security.type for a testing-the-waters offering whose security is still null, and attributes.exemption); the security's terms as the API reports them (attributes.security.terms, such as the valuation cap, discount, share price, or valuation); the target and amount raised with a fetch time; the open and close dates; and a link to the offering page.
  • Not allowed: terms or figures the API does not report, your own calculations presented as the offering's terms, or terms shown without the link to the offering page, where the full disclosures are.
  • Testing-the-waters offerings. When attributes.testing_the_waters is true, the company is collecting non-binding reservations, not investments. Your copy must say "reserve" or "reservation" for those offerings and never "invest". A reservation can be cancelled by the investor at any time and is not a commitment.

Investor data​

Investor data is never public and never yours.

  • read:investors:pii exists so a company's own team, or a tool that team installed, can see the investors in that company's raise. It is granted per install, and only when the person installing could grant it: they manage your organization (a founder running their own app, or your staff installing on a company they already edit), or Wefunder has approved your app for investor PII. See Investor PII is granted per install.
  • Data returned under that scope stays within the company's team: it may be shown to the company's authorized users and processed on their behalf. It may not be displayed publicly, aggregated across companies, or used to contact investors on your own behalf, and you must delete it when the installation is revoked.
  • The same applies to anything a user authorized you to read about themselves through the authorization-code flow: it is theirs, shown to them, and you delete it when they revoke access.

Enforcement​

We review usage through the same request log every application sees in the portal. When an application breaks these rules we suspend it: its credentials stop being accepted, it can no longer be installed, and the app shows as suspended in your portal. Only Wefunder can lift a suspension, usually after you confirm the fix in writing. Repeated or deliberate violations can end the organization's access.

Acceptance​

Creating an application records that you accepted these terms, with the time of acceptance, on the application. Applications created before this page existed are bound by it as a condition of access even though no acceptance was recorded. The approval email for new developers links here as well. We will announce material changes in the changelog and, where they narrow what you may do, give existing applications time to comply.

Was this page helpful?