--- title: Integration Setup & Security description: Technical reference for connecting each integration — how authentication works, what data WIZE accesses, how it syncs, and what your IT or CRM admin needs to set up. order: 7 --- # Integration Setup & Security This is a technical reference for **IT teams, security reviewers, and CRM administrators** who are setting up or evaluating a WIZE integration. For the plain-language overview of what each integration does day to day, see [Integrations](/help/integrations/). For each integration below you'll find: the authentication method, whether access is **read-only or read/write**, exactly what data WIZE reads, how often it syncs, and what your administrator needs to do. Jump straight to the one you need — e.g. [Salesforce](#salesforce), [Blackbaud Raiser's Edge NXT](#blackbaud-raisers-edge-nxt), or [Google Workspace](#google-workspace). ## How connections work **Two ways to authenticate:** - **OAuth 2.0 sign-in** (Google, Microsoft, Salesforce, Blackbaud, HubSpot, Airtable, Asana, Monday.com, Mailchimp, Slack). You sign in to the other service and approve access. WIZE receives a revocable access token — **your password is never shared with WIZE.** WIZE registers and maintains the connected app on its side; there is nothing for you to create in a developer console (the one exception is Blackbaud, which requires a one-time app connection in the NXT Marketplace — see that section). - **API key** (most CRMs). You generate a key in the other tool's settings and paste it into WIZE's connect screen. The connect screen tells you where to find it. **Two connection levels:** - **Organization** — connected once for the whole team (all CRMs, Airtable, project management, email marketing). Anyone in your Organization can then use it in chat. - **Personal** — each teammate connects their own account (email and calendar). WIZE only touches an individual's inbox or calendar when that person asks it to. **Two access patterns:** - **Synced** (CRMs and Airtable) — on connect, WIZE runs an initial import and then re-syncs on a daily schedule so chats can query current data. This is **read-only for every source except Blackbaud Raiser's Edge NXT**: WIZE imports a copy into your workspace and never writes back to the source. For Blackbaud NXT, WIZE can additionally **create actions and notes on a constituent when you ask it to in chat, and only after you confirm the exact values** — see [Blackbaud Raiser's Edge NXT](#blackbaud-raisers-edge-nxt). Nothing is ever updated or deleted, in any CRM. - **On-demand** (email, calendar, project management, email marketing) — WIZE reads or acts only in the moment you ask, in chat. There is no background copy of this data. ## Data handling & security - **In transit:** all traffic between WIZE and every provider uses encrypted HTTPS/TLS connections. - **Read-only CRMs:** WIZE never creates, edits, or deletes records in any connected CRM. It only reads. - **Drafts only, never sends:** where WIZE can write to email tools, it only ever creates **drafts** for a person to review and send. WIZE does not send email or launch campaigns on its own. - **Your credentials:** OAuth tokens and API keys are stored in your Organization's workspace, sent only in the authorization header of requests to that specific provider, and are **never exposed to the AI model or shown in chat**. - **Not used for training:** connected data stays inside your workspace and is not used to train any AI model. - **Encrypted at rest** and covered by the practices in our [Privacy Policy](/privacy-policy) (including encrypted backups). - **Revoke anytime:** disconnect any integration from the same **Integrations** screen where you connected it. For OAuth integrations you can also revoke access from the provider's own "connected apps" screen; the next sync or request then fails cleanly and prompts a reconnect. ## At a glance | Integration | Category | Connects | Auth | WIZE's access | Sync | |---|---|---|---|---|---| | Blackbaud Raiser's Edge NXT | CRM | Organization | OAuth 2.0 (+ Marketplace app) | Read + create actions/notes | Daily (incremental + weekly full) | | Salesforce | CRM | Organization | OAuth 2.0 + PKCE | Read-only | Daily (incremental) | | Blackbaud Raiser's Edge NXT | CRM | Organization | OAuth 2.0 (+ Marketplace app) | Read-only | Daily (incremental + weekly full) | | Salesforce (incl. PatronManager) | CRM | Organization | OAuth 2.0 + PKCE | Read-only | Daily (incremental) | | ActiveCampaign | CRM | Organization | API key + account URL | Read-only | Daily (full) | | Bloomerang | CRM | Organization | API key | Read-only | Daily (incremental) | | DonorDock | CRM | Organization | API key + secret + tenant | Read-only | Daily (full) | | DonorPerfect | CRM | Organization | API key | Read-only | Daily (incremental) | | Little Green Light | CRM | Organization | API key | Read-only | Daily (incremental) | | Virtuous | CRM | Organization | API key | Read-only | Daily (incremental) | | Salsa Engage | CRM | Organization | API token | Read-only | Daily (incremental) | | Zeffy | CRM | Organization | API key | Read-only | Daily (incremental + weekly full) | | Givebutter | CRM | Organization | API key | Read-only | Daily (incremental + weekly full) | | Give Lively | CRM | Organization | Organization ID + API key | Read-only | Daily (full) | | DonorDrive | CRM | Organization | None — site address + event ID | Read-only | Daily (incremental + weekly full) | | Funraise | CRM | Organization | API key | Read-only | Daily (incremental + weekly full) | | GiveCampus | CRM | Organization | API key | Read-only | Daily (incremental + weekly full) | | HubSpot | CRM | Organization | OAuth 2.0 | Read-only | Daily (full) | | EngageBay | CRM | Organization | API key | Read-only | Daily (full) | | Cvent | CRM | Organization | Client ID + Client Secret (OAuth2 client credentials) | Read-only | Daily (full) | | Donorbox | CRM | Organization | Login email + API key (Basic auth) | Read-only | Daily (full) | | Fundraise Up | CRM | Organization | API key | Read-only | Daily (full) | | Blackbaud eTapestry | CRM | Organization | API key + database ID | Read-only | Daily (full) | | GoFundMe Pro (formerly Classy) | CRM | Organization | API application (client ID + secret) | Read-only | Daily (full) | | OneCause | CRM | Organization | Organization ID + API key | Read-only | Daily (full) | | Neon CRM | CRM | Organization | Organization ID + API key (Basic auth) | Read-only | Daily (full) | | iMIS (ASI) | CRM | Organization | Site URL + REST API user (OAuth2 password grant) | Read-only | Daily (full) | | Microsoft Dynamics 365 | CRM | Organization | Microsoft Entra app registration (client credentials) | Read-only | Daily (incremental) | | Ellucian Banner | CRM | Organization | Ethos Integration API key | Read-only | Daily (full) | | Slate (Technolutions) | CRM | Organization | Service account (Basic auth) | Read-only | Daily (full) | | Andar | CRM | Organization | API access token (bearer) | Read-only | Daily (full) | | Tessitura | CRM | Organization | API user (Basic auth: user name + user group + location + password) + List ID | Read-only | Daily (full) | | NetSuite (Oracle) | Accounting/ERP | Organization | Token-Based Authentication (OAuth 1.0) | Read-only | Daily (incremental) | | VolunteerHub | CRM | Organization | Superuser (Basic auth) | Read-only | Daily (incremental users + full events/groups) | | vCita | CRM | Organization | API token | Read-only | Daily (full) | | Airtable | Data sync | Organization | OAuth 2.0 + PKCE | Read-only | Daily (full reconcile) | | Google Workspace | Email & calendar | Personal | OAuth 2.0 | Read + create drafts/events | On-demand | | Microsoft Outlook | Email & calendar | Personal | OAuth 2.0 | Read + create drafts/events | On-demand | | Asana | Project management | Organization | OAuth 2.0 | Read + create/update tasks | On-demand | | Monday.com | Project management | Organization | OAuth 2.0 | Read + create/update items | On-demand | | Mailchimp | Email marketing | Organization | OAuth 2.0 | Read + create drafts | On-demand | | Constant Contact | Email marketing | Organization | OAuth 2.0 | Read + create drafts | On-demand | | QuickBooks Online | Accounting & finance | Organization | OAuth 2.0 | Read-only | On-demand (live, no import) | | Canva | Design | Personal | OAuth 2.0 + PKCE | Read designs + upload images | On-demand | | Connect The Dots | Prospect research | Personal | OAuth 2.0 | Read-only (relationship graph) | On-demand | | Tatango (momoGood) | Texting (SMS) | Organization | Login email + API key (Basic auth) | Read-only | On-demand | | Emma (Marigold) | Email marketing | Organization | Account ID + public/private API key | Read groups + add contacts | On-demand | | Slack | Communication | Organization | OAuth 2.0 | Read + post in invited channels — *being switched on, see below* | On-demand | All OAuth integrations use the redirect/callback URL `https://app.wizenow.com/api/oauth/callback//`. --- ## CRM integrations CRM connections are **Organization-level**. WIZE imports a copy of your data into your workspace on a daily schedule; query results in chat open as spreadsheets you can review and reuse. **Writing back:** every CRM here is **read-only** except **Blackbaud Raiser's Edge NXT**, where WIZE can create **actions and notes** on a constituent — new records only, on your explicit confirmation, each one stamped so you can find it. WIZE never updates or deletes an existing CRM record, and never creates constituents, gifts, or anything else. Details in the Blackbaud section below. ### Blackbaud Raiser's Edge NXT - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow against Blackbaud SKY. The token request is authenticated with WIZE's own application credentials; API calls also carry WIZE's `Bb-Api-Subscription-Key` (a WIZE-owned key, not something you provide). - **Scope requested:** `rnxt.r rnxt.w` — Raiser's Edge NXT **read and write**. WIZE does **not** request the delete (`rnxt.d`) scope, and the write scope is used only for the two create operations below. Connections authorized before this change hold a read-only token and stay read-only until an admin reconnects. - **Access:** Read, plus **create actions and notes** (see *What WIZE can create* below). No updates, no deletions. - **Data WIZE reads:** constituents, gifts, actions, notes, relationships, education records, and constituent codes. - **What WIZE can create:** **actions** (calls, meetings, emails, mailings, follow-ups) and **notes** on a constituent — and nothing else. Both happen only when you ask for one in chat, and only after WIZE shows you the exact values and you confirm them. Every record WIZE creates carries the text **`[Created in WIZE]`** in its body (an action's *description*, a note's *text*), so your team can tell at a glance which rows came from WIZE and can search NXT for all of them. The new record appears back in WIZE on the next daily sync. To turn this off, disconnect Blackbaud — or connect with an RE user who lacks permission to add actions and notes, in which case WIZE reads normally and tells you it can't write. - **Sync:** initial full import, then a daily incremental sync (server-side "last modified" filtering) with a weekly full reconcile to catch deletions. - **What your admin sets up:** an administrator in Raiser's Edge NXT connects the WIZE application in the **NXT Marketplace** using WIZE's application ID `5f27e840-6a64-4815-96da-af524abe35d2`, then completes the OAuth sign-in from WIZE's connect screen. - **Connection details:** OAuth + token host `oauth2.sky.blackbaud.com`; data host `api.sky.blackbaud.com`; redirect URL `https://app.wizenow.com/api/oauth/callback/blackbaud_re_nxt/`. ### Salesforce (including PatronManager) - **Applies to:** the core Salesforce CRM (Sales Cloud), **including NPSP** (Nonprofit Success Pack) and **PatronManager** — both are managed packages on the same platform, so WIZE reads their objects through this one connection (see *Data WIZE reads* and *PatronManager* below). It does **not** connect to **Salesforce Marketing Cloud**, which is a separate product with its own API and data model (Data Extensions, Journeys, Subscribers) — WIZE has no Marketing Cloud integration. - **Connection level:** Organization. - **Authentication:** OAuth 2.0 **authorization-code flow with PKCE (S256)**. WIZE hosts its own Connected App — **you do not create a Connected App and there is no managed package to install.** Your password is never shared with WIZE; WIZE stores a refresh token used for the daily sync. - **Scopes requested:** `api`, `refresh_token`, `openid`. (`api` runs the SOQL queries, `refresh_token` grants the offline access the daily sync needs, `openid` identifies the connecting user.) - **Connected App:** WIZE provides and maintains a single first-party Connected App and is the OAuth client. There is **nothing for your team to create, configure, or install** in your org — no managed package and no custom Connected App. WIZE's app is configured with PKCE required, the redirect URL below, and only the three scopes above. - **Access:** **Read-only.** WIZE issues only SOQL `SELECT` queries — it never creates, updates, or deletes anything in Salesforce. - **Data WIZE reads:** - Standard objects: **Account, Contact, Opportunity, Task, Event, Note.** - NPSP (auto-detected if installed): **Recurring Donations** (`npe03__Recurring_Donation__c`), **Payments** (`npe01__OppPayment__c`), **Affiliations** (`npe5__Affiliation__c`), **Relationships** (`npe4__Relationship__c`), **Addresses** (`npsp__Address__c`). - Custom `__c` objects that reference Account or Contact — WIZE discovers these automatically at sync time. - **PatronManager (arts and culture):** PatronManager is a **native Salesforce app installed in your own org**, not a separate system, so you connect it *here* — there is no separate PatronManager tile and no PatronManager API key. - **Patrons and contributions sync automatically** with the standard connection: your patrons and ticket buyers are Salesforce **Contact** records and their contributions are **Opportunity** records, both of which WIZE already reads. - **Ticketing is an opt-in extra.** Once connected, turn on **"Also sync PatronManager ticketing"** on the Salesforce card (**Integrations → Salesforce**). That adds your PatronManager ticketing, event and order objects — the `PatronTicket__…` objects in your org that link to a Contact or Account — so WIZE can answer questions about ticket buyers alongside donors (frequent buyers who have never given, lapsed subscribers, and so on). - **No new sign-in is needed** to turn it on or off: it uses the Salesforce connection you already authorized and only changes which objects WIZE reads. Turning it off removes the ticketing data from WIZE again; your patron and donation data is unaffected. - Still **read-only**, and still limited to what the connecting user can see. Which ticketing objects appear depends on your own PatronManager configuration; very large ticketing objects are capped per sync to protect your Salesforce API limits. - **Sync:** initial full import, then a daily incremental sync using a server-side `SystemModstamp` filter. - **Single sign-on (SSO):** if your org is SSO-only, enter your **My Domain** (e.g. `yourorg.my.salesforce.com`) on WIZE's connect screen so login is routed to your identity provider instead of the generic `login.salesforce.com`. Sandboxes and `*.my.salesforce.com` hosts are supported. - **What your admin sets up:** - **You do not create or register a Connected App.** WIZE is the OAuth client; its Connected App already exists on WIZE's side and is used for every customer. Your team's only role is to *authorize* it (and, if your org locks down connected apps, pre-approve it — see below). There is no App Manager setup, no consumer key/secret for you to generate, and no package to install. - The person who clicks **Connect** needs the **API Enabled** permission and read access to the objects above. - If your org restricts connected apps (OAuth policy *"Admin approved users are pre-authorized,"* or IP relaxation is locked down), a Salesforce admin pre-approves the WIZE Connected App under **Setup → Connected Apps OAuth Usage / Manage Connected Apps** and assigns it to the connecting user's profile/permission set. If your policy is *"All users may self-authorize,"* no admin action is needed at all. - **Permissions & data scope (architecture):** WIZE authenticates *as the connecting Salesforce user* and reads only what that user is permitted to see — **object permissions, field-level security, and sharing rules all apply.** To scope exactly what WIZE can access, connect with a **dedicated, read-only integration user** whose profile/permission set is limited to the objects and fields you want shared. - **How to connect:** in WIZE, open **Integrations → Salesforce** → (SSO orgs only) enter your **My Domain** → sign in to Salesforce and approve access → the initial import starts automatically and re-syncs daily. That's the entire setup — nothing to configure inside Salesforce first (aside from the optional admin pre-approval above). PatronManager customers then flip the ticketing toggle on the same card. - **Connection details:** authorize/token host is your My Domain (or `login.salesforce.com`); data calls go to your org's instance URL; redirect URL `https://app.wizenow.com/api/oauth/callback/salesforce/`. ### ActiveCampaign - **Connection level:** Organization. - **Authentication:** API key. In ActiveCampaign, go to **Settings → Developer** to find your **API Access URL** (`https://.api-us1.com`) and **Key**. Paste both into WIZE. - **Access:** Read-only (sent as an `Api-Token` header). - **Data WIZE reads:** contacts, deals, deal pipelines and stages, lists, and tags. - **Sync:** initial import, then a daily full sync. - **What your admin sets up:** generate an API key with read access to contacts, deals, and lists. - **Connection details:** per-account host `https://.api-us1.com/api/3/`. ### Bloomerang - **Connection level:** Organization. - **Authentication:** API key, generated in Bloomerang's settings. Paste the key into WIZE. - **Access:** Read-only (sent as an `X-API-Key` header). - **Data WIZE reads:** constituents, transactions, interactions, notes, and soft credits. - **Sync:** initial import, then a daily incremental sync (server-side `lastModified` filtering where supported). - **What your admin sets up:** generate an API key with read access. - **Connection details:** host `https://api.bloomerang.co`. ### DonorDock - **Connection level:** Organization. - **Authentication:** an **API key**, an **API secret**, and your **Tenant ID**, all generated/identified in DonorDock's settings. WIZE combines the key and secret into an HTTP Basic authorization header; the tenant ID is sent as an `X-Tenant-Id` header. - **Access:** Read-only. - **Data WIZE reads:** contacts and gifts. - **Sync:** initial import, then a daily full sync. - **What your admin sets up:** generate an API key + secret and provide your DonorDock Tenant ID. - **Connection details:** host `https://public-api.donordock.com`. ### DonorPerfect - **Connection level:** Organization. - **Authentication:** API key, generated in DonorPerfect's admin panel. WIZE calls DonorPerfect's XML API with the key as an `apikey` parameter. - **Access:** Read-only. - **Data WIZE reads:** donors (constituents) and gifts. - **Sync:** initial import, then a daily incremental sync (filtered on modified/created date). - **What your admin sets up:** obtain an API key from DonorPerfect's admin panel with read access. - **Connection details:** host `https://www.donorperfect.net` (XML request API). ### Little Green Light - **Connection level:** Organization. - **Authentication:** API key, generated under **Settings → Integration Settings → API** in Little Green Light. Paste the key into WIZE (sent as a `Bearer` token). - **Access:** Read-only. - **Data WIZE reads:** constituents (including each constituent's mailing addresses, email addresses and phone numbers) and gifts. - **Sync:** initial import, then a daily incremental sync (`updated_from` filtering). - **What your admin sets up:** generate an API key with read access. - **Connection details:** host `https://api.littlegreenlight.com/api/v1`. ### Virtuous - **Connection level:** Organization. - **Authentication:** API key, generated in Virtuous under your API settings. Paste the key into WIZE (sent as a `Bearer` token). - **Access:** Read-only. (WIZE uses Virtuous's query endpoints, which accept a POST body to filter and page — these are read operations, not writes.) - **Data WIZE reads:** contacts and gifts. - **Sync:** initial import, then a daily incremental sync where the account supports last-modified filtering (WIZE probes for this and falls back to a full sync otherwise). - **What your admin sets up:** generate an API key with read access to contacts and gifts. - **Connection details:** host `https://api.virtuoussoftware.com`. ### Salsa Engage - **Connection level:** Organization. - **Authentication:** API token, generated in Salsa Engage's settings. Paste the token into WIZE (sent as an `authToken` header). - **Access:** Read-only. - **Data WIZE reads:** supporters, donation transactions, activities, and segments. - **Sync:** initial import, then a daily incremental sync (`modifiedFrom` / `transactionFrom` filtering). - **What your admin sets up:** obtain an API token with read access. - **Connection details:** host `https://api.salsalabs.org/api`. ### Zeffy - **Connection level:** Organization. - **Authentication:** API key, generated by an org admin under **Settings → Integrations** in Zeffy. Paste the key into WIZE (sent as a `Bearer` token). - **Access:** Read-only. - **Data WIZE reads:** contacts, payments (donations, ticketing, and manual entries), and campaigns. - **Sync:** initial import, then a daily incremental sync, plus a weekly full reconcile to catch edits and refunds to older payments. - **What your admin sets up:** generate an API key (org-admin only) with read access. - **Connection details:** host `https://api.zeffy.com/api/v1`. ### Funraise **Which Funraise?** funraise.org (help.funraise.io). This is a *different* company from **Fundraise Up** (fundraiseup.com), **Funraisin** (funraisin.co) and **Fundraise.com** — all four have similar names. If your platform's login lives at `funraise.org`, this is the right one. - **Connection level:** Organization. - **Authentication:** API key, generated by an admin in Funraise under **Settings → API Keys** → *Generate API Key*. **Copy it before you close that dialog — Funraise shows the key only once.** Paste it into WIZE (sent as an `X-Api-Key` header). - **Access:** Read-only. WIZE only calls Funraise's list endpoints; it never creates or edits anything in your Funraise account. - **Data WIZE reads:** supporters (donors), donations, recurring subscriptions, forms, and campaign sites (active and archived). - **Households:** Funraise has households, but its API offers no way to list them, so WIZE's household table stays empty for Funraise. Household names still show up — each supporter and donation carries its household inline. - **Sync:** initial import, then a daily incremental sync, plus a weekly full reconcile that catches edits and refunds to older donations. - **API request allowance (worth checking before you connect):** Funraise's *API Base* plan includes **3,000 requests/month**, and *API Plus* 10,000. WIZE's normal cadence fits comfortably inside 3,000 for a typical account. A very large Funraise account — roughly 350,000 supporters plus donations or more — will need API Plus or higher; ask your Funraise Success Manager. If the allowance runs out mid-month, WIZE stops the sync rather than importing a partial copy, and your existing data stays exactly as it was. - **Connection details:** host `https://api.funraise.io`. ### EngageBay - **Connection level:** Organization. - **Authentication:** API key, generated by an admin under **Account Settings → API → REST API Key** in EngageBay. Paste the key into WIZE. (EngageBay sends the key as a bare `Authorization` header — there is no separate secret or account URL to supply.) - **Access:** Read-only. WIZE only calls EngageBay's list endpoints; it never creates or edits records in your EngageBay account. - **Data WIZE reads:** contacts, companies, deals, plus tags, tasks, products, and your EngageBay users (owners). Owners are imported so that a deal's owner shows up as a name rather than an id — that is your own staff list, and it stays inside your workspace. - **Deals are pipeline, not settled gifts:** EngageBay is a sales-and-marketing CRM, so a "deal" is an *opportunity* with a stage, an amount, and an expected close date — not a donation that has cleared. If you track major gifts or pledges as EngageBay deals, WIZE will answer from that pipeline; it will describe expected amounts, not received ones. - **Sync:** initial import, then a daily full re-sync. EngageBay's API has no server-side "changed since" filter (it can sort by update time but not filter by it), so WIZE re-lists your data each night rather than fetching a delta. This keeps edits and deletions current at the data volumes typical of EngageBay organizations. - **What your admin sets up:** copy the REST API key from Account Settings → API. - **Connection details:** host `https://app.engagebay.com` (paths under `/dev/api/panel`). ### Givebutter - **Connection level:** Organization. - **Authentication:** API key, generated by an admin under **Settings → Integrations → API Keys** in Givebutter. Paste the key into WIZE (sent as a `Bearer` token). - **Access:** Read-only. - **Data WIZE reads:** households, contacts (with lifetime giving stats, tags, custom fields, emails/phones/addresses), transactions (donations, ticketing, with campaign/fund/plan links), campaigns, recurring plans, funds, tickets, payouts, and pledges. - **Sync:** initial import, then a daily incremental sync of contacts and transactions where Givebutter's API supports last-modified filtering (WIZE probes for this each night and falls back to a full re-list otherwise), plus one full re-list a week. Campaigns, recurring plans, funds, tickets, payouts, pledges and households are re-listed in full every night. The weekly full re-list is what removes records deleted or archived in Givebutter, so a deletion can take up to a week to disappear from WIZE. - **What your admin sets up:** create an API key with read access under Settings → Integrations → API Keys. - **Connection details:** host `https://api.givebutter.com/v1`. ### DonorDrive DonorDrive is peer-to-peer and endurance event fundraising (walks, runs, rides, DIY fundraiser pages) — it is a different product from Salsa Engage / EveryAction, even though both are Bonterra-owned. WIZE connects **one event at a time**. - **Connection level:** Organization. - **Authentication:** **none.** DonorDrive's public API is open, so there is no API key, token or password to create. You give WIZE two things: your DonorDrive **site address** (e.g. `yourorg.donordrive.com`) and the **event ID** of the event to sync. - **Finding your event ID:** it is the number or name in your event page's web address — e.g. `605` in `.../index.cfm?fuseaction=donorDrive.event&eventID=605`, or `marathon-2024` in a friendly event URL. Either form works. - **Access:** Read-only. WIZE never writes anything back to DonorDrive. - **Data WIZE reads:** the event's donations (registration fees excluded — they are not gifts), donors, teams and participants. Because this is DonorDrive's *public* API, the donor records carry only what your event's public fundraising page shows — display name, donation totals and dates. **No donor email addresses, postal addresses or phone numbers are available through it.** - **Sync:** initial import, then a daily incremental sync plus a weekly full re-sync. DonorDrive asks integrations to make no more than one request every 15 seconds, so WIZE paces itself accordingly and a first import of a busy event can take up to an hour. Events larger than about 20,000 donations and donors combined are not supported yet — WIZE will tell you at connect time rather than syncing part of it. - **What your admin sets up:** nothing in DonorDrive. Just make sure the event's fundraising page is public. - **Connection details:** per-org host `https:///api/events/`. WIZE currently supports DonorDrive sites hosted on `donordrive.com`; if your site runs on a custom domain, contact support. ### GiveCampus - **Connection level:** Organization. - **Authentication:** API key, generated by a school super-user admin under **School Dashboard → Integrations → API Keys** in GiveCampus. Paste the key into WIZE (sent as a `Bearer` token). - **Access:** Read-only. - **Data WIZE reads:** constituents (donors/alumni), gifts (including pledges and recurring gifts, with their designation/fund and linked constituent), designations, designation groups, and campaigns. - **Sync:** initial import, then a daily incremental sync (filtered on each gift's last-updated timestamp), plus a weekly full reconcile to catch edits and refunds to older gifts. - **What your admin sets up:** a school super-user generates an API key with read access under School Dashboard → Integrations → API Keys. - **Connection details:** host `https://api.givecampus.com/v1`. ### HubSpot - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow. You sign in to HubSpot and approve access for the account you select — WIZE holds the application credentials, so there is nothing for you to create in a developer console and no key to paste. Access tokens are short-lived (30 minutes) and refreshed automatically; if the refresh token is revoked, the connection fails cleanly and prompts a reconnect. - **Scopes requested:** `oauth`, `crm.objects.contacts.read`, `crm.objects.companies.read`, `crm.objects.deals.read` — **read scopes only.** No write scope is requested for any object. - **Access:** Read-only. - **Data WIZE reads:** **Companies** (name, domain, phone, address, industry, type, employee count), **Contacts** (name, email, phone, company, job title, address, lifecycle stage, lead status), and **Deals** (name, amount, stage, pipeline, close date, type, description), plus the associations that link a contact to its company and a deal to its contact/company. - **Deals are pipeline, not settled gifts:** HubSpot has no native "gift" object, so WIZE maps **Deals** to gifts — HubSpot's own nonprofit guidance treats deals as the donation record. A deal is an *opportunity* with a stage, an amount and an expected close date, so WIZE will describe expected amounts, not received ones. If your organization records money through HubSpot's Payments API or a custom object instead, WIZE will not see it as giving. - **Sync:** initial import, then a daily full re-sync. WIZE re-lists your contacts, companies and deals each night rather than fetching a delta, which keeps edits and deletions current. - **What your admin sets up:** nothing inside HubSpot beyond approving access. The person who clicks **Connect** needs permission to connect an app to the HubSpot account and read access to contacts, companies and deals. - **Connection details:** authorization host `app.hubspot.com`; token + data host `api.hubapi.com`; redirect URL `https://app.wizenow.com/api/oauth/callback/hubspot/`. ### Cvent - **Connection level:** Organization. - **Authentication:** **OAuth2 client credentials.** You create the application yourself in Cvent's **Developer Hub** (Applications → new application, Client Credentials grant) and paste its **Client ID** and **Client Secret** into WIZE. The secret is shown only once, so copy it before closing the dialog. There is no WIZE-branded "Sign in with Cvent" screen — Cvent's client-credentials flow has no redirect, which is why you type two values instead of clicking Authorize. - **Scopes your application must grant** (read-only, all six): `event/contacts:read`, `event/transactions:read`, `event/events:read`, `event/attendees:read`, `event/sessions:read`, `event/admission-items:read`. If the application is missing one, WIZE tells you which at connect time; if you add one later, the CRM card's notice clears itself on the next sync. - **Data centre:** WIZE detects whether your account is in Cvent's North American or European data centre automatically — there is nothing to choose. - **Access:** Read-only. WIZE requests only `:read` scopes and never writes to Cvent. - **Data WIZE reads:** event contacts (as constituents), event payments (as gifts), and — as supporting records — events, registrations, sessions, ticket types, and refunds. - **Sync:** initial import, then a **daily full re-sync**. Cvent does offer a "changed since" filter, but linking a payment to a person requires a complete pass over registrations on every run anyway (a payment taken today can belong to a registration from three years ago), so a full re-sync costs little more and is what keeps cancellations and refunds accurate. - **Cvent API tier matters.** Cvent's **Free** API tier allows 1,000 calls per day, which is not enough for a full sync of a real event programme — **Standard or above is required.** You can check your tier in Cvent's Developer Hub. - **How payments are counted:** WIZE counts settled **charges** as giving. Authorizations (approved by the card issuer but not yet taken) and declined payments are ignored. **Refunds are imported but kept separate from the giving totals**, because Cvent does not document whether a refund's amount is positive or negative and guessing would either double-count or hide a gift — so a fully refunded registration still appears in giving totals, and you can see the matching refund alongside it. Ask WIZE for refunds on an event if you need a net figure. - **Currency:** amounts are stored in the currency of the event that took them, and WIZE does **not** convert between currencies — so don't sum across events in different currencies. - **Not synced:** anything that would need one request per event (donation items, per-event orders, seating and table assignments, exhibitors, surveys), plus Cvent's hospitality-sourcing, travel, housing, webcast and user-provisioning data. None of it carries a fundraising signal worth its cost against Cvent's daily call limit. - **What your admin sets up:** create the Developer Hub application, grant the six read scopes, and hand over the Client ID and Client Secret. - **Connection details:** host `https://api-platform.cvent.com/ea` (North America) or `https://api-platform-eur.cvent.com/ea` (Europe). - **If it connected and then stopped:** Cvent client secrets can be rotated or the application deleted. WIZE marks the connection as needing attention; create or copy a fresh secret and reconnect. ### Give Lively - **Connection level:** Organization. - **Authentication:** two values — your **Organization ID** and an **API key**, both found in the Give Lively **Nonprofit Admin Portal → Settings → Organization Settings → Integrations**. If no key exists yet, click **Generate**. Paste both into WIZE. - **Access:** Read-only (Give Lively's API offers no way to write; WIZE only reads). - **Data WIZE reads:** **donations only.** Give Lively's API exposes a single donations feed and no separate donor, campaign or event list. - **How donors work here:** each donation carries the donor's details (name, email, phone, address where the donor supplied them), so WIZE builds a donor record for each person out of their donations. That means a donor appears in WIZE once they have given at least once — Give Lively has no donor list to import from. Donations made under one person's Give Lively account and as a guest with the same email address are matched into one donor; if an email address is shared across several Give Lively accounts (a household or an office address), WIZE keeps those donors separate rather than merging people who may not be the same person. - **Campaigns and events:** their identifiers stay on each donation, so you can ask about them in chat, but they are not imported as their own lists — Give Lively publishes no endpoint for them. - **Sync:** initial import, then a daily full re-sync. Give Lively returns the whole donation history in a single response, so WIZE re-reads all of it each night rather than a partial update — which is what keeps edits and refunds current. - **What your admin sets up:** generate the API key under Nonprofit Admin Portal → Settings → Organization Settings → Integrations, and copy the Organization ID from the same page. - **Connection details:** host `https://secure.givelively.org`. - **Very large donation histories:** because the whole history arrives in one response, an unusually large one can exceed the size WIZE will download in a single sync. If that happens the sync reports an error rather than importing a partial history — contact support and we can raise the limit. ### Donorbox - **Connection level:** Organization. - **Authentication:** **HTTP Basic auth** with two values — your Donorbox **organization login email** and an **API key**. Generate the key in Donorbox under **Account → API Key → Set new api key**; it is shown only once, so copy it before closing the dialog. Paste both into WIZE. - **Requires a paid Donorbox plan.** Donorbox charges separately for API access (about $17/month). If your plan doesn't include it, the connection will be rejected — check your Donorbox plan before assuming the email or key is wrong. - **Access:** Read-only (every Donorbox API endpoint is a GET; WIZE never writes to Donorbox). - **Data WIZE reads:** donors, donations, campaigns, and recurring giving plans. - **Sync:** initial import, then a daily full re-sync. Donorbox's date filters select donations by the date the donation was *made*, not the date a record last *changed*, and its donor endpoint has no date filter at all — so WIZE re-lists the full data set each night rather than an incremental delta. That is what keeps edits, refunds, and donor updates current. - **Not synced:** Donorbox **Events** data (events, tickets, purchases) — that is a separate Donorbox add-on. - **What your admin sets up:** generate the API key under Account → API Key, and confirm the Donorbox plan includes API access. - **Connection details:** host `https://donorbox.org/api/v1`. - **If everything connects but nothing syncs:** confirm the API add-on is active on your Donorbox plan, and that the organization login email you gave WIZE is the one that owns the campaigns. ### Fundraise Up - **Connection level:** Organization. - **Authentication:** API key. Generate it in Fundraise Up under **Settings → API keys** and paste it into WIZE (sent as a `Bearer` token). - **Test-mode keys.** A Fundraise Up key beginning with `test_` is a test-mode key. It connects successfully and then returns only test data — so if the connection succeeds but no donations appear, check the key prefix before assuming the sync is broken. - **Access:** Read-only (WIZE only lists records; it never creates or edits anything in Fundraise Up). - **Data WIZE reads:** supporters (your donors), donations, recurring giving plans, and events. - **Sync:** initial import, then a daily full re-sync. Fundraise Up's API has no "changed since" filter — its list endpoints page through records rather than filtering by date — so WIZE re-lists the full data set each night instead of pulling a delta. That is what keeps refunds, status changes, and supporter edits current. - **Not synced:** anything you write back. WIZE does not create donations, and the Donor Portal is out of scope. - **What your admin sets up:** generate an API key under Settings → API keys. - **Connection details:** host `https://api.fundraiseup.com/v1`. ### Blackbaud eTapestry - **Connection level:** Organization. - **Authentication:** API key **and** database ID, both issued together when an eTapestry admin enables the API. Paste both into WIZE. - **Access:** Read-only. - **Data WIZE reads:** accounts (constituents, with addresses, emails, phones and custom "defined values"), journal gifts, payments and pledges, journal notes and contacts, and your fund, campaign, approach and letter lists. - **Sync:** initial import, then a daily full re-sync. eTapestry's journal filters work on the entry's own date rather than a "changed since" date, so WIZE re-reads the full data set each night — that way edits, refunds and reversals stay current. - **What your admin sets up:** in eTapestry go to **Management → My Organization → Subscriptions**, find the **API Subscription** tile and select **Enable API Subscription**. The tile then shows the API Key and Database ID. **API access is switched off until an admin does this** — until then there is no key to paste and the connection will fail. - **Which records WIZE reads:** eTapestry has no "list everything" call — it reads through a saved query, and WIZE defaults to eTapestry's built-in **Base** queries for all constituents and all journal entries. If your database renames or re-files those queries, you can point WIZE at your own when you connect. - **Connection details:** SOAP endpoint `https://etapestry.sky.blackbaud.com/v3messaging/service`. (eTapestry may move a database between sites; WIZE follows the relocation automatically.) ### GoFundMe Pro (formerly Classy) **If you use Classy, this is your integration.** GoFundMe acquired Classy and renamed the product to GoFundMe Pro. The platform, your account, and the API are the same — only the name changed. Look for the **GoFundMe Pro** card in WIZE. - **Connection level:** Organization. - **Authentication:** an **API application**, not a pasted key. An admin creates the application in GoFundMe Pro and gives you its **Client ID** and **Client Secret**; WIZE exchanges those for a short-lived access token on every sync and refreshes it automatically. You also provide your **Organization ID**. - **Access:** Read-only. WIZE never writes to your GoFundMe Pro account — it cannot create, edit, or refund a donation, or change a campaign. - **Data WIZE reads:** supporters (your donor records), transactions (donations, with campaign/designation and recurring-plan links), campaigns, recurring donation plans, designations (funds), fundraising pages, and fundraising teams. - **Sync:** initial import, then a daily full re-sync. GoFundMe Pro does not publish a "changed since" date filter we can rely on, so WIZE re-lists the full data set each night rather than an incremental delta. That keeps edits and refunds to older transactions current. - **What your admin sets up:** 1. In GoFundMe Pro, go to **Settings → Integrations → API** and create an API application. 2. Copy its **Client ID** and **Client Secret** (the secret is usually shown once — save it before closing the dialog). 3. Find your **Organization ID**: it is the number in your admin URL, e.g. `app.classy.org/admin/`**`123456`**`/...`. 4. Paste all three into WIZE and click **Connect**. WIZE verifies them immediately and tells you if any is wrong. - **Connection details:** host `https://api.classy.org` (the API kept the Classy domain after the rebrand). - **Not included:** the organization activity feed, peer-to-peer page editing, and anything that writes back to GoFundMe Pro. ### OneCause - **Not the same as Salsa Engage / EveryAction.** Both are Bonterra products, but OneCause is the **event-fundraising** platform (galas, silent and live auctions, text-to-bid, event ticketing, event-night mobile giving) and it uses its own API and its own credential. Connecting Salsa Engage does not connect OneCause, and vice versa — if you use both, connect both. - **Connection level:** Organization. - **Authentication:** two values, both shown together in OneCause — your **Organization ID** and an **API key**. A Fundraising Platform **Admin** creates the key under **Settings → API Keys → Create API Key**; the Organization ID appears beside it and is the same for every key your organization creates. Paste both into WIZE. - **The key belongs to the person who made it.** A OneCause API key stays valid only while that user still has Admin access to the Fundraising Platform. If they leave or are downgraded, the key stops working and WIZE will report the connection as failed — have another Admin create a new key and paste it in. - **Access:** Read-only. WIZE never writes to OneCause, and never touches bidding, auction, or event-night operations. - **Data WIZE reads:** event supporters (individuals and companies) and **paid** transactions — completed auction purchases, tickets, and donations. - **Unpaid activity is kept out of your giving totals.** OneCause also exposes *unpaid* items: purchases someone started but never paid for. WIZE imports those separately as reference data and deliberately does **not** count them as gifts, so a bidder who never settled up doesn't inflate their giving history. - **Sync:** initial import, then a daily full re-sync (WIZE re-lists everything each night rather than an incremental delta), which is what keeps edits and refunds current. - **What your admin sets up:** create the API key as a Fundraising Platform Admin and copy both the key and the Organization ID. - **Connection details:** host `https://phaas-public-api.onecause.com`. - **If the connection is rejected:** check that the Organization ID is the one shown beside the key (not an event ID), and that the person who created the key still has Admin access. ### Neon CRM - **Connection level:** Organization. - **Authentication:** **HTTP Basic auth** with two values — your Neon **organization ID** and an **API key**. Your organization ID is the short name your Neon instance is identified by. Generate the key in Neon under **Settings (cog) → User Management →** select or create a user **→ enable API Access →** copy the key. Paste both into WIZE. - **The key inherits its user's permissions.** A Neon API key can only see what that Neon user can see, so use (or create) a user who can view constituents and donations. If that user later loses access, the key stops working. - **Access:** Read-only. WIZE only reads from Neon and never creates, edits, or deletes anything in your Neon account. - **Data WIZE reads:** individual accounts (your constituents), organization/company accounts, donations, campaigns, funds, and events. - **Sync:** initial import, then a daily full re-sync — WIZE re-lists your whole data set each night rather than an incremental delta, which is what keeps edits, refunds, and account changes current. - **Not synced:** memberships, recurring-donation schedules, and store orders. Neon exposes those per constituent rather than as an organization-wide list, so they are not part of the nightly import. - **What your admin sets up:** enable API Access on a Neon user and share the key plus the organization ID. - **Connection details:** host `https://api.neoncrm.com/v2`. WIZE pins the Neon API version it requests, so a Neon release cannot change your data shape unannounced. Neon *trial* instances are on a different host and are not supported. - **If everything connects but nothing syncs:** check that the Neon user whose key you used can still see constituents and donations — a key scoped to a restricted user connects successfully and then reads nothing. ### iMIS (ASI) - **Connection level:** Organization. - **Authentication:** iMIS's REST API with an **OAuth2 password grant**. You provide four values to WIZE: your **iMIS site URL**, a **REST API username** and its **password**, and the **IQA query path** your gifts are read from. - **Your site URL is part of the credential.** Unlike most CRMs, iMIS has no shared cloud address — iMIS Cloud, ASI-hosted and on-premise installs all answer on your own domain. Enter it as `https://members.yourorg.org`. If you are on **iMIS 2017 SP E or earlier**, add the scheduler path: `https://members.yourorg.org/asiScheduler`. - **Accepted site URLs:** WIZE only connects to a site that is `https://`, on the standard port (443), reachable at a public address, with at most one path segment (`/asiScheduler`). Because WIZE sends your API user's password to that address, it will not connect over plain `http`, to an IP address, to a custom port, or to a host that resolves onto a private network. If your iMIS is only reachable inside your own network, WIZE cannot connect to it — that is a firewall/DNS decision on your side, not a bad password. - **Access:** Read-only. WIZE never writes to iMIS. - **Data WIZE reads:** contacts (iMIS **Party** records — both people and organizations) and gifts. - **Sync:** initial import, then a daily full re-sync. iMIS's "changed since" filtering is a parameter of your own IQA query rather than a standard API feature, so WIZE re-lists everything each night, which is what keeps edits and adjustments current. - **Not synced:** groups, events, memberships and fund/appeal reference data — each of those would need its own IQA query. - **What your admin sets up:** 1. **A REST API user account.** Contact **ASI Technical Support** to have one provisioned; ASI notes this may carry a cost. 2. **An IQA query returning your gifts**, published in iMIS and **granted access to the REST API** (in iMIS: the query's REST access setting). There is no standard gift endpoint in iMIS, so this query IS how WIZE reads gifts. Give WIZE its full path, e.g. `$/Fundraising/Queries/WizeGifts`. - **Connection details:** per-site host `https:///api/` with the token at `https:///token/`; contacts read from `/api/Party` and gifts from `/api/IQA`. - **If contacts sync but gifts do not:** the gift query is the thing to check — confirm its path is exactly what you gave WIZE, that it is still published, and that its REST API access is still granted. A query that loses REST access returns no rows rather than an error. ### Microsoft Dynamics 365 - **Connection level:** Organization. - **Works with:** any Dynamics 365 customer-engagement environment — Sales, Customer Service, or Microsoft's nonprofit **Fundraising and Engagement** solution. They all store data in Dataverse, which is what WIZE reads. - **Authentication:** a **Microsoft Entra ID app registration in your own tenant**, using client credentials. WIZE does not hold a Microsoft app for this — you create one, so your IT team can see it, scope it, and revoke it at any time. - **What your admin sets up** (all in your own Microsoft tenant, about ten minutes): 1. In the **Microsoft Entra admin center**, register a new application and create a **client secret**. Copy the secret value immediately — it is shown only once. 2. Note the **Directory (tenant) ID** and the **Application (client) ID** from the app's Overview page. 3. In the **Power Platform admin center**, open your Dynamics environment → **Settings → Users + permissions → Application users → New app user**, add the app you just registered, and give it a **read-only security role**. WIZE only reads, so a role with read privileges on Contacts, Accounts, Opportunities (or Transactions) and Notes is enough. 4. Copy your **environment URL** — the `https://yourorg.crm.dynamics.com` address you see in the browser. - **Paste into WIZE:** environment URL, Directory (tenant) ID, Application (client) ID, client secret. - **Access:** Read-only. WIZE never writes to Dynamics. - **Data WIZE reads:** contacts (people), accounts (organizations and households), donations, notes, and campaigns. - **Where donations come from:** if your environment has Microsoft's Fundraising and Engagement solution, WIZE reads its **Transaction** records. If it doesn't, WIZE reads **won opportunities** — closed-won revenue only. Open and lost pipeline is never treated as a gift. If your organization records donations somewhere else entirely (a custom table), gifts will come through empty — tell us and we'll map it. - **Sync:** initial full import, then a daily incremental sync using each record's last-modified date. - **Not supported:** Dynamics environments in the China (`.crm.dynamics.cn`) or US Government (`.crm.microsoftdynamics.us`) clouds — those sign in against a different Microsoft authority. Ask us if you need one. - **Connection details:** host `https://.crm.dynamics.com`, Dataverse Web API `v9.2`. - **If the connection is rejected:** the most common cause is step 3 — the app registration exists but has not been added to the *environment* as an application user with a security role. A client secret that has expired is the second most common; Entra secrets expire on a schedule (often 180 days), and WIZE will ask you to reconnect when that happens. ### Ellucian Banner - **Connection level:** Organization. - **Authentication:** an **Ethos Integration API key** (a GUID). In Ellucian Ethos, open **Applications → your application → API Key** and copy it. WIZE exchanges that key for a short-lived token on every run; the key itself is stored encrypted and never leaves WIZE. - **Access:** Read-only. WIZE only ever issues GET requests through Ethos and never writes to Banner. - **Data WIZE reads:** alumni constituents (`persons`), organizations, gifts, and campaigns. - **Two optional fields on the connect form:** - **Advancement gift resource.** Banner has no standard gift API. Gifts are served by a resource *your institution publishes* through Ethos (usually with Ellucian **Data Connect**), so its name is yours to choose — often something like `x-advancement-gifts`. Leave the field blank and WIZE looks for the common names; if it can't find one, it tells you exactly which resources your Ethos tenant does expose so you can name the right one (or publish it) and reconnect. - **Ethos region.** WIZE connects to the **US** region by default (`integrate.elluciancloud.com`). Enter `canada`, `europe` or `australia` if your institution is on one of those. - **Constituents are alumni by default.** Banner's `persons` resource is everyone the ERP knows — current students, applicants, parents, staff, vendors — so WIZE asks Ethos for the **alumni** role only. That keeps student records out of your fundraising data and keeps the nightly sync to a sane size. A donor who has no alumni role (a friend, a parent, a company contact) therefore won't appear as a constituent, and their gifts import without a linked person. Tell us if you need other roles included — it is a setting, not a code change. - **Sync:** initial import, then a daily full re-sync. The Ellucian data model has no "changed since" filter, so WIZE re-lists everything each night rather than a delta — that is what keeps edits and adjustments current. - **What your admin sets up:** an Ethos application with proxy access to `persons`, `organizations` and your advancement gift resource, and its API key. - **Connection details:** host `https://integrate.elluciancloud.com` (US region). - **If the connection is refused with a list of resources:** that list is what your Ethos application can actually see. If your gift API isn't in it, the application doesn't have proxy access to it yet — an Ethos administrator grants that, then reconnect. ### Slate (Technolutions) - **Connection level:** Organization. - **Authentication:** a **Service Account** user connecting over Slate's **Open API** with HTTP Basic auth. You provide three values to WIZE: your Slate **hostname** (e.g. `yourschool.technolutions.net`), the service-account **username**, and its **password**. - **Access:** Read-only. - **Data WIZE reads:** persons (constituents), gifts, and applications. - **Sync:** initial import, then a daily full sync. - **What your admin sets up:** create a **Service Account user with Open API access** in Slate, then provide WIZE the hostname, username, and password. - **Connection details:** per-instance host `https:///manage/service` (Open API). ### NetSuite (Oracle) - **Connection level:** Organization. - **What it is for:** NetSuite is an **accounting/ERP** system, not a donor database. WIZE reads your books so it can **reconcile gifts against the general ledger** and answer questions like "did the March appeal revenue post to the right fund?" If your donors live in a separate CRM (commonly Salesforce), connect that too — NetSuite answers the finance half. - **Authentication:** **Token-Based Authentication (TBA)**, NetSuite's OAuth 1.0 scheme. You provide five values: the **Account ID**, a **Consumer Key** and **Consumer Secret** (from an Integration record), and a **Token ID** and **Token Secret** (from an Access Token). TBA credentials do not expire, so the connection does not need periodic re-authorising. - **Access:** **Read-only.** WIZE never writes to your general ledger. - **Data WIZE reads:** customers, income transactions (customer deposits, cash sales, journals), the chart of accounts, deposits, and journal entries. - **Sync:** initial import, then a daily incremental sync using each record's last-modified date. - **What your admin sets up (in NetSuite):** 1. **Setup → Company → Enable Features → SuiteCloud** — enable **Token-Based Authentication** and **REST Web Services**. 2. **Setup → Integration → Manage Integrations → New** — create an integration record with Token-Based Authentication checked. This gives you the **Consumer Key** and **Consumer Secret** (shown once). 3. **Setup → Users/Roles → Access Tokens → New** — create a token for a user and a **role that has REST Web Services permission**. This gives you the **Token ID** and **Token Secret** (shown once). 4. **Setup → Company → Company Information** — copy the **Account ID** (e.g. `1234567`, or `1234567_SB1` for a sandbox). - **Connection details:** per-account host `https://.suitetalk.api.netsuite.com`, queried with SuiteQL. - **If the connection is rejected:** the most common cause is the role attached to the access token lacking **REST Web Services** permission — the credentials themselves look correct but every request is refused. Check that before regenerating tokens. - **A note on scale:** NetSuite caps a single query at 100,000 rows. Organisations with more transaction history than that will see the oldest records fall outside what WIZE can read. ### VolunteerHub - **Connection level:** Organization. - **Authentication:** VolunteerHub's Open API uses **HTTP Basic auth** with a **Superuser** account — there is no OAuth and no scoped API key. You provide three values to WIZE: your VolunteerHub **organization URL** (e.g. `yourorg.volunteerhub.com`), a Superuser **username**, and its **password**. API access is free for Superusers. - **Access:** Read-only (every VolunteerHub API endpoint is a GET). - **Data WIZE reads:** volunteers (users), events, event groups, and user groups. - **Sync:** initial import, then daily — volunteers sync incrementally (VolunteerHub's `LastUpdate` watermark); events and groups are refreshed in full each run. - **What your admin sets up:** ensure you have a **Superuser** account (its password must be under 16 characters), then provide WIZE the organization URL, username, and password. - **Connection details:** per-org host `https://.volunteerhub.com/api/...`. Donations are not synced (they require VolunteerHub's paid Volunteer Fundraising feature). - **Security note:** VolunteerHub's API grants access only at the Superuser level (no read-only/scoped credential exists), so WIZE stores full-Superuser credentials, encrypted at rest like all other integration secrets. ### vCita - **Connection level:** Organization. - **Authentication:** API token. In vCita, go to **Settings → Integrations → Webhooks → Connect** and copy the token, then paste it into WIZE (sent as a `Bearer` token). The token is generated by the business owner — there is no OAuth app and no partner credential involved. - **Access:** Read-only. - **Data WIZE reads:** clients (imported as constituents) and payments (imported as gifts, linked back to the client who made them). WIZE requests no field subset from vCita, so each client and payment record is imported **whole** — the fields vCita returns on it (name, email, mobile phone, and anything else your account holds) all become queryable in chat. vCita has no household or organization record that maps to a WIZE account, so none is imported. - **Sync:** initial import, then a daily full re-sync. vCita documents modified-since filters, but none is verified against a live account, and a filter that silently did nothing would stop importing new records while still reporting success — so WIZE re-lists the full data set each night instead. - **What your admin sets up:** the vCita business owner generates the API token; nothing else is required. - **Connection details:** host `https://api.vcita.biz/platform/v1`. ### Tessitura - **Connection level:** Organization. - **Authentication:** an **API user type** account in Tessitura, over HTTP Basic auth. Tessitura's credential is four values that WIZE combines into one — the **user name**, the **user group**, the **location**, and the **password** — so you paste all four separately (WIZE joins them for you; that is also why the first three cannot contain a colon). Access to the Tessitura API is included with your Tessitura license at no extra charge. - **API address:** whichever matches your hosting — RAMP cloud `https://.tessituranetworkramp.com/LiveAPI/TessituraService`, TNHS cloud `https://webprod.tnhs.cloud/tessitura/api`, or self-hosted, usually `https://tessexternal..org/TessituraService`. It must be **https**, and it must be reachable from the public internet. - **List ID (required):** the numeric ID of a **Tessitura List** (Reporting → Lists) holding the constituents you want in WIZE. This is not an optional filter — it is how WIZE knows which people to sync. Your Tessitura constituent table also contains every single-ticket buyer your organization has ever had, which is not your donor file, so WIZE reads a list you curate instead: your donor list, your patron list, or your prospect list. The list must hold **10,000 constituents or fewer**; WIZE refuses a larger one rather than starting a sync it cannot finish overnight, and it tells you the number it saw. - **Access:** Read-only. WIZE never writes to Tessitura. - **Data WIZE reads:** the constituents in your list, and each of their **contributions** (imported as gifts, linked back to the constituent they belong to). - **Not synced yet:** **memberships** and **ticketing orders / performances** — Tessitura's list and output-set endpoints return columns *about constituents*, so there is no route that hands WIZE one row per membership or per ticket order, and WIZE will not guess at one. **Households** are not imported as separate organization records either: Tessitura stores households as constituents, so a household in your list arrives as a constituent. If any of these matter to you, tell us — they need a live Tessitura instance to build against. - **Sync:** initial import, then a daily full re-sync. Tessitura has no "everything changed since yesterday" read, so each run re-reads the list. - **What your admin sets up:** (1) create an **API user type** account and put it in a **User Group** that can read constituents, contributions, and the list you chose — a group that is too narrow returns empty results rather than an error, so WIZE checks the permissions when you connect and tells you which one is missing; (2) build the **List** and note its numeric ID; (3) if your instance is **self-hosted**, ask IT to allow WIZE's outbound requests through your firewall (IP allowlisting). - **If connecting fails,** the message names the part that failed: the credential, the User Group's permissions, a list that does not exist, a list that is too large, or a list filter your instance ignored. WIZE refuses to sync in that last case rather than importing your whole constituent database. --- ## Data sync ### Airtable Airtable is not a CRM connection: instead of importing into WIZE's constituent and gift tables, it mirrors a table you choose into a WIZE spreadsheet you can query in chat. - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow with **mandatory PKCE (S256)**. You sign in to Airtable and choose which bases to grant access to; WIZE holds the application credentials. Access tokens live 60 minutes and the refresh token is rotated on every refresh, so revoking WIZE from Airtable's own integrations screen ends access at the next refresh. - **Scopes requested:** `data.records:read` and `schema.bases:read` — **read scopes only.** No write scope is requested, so WIZE cannot create, edit, or delete anything in Airtable. - **Access:** Read-only. - **Data WIZE reads:** the base and table list you grant access to, and the records of each table an Organization member explicitly chooses to sync. Nothing is read from a base you did not share. - **Sync:** each configured base + table maps to exactly one WIZE spreadsheet whose id and URL never change. WIZE runs an initial import on configuration, then a nightly full reconcile (03:00 UTC): records are matched on Airtable's stable record id, new and changed records are written, and records deleted in Airtable are deleted from the mirror. - **The mirror is edit-locked in WIZE.** Because every run rewrites the spreadsheet in place, manual edits would be lost — so WIZE blocks them with an explanatory message rather than accepting and silently discarding them. Change the data in Airtable. - **Field types:** values are flattened to text — a list of values is comma-joined, and a structured value (attachment, linked record) is stored as its JSON representation. Airtable's record id is kept as a hidden column used only for matching. - **Rate limits:** WIZE paces its reads to stay under Airtable's 5 requests/second per base limit and backs off on a 429. - **What your admin sets up:** nothing inside Airtable beyond approving access and choosing which bases to share. - **Connection details:** authorization host `airtable.com`; data host `api.airtable.com`; redirect URL `https://app.wizenow.com/api/oauth/callback/airtable/`. ### Andar - **Connection level:** Organization. - **Authentication:** an **API access token** created in Andar (`System Administration > Security > API Tokens Maintenance`), sent as a bearer token. You provide two values to WIZE: your **base web address** (the e-Community address, e.g. `https://ecommunity.yourorg.org/andarweb`) and the **access token**. - **Access:** Read-only. WIZE only runs Executive Plus exports; it never uses Andar Connector to import data back into Andar. - **Data WIZE reads:** constituents, accounts, and gifts — plus pledges, contacts, and campaigns if you create those optional components. - **Sync:** initial import, then a daily full sync. - **Connection details:** per-instance host `https:///rest/api/v2/` (Andar API module version 2). **Andar needs an API module license, and Version 2 of the API module.** Version 1 is not compatible. #### What your Andar administrator sets up 1. **Turn the API on.** `System Preferences > System Preferences > General > API Settings` → select **Enable API Integration**. 2. **Create the access token.** `System Administration > Security > API Tokens Maintenance` → **Add**. Leave **Requires Refresh** *off* — WIZE syncs on a nightly schedule and needs a token that does not expire. (With it on, Andar expires the token one hour after it is generated and the nightly sync will fail.) Copy the **Access Token**. 3. **Create the export components** below. #### The Executive Plus components WIZE reads Andar's API exports data by running an **Executive Plus component** of the **API Data Export** type, so WIZE reads exactly the components you build for it. Create them with these exact names: | Component name | Required? | Becomes | |---|---|---| | `WizeConstituents` | **Required** | Your constituent records | | `WizeAccounts` | **Required** | Your account/organization records | | `WizeGifts` | **Required** | Your gift and pledge history | | `WizePledges` | Optional | Extra pledge detail | | `WizeContacts` | Optional | Contact/interaction history | | `WizeCampaigns` | Optional | Campaign records | **Every component must expose a column aliased `id`** holding that record's unique key. `WizeGifts` (and any optional component that relates to a person or account) should also expose `constituent_id` and `account_id`, and `WizeGifts` should expose `gift_date` and `amount`. Column names are matched case-insensitively, so `ID` and `Gift_Date` are fine. **Every component must page.** WIZE reads your data in batches, and Andar's export endpoint has no paging of its own — so each component's SQL must accept the substitution variables `wize_offset` and `wize_limit` and must have a deterministic `ORDER BY`. A component that ignores them would return the same first batch over and over, so WIZE checks this when you connect and refuses the connection if paging isn't working. A minimal `WizeConstituents` looks like this: ```sql SELECT a.accountNumber AS id, a.firstName AS first_name, a.lastName AS last_name, a.emailAddress AS email FROM Individuals a ORDER BY a.accountNumber OFFSET {wize_offset} ROWS FETCH NEXT {wize_limit} ROWS ONLY ``` …and `WizeGifts` follows the same shape, adding `constituent_id`, `account_id`, `gift_date` and `amount`: ```sql SELECT g.giftId AS id, g.accountNumber AS constituent_id, g.accountNumber AS account_id, g.giftDate AS gift_date, g.giftAmount AS amount FROM Gifts g ORDER BY g.giftId OFFSET {wize_offset} ROWS FETCH NEXT {wize_limit} ROWS ONLY ``` Add any other columns you want WIZE to be able to answer questions about — everything a component returns is imported and available in chat. #### If the connection is refused - *"could not find an Executive Plus component named WizeConstituents"* — the component doesn't exist yet, is named differently, or isn't of the **API Data Export** type. - *"ignored the {wize_offset} substitution variable"* — the component's SQL doesn't use `OFFSET {wize_offset} ROWS FETCH NEXT {wize_limit} ROWS ONLY`, or has no `ORDER BY`. - *"returned rows without an 'id' column"* — alias the record's unique key as `id`. - *"must be reachable at a public internet address"* — your Andar server isn't reachable from the internet, so WIZE's servers cannot connect to it. - *"must use https"* — WIZE sends your access token on every request and will not put it on an unencrypted connection. Your e-Community site needs a valid TLS certificate. - *"rejected the access token"* — regenerate the token, or check it hasn't been revoked. - *"check that API integration is enabled"* — step 1 above, or the component is the wrong type. **WIZE reaches your Andar server directly over the public internet, over https only**, so it does not support connections that require a private network, a VPN, an outbound proxy, or a privately-issued TLS certificate. **WIZE re-checks all three required components before every nightly sync**, not just when you first connect. If your Andar administrator renames one or edits its SQL, the sync stops rather than importing partial data — so a broken component costs you one night's refresh, never your existing data in WIZE. --- ## Email & calendar Email and calendar are **Personal** connections — each teammate connects their own account, and WIZE only reads or acts on it in the moment they ask, in chat. There is no background sync. **WIZE only ever creates drafts and calendar events for you to review; it never sends email on its own.** ### Google Workspace - **Connection level:** Personal (each user connects their own Google account). - **Authentication:** OAuth 2.0 authorization-code flow. WIZE hosts the connected app; you sign in and approve access. - **Scopes requested:** `gmail.readonly`, `gmail.compose`, `calendar.events`, `userinfo.email`, `userinfo.profile`, `drive.metadata.readonly`, `drive.file`. - **What those mean:** read your email and create drafts; read and create calendar events; your address and name; see the names of your Drive files when you search, without reading them; and open the contents of the specific files you pick. - **Signing in with Google** is a smaller request — `openid`, `email`, `profile`. - Signing in grants no access to your mail, calendar or Drive. Depending on how WIZE is configured it may use the same registered app as the connection above. - **Access:** read email, calendar, and Drive; **create email drafts and calendar events.** WIZE only ever creates email as a **draft** in your Drafts folder — you review and send it. WIZE never writes to Drive: it can list file names to help you find something, and read the contents only of files you hand it through Google's own file picker. - **Access model:** on-demand in chat only; no background sync. - **What your admin sets up:** typically nothing — users self-authorize. If your Google Workspace domain restricts third-party app access, a Workspace admin may need to allow the WIZE OAuth app. - **Connection details:** Gmail/Calendar/Drive APIs on `googleapis.com`; redirect URL `https://app.wizenow.com/api/oauth/callback/google/`. ### Microsoft Outlook - **Connection level:** Personal (each user connects their own Microsoft account). - **Authentication:** OAuth 2.0 authorization-code flow via the Microsoft identity platform (multi-tenant `common` endpoint) against Microsoft Graph. WIZE hosts the connected app; you sign in and approve access. - **Scopes requested:** `offline_access`, `User.Read`, `Mail.Read`, `Mail.ReadWrite`, `Calendars.Read`, `Calendars.ReadWrite`, `Files.Read`. **`Mail.Send` is deliberately not requested**, so WIZE cannot send mail — it can only create drafts. - **Access:** read mail, calendar, and OneDrive files; **create email drafts and calendar events.** Email is only ever created as a **draft** for you to review and send. - **Access model:** on-demand in chat only; no background sync. - **What your admin sets up:** - The account needs a REST-enabled Exchange Online mailbox — WIZE verifies mailbox access at connect time and declines the connection if the mailbox is on-premises or not REST-enabled. - If your tenant requires admin consent for third-party apps, or restricts app permissions via conditional-access policy, a Microsoft admin may need to consent to / allow the WIZE app. - **Connection details:** Microsoft Graph `https://graph.microsoft.com/v1.0`; redirect URL `https://app.wizenow.com/api/oauth/callback/outlook/`. --- ## Project management Asana and Monday.com are **Organization** connections. WIZE reads and writes only in the moment you ask, in chat — there is no background sync, and changes you make directly in Asana/Monday.com are not copied back into WIZE. ### Asana - **Connection level:** Organization (connects one Asana workspace — the one you approve). - **Authentication:** OAuth 2.0 authorization-code flow. Sign in with Asana and approve access — no keys to copy. - **Scopes requested:** `tasks:read`, `tasks:write`, `projects:read`, `users:read`, `workspaces:read`. - **Access:** read + write. WIZE can list projects, search tasks, and look up workspace members; and **create tasks and update them** (name, notes, due date, assignee, completion). - **Access model:** on-demand in chat only. - **What your admin sets up:** the person connecting approves access to their workspace. Workspace-wide search is fastest on paid Asana plans; on free plans WIZE finds tasks by looking through projects instead. - **Connection details:** host `https://app.asana.com/api/1.0`; redirect URL `https://app.wizenow.com/api/oauth/callback/asana/`. ### Monday.com - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow. Sign in with Monday.com and approve access. (Scopes are configured on WIZE's Monday app; the token does not expire.) - **Access:** read + write. WIZE can list boards, search board items, and read groups/columns; and **create items and update them** (rename, status, dates, and custom columns). - **Access model:** on-demand in chat only. - **What your admin sets up:** the person connecting approves access to their account. - **Connection details:** host `https://api.monday.com/v2` (GraphQL); redirect URL `https://app.wizenow.com/api/oauth/callback/monday/`. --- ## Prospect research ### Connect The Dots - **Connection level:** Personal — each person connects their own account. Your professional network is yours, and WIZE never reaches into a colleague's Connect The Dots account on your behalf. - **Authentication:** two pasted values — your **API key** and the **email address on your Connect The Dots account** (sent as the `ctd-client-id` header). No OAuth, no redirect. - **Requires a paid Connect The Dots plan.** API access starts at **Professional**; the free tier does not expose the API at all. The account and the subscription are yours — WIZE does not buy or resell them. - **Where to get the key:** in Connect The Dots, go to **Settings → API access**. - **Access:** read-only. WIZE can find a **warm introduction path** to a person or organization, look up **who your team already knows** somewhere, and list **recent job changes** in your network. It cannot send anything — Connect The Dots' "ghost email" introduction-sending feature is deliberately not connected. - **Access model:** on-demand in chat only. Results are shown in the conversation; WIZE does not copy your network into its own database. - **What comes back:** information about real people outside your organization (a prospect, and the colleague who can introduce you). Treat it like any other prospect research. ## Communication ### Slack - **Availability:** being switched on. The Slack card in **Integrations** shows **"Setup in progress"** with Connect disabled until the WIZE team finishes provisioning the Slack app; while it does, Slack is not connectable and WIZE will not offer it. The card enables itself — there is nothing for a customer or an admin to do to trigger it. - **Connection level:** Organization (one Slack workspace per WIZE organization). - **Authentication:** OAuth 2.0 authorization-code flow (Slack "install the app" consent). The bot token Slack issues does not expire; WIZE does not use token rotation. - **Scopes requested:** `channels:read`, `groups:read`, `channels:history`, `groups:history`, `chat:write`, `users:read`. - **Access:** read + write, **confined to channels the WIZE app has been invited to.** WIZE deliberately does **not** request `chat:write.public`, the scope that would let it post into any public channel without being a member — so the channels WIZE can reach are exactly the ones a person added it to, and nothing else. - **Access model:** on-demand in chat only. No background reading, no sync, no stored copy of your Slack messages. - **Not supported:** direct messages, searching across Slack, and reading channels the app has not been invited to. - **What your admin sets up:** two things. Many workspaces restrict who can install apps — if yours does, Slack routes the install to a workspace admin for approval, and the Integrations card stays "Not connected" until they approve it (Slack does not tell WIZE that a request is pending). Then someone invites the WIZE app to each channel it should work with, with `/invite @WIZE`. - **Removing it:** disconnecting from **Integrations** revokes the token, which removes the WIZE app's access to the workspace. - **Connection details:** host `https://slack.com/api`; redirect URL `https://app.wizenow.com/api/oauth/callback/slack/`. --- ## Email marketing ### Mailchimp - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow. Sign in with Mailchimp and approve access. WIZE detects your account's data center automatically. - **Access:** read your audiences and **create campaign drafts.** **WIZE never sends** — reviewing and sending always happens by a person in Mailchimp. - **Access model:** on-demand in chat only. - **What your admin sets up:** the person connecting approves access to their Mailchimp account. - **Connection details:** per-account host `https://.api.mailchimp.com/3.0`; redirect URL `https://app.wizenow.com/api/oauth/callback/mailchimp/`. ### Constant Contact - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow. Sign in with Constant Contact and approve access. - **Access:** read your contact lists and **create campaign drafts.** **WIZE never sends** — reviewing and sending always happens by a person in Constant Contact. - **Access model:** on-demand in chat only. - **What your admin sets up:** the person connecting approves access to their Constant Contact account. Constant Contact only lets a campaign use a **confirmed** sending address, so make sure at least one email address in your account is confirmed — otherwise draft creation will tell you to confirm one first. If you ask WIZE to route replies to an address that isn't confirmed in Constant Contact, it will use your confirmed address instead and say so. - **Connection details:** host `https://api.cc.email/v3`; redirect URL `https://app.wizenow.com/api/oauth/callback/constant_contact/`. - **If you connect both Mailchimp and Constant Contact:** WIZE will ask which account a draft should go to rather than guessing. --- ## Accounting & finance Accounting connections are **Organization-level** and **read-only**. Unlike CRM connections, WIZE imports **nothing**: it reads your books live, only while answering a question you asked, and stores no copy of your financial records. ### QuickBooks Online - **Connection level:** Organization. - **Authentication:** OAuth 2.0 authorization-code flow with Intuit. Sign in, pick the company (QuickBooks calls it a "realm"), and approve access. - **Access:** **Read-only.** WIZE never creates, edits, or deletes anything in QuickBooks — no transactions, no journal entries, no accounts. - **Access model:** on-demand in chat only. No scheduled import, no stored copy of your books. - **Data WIZE reads:** deposits, sales receipts, payments, invoices, journal entries, your chart of accounts, and your classes. - **No 30-day limit.** WIZE reads whatever date range you ask about, including past years — it queries your books directly rather than watching a feed of recent changes, so history is available from day one, not just transactions since you connected. - **Connection details:** data host `quickbooks.api.intuit.com`; redirect URL `https://app.wizenow.com/api/oauth/callback/quickbooks/`. **What you can ask in chat** - *"How much did we deposit in July?"* — totals straight from the books. - *"What's in the Annual Fund class?"* — reads your classes and accounts by name. - *"Do our recorded gifts match what hit the books last month?"* — WIZE compares the gifts in your CRM against QuickBooks deposits over a date range and tells you which ones it could not match on either side. **Two things worth knowing about reconciliation** - **Deposits are not the same as donation revenue.** Grant cheques, program income, transfers, and refunds all land in your deposit total too, so the books total will normally be larger than your gift total. WIZE says so in its answer rather than presenting the gap as a problem. - **Matching is on exact amounts,** within a few days either side. If your CRM records gifts gross and your books record them net of processor fees, those will not match — that difference is real, and WIZE surfaces it instead of smoothing it over. **A note on the Intuit permission screen:** Intuit offers only one accounting permission, and it covers both reading and writing — there is no read-only option to choose. The consent screen will therefore mention write access. WIZE does not use it: no write capability exists anywhere in the QuickBooks integration. --- ## Design ### Canva - **Connection level:** Personal. Each person connects their own Canva account — connecting yours does not give the rest of your organization access to your designs, and a design you bring into WIZE stays private to you. - **Authentication:** OAuth 2.0 authorization-code flow with PKCE. Click Connect, sign in to Canva, and approve access. - **Access:** list your designs, bring a design into WIZE as a document (PNG or PDF), and upload a WIZE image into your Canva uploads. WIZE never edits or deletes your Canva designs. - **Access model:** on-demand in chat only. Ask WIZE things like "list my Canva designs", "bring my spring appeal flyer in here as a PDF", or "put this image in my Canva uploads". - **Multi-page designs:** a PNG export covers the first page only — ask for PDF to bring in every page. - **Not included:** filling a Canva Brand Template with your data (autofill). That part of Canva's API is limited to Canva Enterprise organizations, so it isn't part of this integration. - **What your admin sets up:** nothing — each person connects their own account. - **Connection details:** host `https://api.canva.com/rest/v1`; redirect URL `https://app.wizenow.com/api/oauth/callback/canva/`. --- ## Texting (SMS) ### Tatango (momoGood) Tatango is now part of **momoGood** — the developer docs moved to `developers.momogood.com`, but you still sign in at `app.tatango.com` and the product is the same one you know. - **Connection level:** Organization. - **Authentication:** HTTP Basic — your Tatango **login email** plus an **API key**. In Tatango: **My Account → API**, then paste both into WIZE under **Settings → Integrations → Tatango**. - **Access: read-only.** WIZE can see your SMS lists (name, subscriber count, keywords) and your past text messages, including how many were delivered and how many people opted out. - **WIZE cannot send, schedule, or save a text message — at all.** This is not a policy setting you can turn on: Tatango's API provides no way for an outside tool to create a draft or schedule a send. WIZE writes the copy in your chat; you paste it into Tatango and send it there yourself. If WIZE ever tells you a text has been queued or sent, that is wrong — check Tatango. - **Access model:** on-demand in chat only. Nothing is synced or stored on a schedule. - **Consent and opt-ins are untouched.** Text messaging is opt-in and regulated (TCPA), and your lists carry their own opt-in type and keywords. WIZE cannot add, remove, or unsubscribe a subscriber, and cannot change an opt-in setting — it has no write access of any kind. - **What your admin sets up:** an API key in Tatango. Keys are shown per account; rotating the key in Tatango means updating it in WIZE. - **Connection details:** host `https://app.tatango.com/api/v2` (Messaging API v2). No redirect URL — there is no OAuth flow. **Good uses:** "Which of my text lists should this year-end appeal go to?", "How did our last three text appeals perform?", "Draft a 160-character version of this email appeal for our Mobile list." ### Emma (Marigold) - **Connection level:** Organization. - **Authentication:** API key. In Emma, go to **account settings → the "API Key" tab → Generate API Key**. That gives you three values, and WIZE needs all three: your **account ID**, your **public API key** and your **private API key**. If your account sits under an agency/HQ account, generate the key from the **subaccount** (Menu → Accounts → the account's settings) and use that subaccount's ID. - **Access:** read your Emma **groups**, and **add contacts to a group** you pick. WIZE never removes anyone from a group, never deletes a contact, and **never sends anything**. - **Writing and sending the email stays in Emma.** This is a limit of Emma's API, not a WIZE choice: Emma's public API can list and update your audience, but it has no way to create a campaign — so WIZE cannot draft one for you the way it can in Mailchimp. Use WIZE to get the right people into the right group, then write and send from Emma. - **Contacts are added or updated, never replaced.** If someone is already in your Emma audience, they are added to the group and any name WIZE has is filled in; WIZE never blanks out a value Emma already holds. - **Imports run in the background at Emma's end.** WIZE reports Emma's own import result, and tells you when an import is still processing rather than claiming it finished. - **Access model:** on-demand in chat only. - **What your admin sets up:** whoever connects it needs access to Emma's API Key settings. - **Connection details:** host `https://api.e2ma.net`; no redirect URL (there is no OAuth step).