Skip to main content

​
Neon CRM Overview

Neon CRM is a cloud-based donor management platform for nonprofits. The WeGive integration syncs a specific, narrower set of objects than Neon CRM itself supports — this page describes what the integration actually does, not everything Neon CRM offers as a platform.
Several claims below reflect real code behavior corrections made during a 2026-09 accuracy audit. In particular: payment-method mapping is narrower than commonly assumed, several “key features” listed in earlier versions of this page (event/ticketing sync, communication tools, custom-field arrays) are not implemented, and there is no rate limiting or automatic retry anywhere in this integration.

​
What This Integration Actually Syncs

  • Donor/Account Management: individual and company donor profiles, pulled and pushed
  • Donations: gift records with payment method details, pulled and pushed
  • Campaigns: name, dates, goal — pulled and pushed
  • Recurring Donations: push-only (WeGive → Neon)
  • Addresses: dead code — syncAddress() is fully implemented but has no caller anywhere; address sync has never actually run for any organization (this is a known issue). A stripped-down copy of mailing/billing address (no phone/fax) does sync inline as part of the donor account push itself.
  • Webhooks: real-time notifications for donor create/update and donation create/update only — not for recurring donations or campaigns, despite occasional documentation implying broader webhook coverage
There is no event registration/ticketing sync, no email marketing or communication-tracking sync, and no implemented custom-field array support (accountCustomFields/donationCustomFields exist as commented-out placeholders in the integration’s payload-generation code, not as working features) in this integration.

​
Payment Method Mapping

The integration maps only 3 WeGive source types to Neon tender types — it does not have distinct support for cash, stock/securities, in-kind, PayPal, wire, or gift-certificate payment methods, despite Neon CRM itself supporting all of these as a platform.
Card brand mapping is similarly narrow: only Visa, MasterCard, Amex, and Discover have a code mapped — any other card issuer would fail to resolve a cardTypeCode in the payload.

​
Integration Architecture

  • Neon CRM API v2: RESTful, real
  • Real-time push: donor, donation, campaign, and recurring-donation pushes are all triggered synchronously on WeGive record create/update. Address push (syncAddress()) is implemented but dead code — this is a known issue.
  • Daily batch pull: donors, campaigns, and donations are pulled once daily (command:pull-integrations neon scheduled daily) — incremental, filtered by last-modified date
  • Custom Field Mapping: real, via NeonMappingRule records and JSONPath ($.path.to.field) resolution — but see the warning below
  • Redis locking: each push type uses a per-record lock to prevent duplicate creation under concurrent pushes
There is no automatic retry logic or rate-limit throttling anywhere in this integration. Every API call is a single, unretried HTTP request with a 120-second timeout via Laravel’s HTTP client. A failed call simply fails — there’s no backoff, no queue-based retry, no built-in respect for Neon’s own rate limits beyond whatever Neon’s API itself enforces server-side.

​
Custom Field Mapping Caveat

As of this writing, the NeonMappingRule model’s literal flag (meant to send a fixed value rather than look one up) is not yet honored by Neon’s field-application code — generateAccountParams()/generateDonationParams() always treat wegive_path as a JSONPath lookup regardless of the flag. This is a known issue, with a fix in progress (both the dashboard UI PR and the API export-side PR open). Until that ships, don’t configure a Neon mapping rule expecting literal to work.

​
Getting Started

  1. Review the Setup Requirements
  2. Configure your Integration Settings
  3. Review the Data Mapping documentation
  4. Understand the Integration Nuances

​
Core Objects

​
Account Management

  • Individual Account: personal donor records
  • Company Account: organization donor records
  • Primary Contact: name/email, nested under the account in Neon’s API shape
  • Address: mailing (and, for individuals only, billing) address — a stripped-down copy syncs inline as part of the account push (no phone/fax); the dedicated syncAddress() push path is dead code and never runs (this is a known issue)

​
Transaction Management

  • Donation: gift records with payment details and campaign attribution
  • Campaign: name, dates, goal, and Neon-reported statistics (pulled read-only — WeGive doesn’t compute these)
  • Recurring Donation: push-only scheduled gift records

​
Environment Configuration

​
Production

  • API Base: https://api.neoncrm.com/v2/
  • Webhook Base: https://super.givelist.app/api/

​
Staging/Development

  • API Base: https://trial.neoncrm.com/v2/
  • Webhook Base: https://api.staging.givelist.app/api/
Selected automatically based on config('app.env') — no manual environment toggle in the dashboard.

​
Support and Resources

​
Best Practices

  • Data Quality: keep donor emails clean — email is the match key on pull
  • Understand the payment-method limitation: don’t assume Neon-side reporting for cash/stock/in-kind gifts reflects a distinct tender type; they’ll show as Check
  • Check Sentry, not a dashboard sync-status view: there’s no dedicated integration health dashboard beyond the general integration log
This is a real, working bidirectional integration for its supported objects — but it’s narrower in scope (payment methods, custom fields, webhook coverage, retry behavior) than a feature-complete description would suggest.