> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wegive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction to Neon CRM

> Learn about Neon CRM and how it integrates with the WeGive donor management platform

# 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.

<Warning>
  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.
</Warning>

## 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

<Note>
  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.
</Note>

## Payment Method Mapping

<Warning>
  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.
</Warning>

| WeGive `source_type` | Neon Tender Type |
| - | - |
| `card` | Credit Card Offline |
| `bank` | Check |
| `donor` | Check |
| anything else | Check (fallback default) |

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

<Warning>
  **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.
</Warning>

### Custom Field Mapping Caveat

<Warning>
  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.
</Warning>

## Getting Started

1. Review the [Setup Requirements](/external/onboarding/neon/setup-requirements)
2. Configure your [Integration Settings](/external/onboarding/neon/configuration-options)
3. Review the [Data Mapping](/external/onboarding/neon/data-mapping/overview) documentation
4. Understand the [Integration Nuances](/external/onboarding/neon/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

* [Neon CRM API Documentation](https://developer.neoncrm.com/)
* [Neon CRM Support Center](https://help.neoncrm.com/)
* WeGive Support: [support@wegive.com](mailto:support@wegive.com)

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.