Building a Custom Member Portal on Top of Wild Apricot

The New Zealand Society of Association Executives is the peak body for people who run associations. Their member portal was Wild Apricot's out-of-the-box template — plain forms, link lists, someone else's design language. For an organisation whose whole purpose is helping associations present themselves well, that's an awkward place to be.

We rebuilt the member experience on Drupal 11 and kept Wild Apricot underneath as the membership system of record. The case study covers the outcome. This post covers the parts the case study glosses over — what we planned, where the API pushed back, and what we'd tell anyone attempting the same build.

The Problem

Wild Apricot does the administrative side of an association well. Memberships, renewals, payments, contact records — it's reliable, and NZSAE had no reason to move off it. We didn't suggest they should.

The member-facing side is a different story. The logged-in area is a fixed template. You can change colours and fonts, but the layout, content structure and workflows are whatever Wild Apricot decided they should be. The public website and the member portal were effectively two products, and members crossed a visible seam every time they signed in.

Most organisations in this position see two options: put up with the template, or replace the whole platform. Both are wrong. The membership administration and the member experience are separate problems, and Wild Apricot is only good at one of them. Keep it for what it does well, build the experience on something you own.

Planning

Two decisions in planning did more for the project than anything in the build.

The first was scoping the portal from member workflows rather than from the template we were replacing. The easy version of this project is Wild Apricot's portal with NZSAE branding — same forms, same link lists, new colours. Instead we started from what members actually do: register for events, manage renewals and invoices, find suppliers, use member-only resources. That produced a genuinely different portal. Members land on a dashboard showing their membership status, upcoming events and their own registrations, with navigation across Profile, Events, Invoices and Resources.

The second was mapping every member flow to a home before writing any code. In a hybrid setup some things live in Drupal and some still happen in Wild Apricot, and if you don't decide which is which up front, your members will discover the boundary for you. Viewing membership details, invoices, events, resources: Drupal, reading from the API. Payments and membership administration: Wild Apricot. On paper this looks obvious. In practice every flow tempts you with "surely we can pull this into the portal too", and each one needs an honest answer about what the API supports.

The API

The Wild Apricot API works, but it was built as an add-on to a SaaS product, not as a foundation for external experiences. Two constraints shaped the integration.

Queries return 100 records maximum, so anything touching full member lists or event histories needs pagination handling from day one. And endpoints are rate-limited — the contact-by-identifier endpoint allows 120 requests per minute, for example. Neither killed anything, but both are the kind of detail that turns a two-week integration estimate into four weeks if you find out mid-build instead of during planning.

The rate limits force a real decision about data freshness. A portal showing stale membership status is worse than no portal — a member who just renewed and still sees "expired" won't trust anything else on the page. But you can't hit the API on every page load either. We treated freshness per data type: membership status, renewals and invoices are read from Wild Apricot so the dashboard always reflects the real state of an account, while slower-moving data tolerates more caching. Boring answer, but it's the right one.

Role mapping was the third piece. Wild Apricot knows about membership levels and statuses — organisational, individual, lapsed, pending. Drupal knows about roles and permissions. The integration maps one to the other so access follows automatically from real membership state. The fiddly parts are organisational memberships, where access belongs to an organisation but gets exercised by individual people, and lapses, where access should degrade sensibly rather than vanish mid-session. Once the mapping is right there's no manual access administration at all. Wild Apricot stays the single source of truth for who's a member; Drupal enforces what that means.

What the API Won't Do

The biggest gap we hit was password resets.

Members authenticate against their Wild Apricot accounts, so passwords live in Wild Apricot, so resets have to happen there. And the API gives you no way to trigger one. Same with most of Wild Apricot's internal transactional emails — the platform sends them on its own schedule and you can't fire them from outside. This isn't an obscure edge case either; there's a developer forum request for exactly this that's been sitting open for years.

We looked at rebuilding the flow ourselves and decided against it. Working around a membership platform's account security is how you inherit problems you didn't sign up for. So for the handful of flows the API won't support, members get handed off to Wild Apricot's own hosted pages, with the hand-off kept as short and unsurprising as we could make it before they're back in the portal.

I'd rather have zero seams. But a planned hand-off on one narrow flow is fine in practice — what actually annoys members is hitting a boundary nobody designed, halfway through a task. Because we'd mapped every flow up front, the password reset limitation moved one flow to the other side of the line and changed nothing else.

What's Possible Now

New member features are now ordinary Drupal work rather than feature requests into a vendor's backlog. CPD tracking is the clearest example — for association executives, continuing professional development is core to the job, and it's next on the list now that the platform can support it properly. Community features, deeper personalisation and a growing supplier directory sit in the same category: buildable when NZSAE wants them, none of it waiting on Wild Apricot's roadmap.

The AI side is the more interesting one to me. NZSAE's resources and events now live in an open platform with real APIs, which means they're available to build on. The obvious candidate is semantic search over the member resource library — members asking questions in plain language instead of keyword-matching through document titles. None of this was feasible with content locked inside a proprietary portal. To be fair, these are things the architecture supports, not things NZSAE has committed to. But being able to say yes to them later is most of the point of owning the platform.

If You're Attempting This

Audit the API before you estimate. The pagination limits, the rate limits, and the flows it won't support should shape the plan — finding them mid-build is the expensive version.

Scope from what your members do, not from the template you're replacing. And map every flow to a side of the boundary before you start, because some flows will stay on the SaaS side no matter what you build, and the difference between a fine hand-off and an annoying one is whether anyone designed it.

Wild Apricot kept the job it's good at, and NZSAE now owns everything its members see. We'd use the same split again.