Summer camp is often the second-biggest revenue line at a museum, zoo, or nature center, and it almost always runs in a separate registration platform such as CampSite. Camp software handles things Altru was never built for: session waitlists, medical forms, pickup authorizations, cabin or group assignments. The trouble starts in the fall, when development asks which camp families are members, finance asks where the camp revenue landed, and nobody can answer without a spreadsheet marathon.
So the question becomes: can someone just connect the two with an API? Sometimes. But before you hire a developer, it helps to know what Altru exposes, what the camp system exposes, and what you actually need to move.
Start with what has to move, not with the API
“Integration” means very different projects depending on the direction and the data. Write down answers to these before you talk to anyone technical:
- Altru to camp system. Do you need the camp platform to know who is a current member, so it can apply member pricing or early registration? That is a small, read-only flow of names, emails, and membership expiration dates.
- Camp system to Altru. Do you want camp families created or updated as constituents, so they show up in appeals and membership renewal lists? That means writing records into Altru and deciding how to match them against people already there.
- Revenue. Does each camp payment need to appear in Altru as an individual transaction, or is a daily or weekly summary posted to the right account enough for finance?
- Frequency. Real time, nightly, or once a week during registration season? Nightly covers most real needs and is much cheaper to build and maintain.
Most organizations find that two flows matter: member status going out to the camp system, and parent contact information coming back in. Revenue is often better handled as a summary entry, with camp software staying the detailed record for each registration.
What Altru offers for outside connections
Altru runs on Blackbaud’s Infinity platform, which has web services that developers have used for custom integrations. Altru is not a typical modern REST API with a public developer portal and self-serve keys, though, and what you’re allowed to call, and how you authenticate, depends on your hosting arrangement and what Blackbaud supports for your account. Some Blackbaud products are on the SKY API; check whether Altru endpoints are available to you rather than assuming they are.
Before you scope a custom build, ask Blackbaud support directly:
- Is API or web service access available for our hosted Altru database, and what does it cost?
- Which operations are supported: reading query results, creating constituents, adding revenue?
- Is there a sandbox or test environment we can point a developer at?
- Are there usage limits or terms that restrict third-party developers?
Then ask the camp vendor the same questions from their side. Many camp platforms offer reporting exports, webhooks, or an API, but access and depth vary by plan. If neither side gives you clean read and write access, a direct system-to-system connector isn’t an option, however good the developer.
Three realistic approaches
1. Scheduled exports and imports
This is the least glamorous option, and it works. Export registrations from the camp system on a schedule, clean the file, and bring it into Altru with its import tools. Going the other way, run an Altru query of active members and upload it to the camp platform if it accepts member lists. The cost is staff time and the risk of someone forgetting, but nothing breaks when either vendor ships an update.
2. A one-way automated feed out of Altru
Often the most valuable piece is simply getting current member data out of Altru on a schedule without manual exports. A query that refreshes into a shared spreadsheet or a marketing tool can feed the camp team’s pricing checks, or a lightweight script your developer maintains. This avoids writing into Altru at all, which is where custom integrations get risky.
3. A custom two-way integration
If both vendors confirm API access and the volume justifies it, a developer can build a middleware service that reads from one system and writes to the other. Budget for more than the initial build:
- Matching rules. Camp registrations are usually entered by parents, with nicknames, work emails, and typos. Decide how a camp parent matches an existing constituent (email plus last name, for example) and what happens on a near-miss. Without this, every summer adds a layer of duplicate records.
- Households. Decide whether the camper, the parent, or both become constituents, and how they relate to an existing membership household.
- Revenue mapping. Agree with finance on accounts, designations, and how refunds and transfers between sessions are handled before anything posts automatically.
- Ownership. Someone has to monitor failed syncs and update the code when either vendor changes something. Ask any freelancer how they handle maintenance after launch.
Questions to put in front of a developer
- Have you worked with Blackbaud Infinity web services or Altru specifically?
- Will you test against a sandbox before touching production data?
- How does the integration log errors, and who gets notified?
- Where is the middleware hosted, and how are credentials stored?
- What does ongoing support cost per year?
A developer who can’t answer the first question confidently will spend part of your budget learning the platform.
Keeping the data clean either way
Whatever route you pick, plan a duplicate review after each registration season. Camp families who are also members, donors, or past group visitors are exactly the people who end up with two or three constituent records. Catching that in September is far easier than untangling it during year-end appeals.
Where Social Good can help
We don’t connect directly to camp registration platforms, but Data Bridge syncs Altru query results to Google Sheets, Mailchimp, ActiveCampaign, and other tools on a schedule. For many organizations, a live member list in a shared sheet covers the “is this family a member?” check without a custom build, and leaves the developer budget for the parts that truly need it.
