Your product already owns the customer truth
If enrolment, conversion, or reward logic already lives in your own backend, the cleanest approach is to integrate directly with that source of truth.
Build referral operations into your own stack without giving up control.
When your customer data, business rules, or conversion logic live in custom systems, the API and webhooks give you the control to wire Referral Factory into that reality. Use it when direct no-code integrations are too narrow for the workflow you need.
Best when qualification lives in your own backend, product events, or custom operational logic.
Flexible integration path
API
Developer-controlled
Create users, generate links, issue rewards, and manage referral data from your own product or backend when the workflow needs full control.
Webhooks
Event transport
Send new referrals out, receive qualifying events back, and keep the referral engine stitched into the rest of your stack.
Referral operations fit
Connect the channel only when referrals are worth tracking.
Integrations matter because referral-ready businesses need attribution, qualification, reward approvals, and revenue reporting tied to systems the team already trusts.
Use existing CRM or payment data
Qualify referrals on real milestones
Protect reward economics
Report on measurable acquisition
Check referral readinessWhy this matters
Why teams choose API and webhooks instead of a fixed integration
The developer path is not about making things harder. It is about fitting Referral Factory into systems, rules, and product logic that are already unique to your business.
Qualification can follow custom business events
Use the event that actually matters in your system, whether that is a funded account, approved workflow, completed action, or internal state change.
You keep control of the orchestration
Engineering teams can decide how events move, how data is shaped, and how tightly referral logic fits the rest of the platform.
Use the API when your system needs to create or update referral participants directly.
Use webhooks when referral events should feed your own services or trigger downstream automation.
Bring the qualifying event back only when the business rule is truly satisfied.
What you can orchestrate
What your team can orchestrate with the developer path
The useful pattern is to let your own systems stay in control of customer truth while Referral Factory handles the referral mechanics and reward state.
Create users and generate referral links programmatically
Your backend can enrol users in real time instead of waiting for a manual sync or a UI-driven workflow.
Send referral events out to internal systems
Use webhooks to push new referrals into your own processing layer, data warehouse, CRM, or queue-based architecture.
Qualify and reward from custom events
Once your system knows a referral met the business rule, push that event back so the referral workflow can progress cleanly.
Event flow
How the developer workflow should be structured
Keep the boundary clean: your system owns the product logic, Referral Factory owns the referral state, and events move explicitly between them.
Step 1
Create or sync participants from your backend
Enrol users at the moment that makes sense inside your product instead of forcing a separate manual action.
Step 2
Receive and route referral events
Use webhooks when new referrals need to enter your internal processing flow immediately.
Step 3
Wait for the real internal conversion signal
Qualify only when your own product or business logic says the referral truly reached the required outcome.
Step 4
Push qualification and reward actions back intentionally
That keeps your architecture explicit and avoids brittle assumptions about state.
Best fit
Who should choose the API and webhook path
This path makes sense when the business needs more control than a direct integration or no-code tool can realistically provide.
Product teams with custom backend logic
Use this when the important milestones live inside your own application or database rather than in a third-party tool.
Technical operations teams
Use this when the workflow spans several systems and the team wants explicit event handling instead of an opaque point integration.
Businesses with unique qualification rules
Good fit when referral success depends on custom underwriting, verification, approval, or product behaviour the off-the-shelf integrations cannot express cleanly.
Launch checklist
What needs to be true before you switch this on
The fastest launches happen when the milestone is clear, the owner is known, and the data already lives where your team works.
Clean records in the source system
Make sure Webhooks and API already contains the customer or conversion data you want to use for referral operations.
A simple enrolment path
Decide whether you want to generate links from existing records, sign people up through a form, or support both motions.
One qualifying milestone: the custom event or backend state your product team already treats as truth
Pick a milestone the business already trusts so rewards are tied to real commercial progress instead of guesswork.
Automation ownership
Assign one product, engineering, or technical operations owner to own mappings, qualification rules, and what should happen after a referral converts.
Review and exception handling
Decide which scenarios can run automatically and which ones should pause for review before a reward is issued.
A reporting loop
Track enrolments, referred leads, qualification rate, and issued rewards so the team can improve the workflow instead of babysitting it.
Next step
Wire Referral Factory into the system you already trust
If your business logic already lives in your own stack, the API and webhooks let you keep that architecture intact while still running a real referral engine.
Keep your own source of truth
Do not flatten custom business logic into a workflow that cannot express it properly.
Move events explicitly
Use the systems and queues you already trust instead of adding hidden handoffs.
Qualify from real business state
Reward only when the internal event that matters has actually happened.
FAQ
Questions technical teams usually ask first
The API path gives you flexibility, but the implementation still needs clear ownership and clean event boundaries.
When should we choose the API path instead of a direct integration?+
Choose the API or webhook path when your qualification logic, customer records, or orchestration needs already live in your own systems and a direct integration would force the wrong architecture.
What can we do through the API?+
You can create and manage participants, generate referral links, work with referral data, and drive parts of the referral lifecycle programmatically from your own backend.
What are webhooks useful for?+
Webhooks are useful when referral events need to trigger activity in your own systems immediately, or when your own systems need to send a clean qualifying event back once the business milestone is complete.
Who should own the implementation?+
Give ownership to the team that understands both the business rule and the architecture boundary. In most cases that means product engineering or technical operations, not a marketing-only owner.