RFP: Blackbaud + Webflow Student Sponsorship Integration

Kevin Ache

Project Name

Konpayon Student Sponsorship Availability Sync
https://konpayon.org/

Organization Background

Konpayon is a nonprofit serving Bayonnais, Haiti through relationship-first programs including education, health, agriculture, and student sponsorship. Student sponsorship allows donors to support individual children so they can attend school and receive related support.

Konpayon’s website is built in Webflow. Available students are currently displayed through the Webflow CMS. Konpayon also uses Blackbaud for donor records, financial records, sponsorship-related data, and gift processing.

Core Principle

We want the integration to follow this principle:

Blackbaud decides whether a child is available. Webflow simply reflects that decision.

Blackbaud should be treated as the system of record for sponsorship status. Webflow should act as the public-facing catalog of currently available students.

Project Goal

We need help designing and implementing a reliable integration between Blackbaud and Webflow so that student sponsorship availability is accurately reflected on the website.

At minimum, when a child becomes sponsored in Blackbaud, the corresponding child should be removed from the public sponsorship listing in Webflow or marked unavailable.

Ideally, the system should also reduce or prevent the risk of two donors sponsoring the same child at nearly the same time.

Current Situation

Konpayon has a Webflow page that lists students available for sponsorship:

https://www.konpayon.org/programs/student-sponsorship

Each student appears to be represented as a Webflow CMS item.

Konpayon also has student/sponsorship/donor information in Blackbaud. The current sponsor form allows users to make either one-time donations or recurring sponsorship gifts.

We are not yet fully clear on:

• Which exact Blackbaud product/form setup is being used.
• Where the selected child/student ID is stored.
• Whether a recurring sponsorship immediately creates a reliable event in Blackbaud.
• Whether Blackbaud can trigger a webhook when a child is sponsored.
• Whether the current form can be bound to a specific child ID.
• Whether child availability can be checked before payment submission.
• Whether sponsorship reactivation should be automated or manual.

Primary Problem to Solve

If a child is sponsored, that child should no longer appear as available for sponsorship on the Webflow site.

We also recently had a scenario where two people selected the same child close together. We need to understand whether the integration can prevent this or whether a custom reservation/locking step is required.

Desired Architecture

We are open to recommendations, but our expected architecture is:

Blackbaud

Source of truth for:

• Child/student ID
• Sponsorship status
• Donor/sponsor relationship
• Recurring gift status
• Whether a child is available for public sponsorship

Webflow

Public display layer for:

• Student listing page
• Student CMS item
• Student profile information
• Sponsor CTA/form handoff

Middleware / Integration Layer

Responsible for:

• Matching Blackbaud child IDs to Webflow CMS items
• Listening for Blackbaud events or polling Blackbaud records
• Updating Webflow CMS availability/status
• Logging errors
• Preventing duplicate sponsorships if feasible
• Alerting staff when manual review is needed

Possible tools may include serverless functions, Pipedream, Make, n8n, Supabase, Airtable, or a custom Node/Python integration. We are open to the developer’s recommendation.

Phase 1: Discovery + Proof of Concept

We want the first engagement to be a focused discovery and proof-of-concept, not a full production build.

Discovery Questions to Answer

The freelancer should determine:

1. Which Blackbaud product/form setup Konpayon is using.
2. How students/children are represented in Blackbaud.
3. Whether each child has a permanent unique ID suitable for syncing.
4. Whether the sponsorship form can pass or store a selected child ID.
5. Whether the current form distinguishes between:
   • one-time donation
   • recurring sponsorship
   • general sponsorship support
   • child-specific sponsorship
6. What Blackbaud event or record change can reliably indicate that a child has become sponsored.
7. Whether that event is immediate or delayed/manual/batch-based.
8. Whether Blackbaud webhooks are available for the relevant event.
9. Whether polling the Blackbaud API is more reliable than webhooks.
10. Whether Webflow CMS items can be matched by a blackbaud_child_id field.
11. Whether Webflow should hide, unpublish, archive, or mark a child unavailable.
12. Whether a pre-payment reservation/lock is needed to prevent duplicate sponsorships.
13. Whether reactivation should be automated or manual.

Proof-of-Concept Requirements

The proof of concept should demonstrate:

1. A shared child ID exists in both Blackbaud and Webflow, or can be created.
2. One test child can be matched between Blackbaud and Webflow.
3. A status change in Blackbaud can trigger or support an update to Webflow.
4. The matching Webflow CMS item can be updated through the Webflow CMS API.
5. The developer can recommend the safest production workflow.

Webflow’s CMS API supports programmatic CMS management, including creating, updating, and publishing CMS items, so the POC should verify the specific CMS fields and publish/unpublish behavior needed for Konpayon’s site.  

Phase 2: Production Build

After the discovery phase, we may hire the same freelancer for implementation.

Potential production features:

Required

• Add/use a permanent blackbaud_child_id field in Webflow CMS.
• Sync sponsored/unavailable status from Blackbaud to Webflow.
• Remove or hide sponsored students from the public listing.
• Log all sync attempts and errors.
• Provide staff-facing documentation.
• Provide a safe manual override process.

Strongly Desired

• Prevent duplicate sponsorship attempts through a reservation/locking flow.
• Add a temporary reserved status when a donor begins sponsorship checkout.
• Release the reservation if the donor abandons checkout.
• Mark the child sponsored only after successful recurring sponsorship creation.
• Notify staff when a duplicate, failed, or ambiguous sponsorship occurs.

Optional / Future Phase

• Automatically create Webflow CMS items from Blackbaud student records.
• Automatically update Webflow CMS fields when Blackbaud student data changes.
• Dashboard for sponsorship sync status.
• Manual “resync” button.
• Staff notifications in email or Slack.
• Automated reactivation when sponsorship ends, if appropriate.

Important Business Rules to Clarify

The freelancer should help us document these rules before building:

1. Does a one-time $40 donation make a child sponsored?
2. Or should only an active recurring $40/month gift make a child sponsored?
3. What happens if a recurring payment fails once?
4. What happens if a recurring gift is cancelled?
5. Should reactivation be manual?
6. Who on Konpayon’s team approves a child becoming publicly available again?
7. Should incomplete student records sync to Webflow as drafts instead of publishing automatically?

Our likely preference is:

• One-time gifts should not automatically remove a child from sponsorship availability.
• Active recurring sponsorships should mark a child sponsored.
• Failed/cancelled recurring gifts should require staff review before reactivation.
• New children should not auto-publish publicly without staff review.

Required Skills

The ideal freelancer should have experience with:

• Blackbaud SKY API and/or Raiser’s Edge NXT integrations
• Webflow CMS API
• Webhooks and REST APIs
• OAuth/API authentication
• Serverless functions or lightweight backend development
• JavaScript/Node.js or Python
• Middleware tools such as Pipedream, Make, n8n, Zapier, or custom backend workflows
• Data mapping and sync logic
• Error logging
• Race-condition prevention or reservation systems
• Nonprofit CRM/donation workflows

A pure Webflow designer is probably not enough for this project. We need someone who understands APIs, donor systems, and transaction logic.

Deliverables for Discovery Phase

Please include the following in your proposal:

1. Recommended discovery process.
2. Estimated hours and cost for discovery/POC.
3. Blackbaud access or permissions needed.
4. Webflow access or permissions needed.
5. Questions you would ask Konpayon before beginning.
6. Relevant experience with Blackbaud, Webflow, or nonprofit CRM integrations.
7. Recommended integration architecture.
8. Risks or assumptions you already see.
9. Whether you can also build the production version if discovery is successful.

Final discovery deliverables should include:

• Written technical findings
• Recommended architecture
• Field mapping proposal
• Sponsorship status rules proposal
• POC demonstration
• Production implementation estimate
• Known risks/limitations
• Maintenance recommendations

Deliverables for Production Phase

If selected for production implementation, expected deliverables may include:

• Working integration between Blackbaud and Webflow
• Child ID mapping between systems
• Webflow CMS update/publish/unpublish logic
• Sponsorship status sync
• Optional reservation/locking flow
• Error logging and notifications
• Documentation for Konpayon staff
• Handoff call/training
• 30-day bug-fix window after launch

Security and Access Expectations

The freelancer should follow secure practices:

• No shared personal logins where avoidable
• Use least-privilege access
• Use environment variables for API keys/secrets
• Do not expose API keys in Webflow front-end code
• Document where credentials live
• Provide clean handoff
• Avoid storing donor/payment data unless absolutely necessary
• Avoid duplicating sensitive child or donor data outside the systems unless required

Proposal Evaluation Criteria

We will evaluate candidates based on:

1. Blackbaud/SKY API experience
2. Webflow CMS API experience
3. Ability to explain the integration clearly
4. Understanding of sponsorship availability and duplicate-submission risk
5. Practical approach to discovery before build
6. Security practices
7. Nonprofit/donor-system experience
8. Maintenance plan
9. Cost and timeline
10. Communication style

Initial Budget

Please provide pricing for:

1. Discovery + proof-of-concept only
2. Estimated production build
3. Ongoing monthly maintenance/support

We expect the discovery/POC to be a smaller first engagement before approving the full implementation.

Email Kevin Ache at kevinache@me.com with questions and responses.