Name
Type
Required
Description
Format
amount
number
Required
Words
campaign_id
number
Required
Words
created_at
string
Words
Words
first_name
string
Words
id
string
Words
Words
last_name
string
Words
user_id
number
Words
The following JSON Donation object is suitable for copying.
Name
Type
Required
Description
Format
ambassadors
array of ambassador objects
optional
See ambassador object below.
author
author object
optional
See the author object below.
createdAt
string
The date this campaign record was created.
.YYYY-MM-DD Year-Month-Day
details
string
The detailed description of the organisation and campaign.
end_date
string
The date the campaign ends.
.YYYY-MM-DD Year-Month-Day
goal
number
The monetary goal for the campaign,
id
number
Required
A unique ID for this campaign auto-generated by 360Alumni.
image
string
A URL to an image representing the campaign or organization.
URL
islnactive
number
The status of whether the campaign is active. 1: is active 0: is inactive
raised
number
The monetary amount raised by the campaign.
start_date
string
The date the campaign starts.
.YYYY-MM-DD Year-Month-Day
thank_you_message
string
A thank-you message that can be sent to donors.
title
string
Required
The title for the campaign.
type
string
The type of the campaign length such as short or ongoing.
updatedAt
string
The date this campaign record was modified.
.YYYY-MM-DD Year-Month-Day
Name
Type
Required
Format
user_id
number
Required
The user ID identifying an ambassador for the campaign generated by 360Alumni. See also the User Object.
first_name
string
Required
The ambassador's first name.
last_name
string
Required
The ambassador's last name.
JSON Field
(* = Required)
JSON Type (size)
Valid Values
Description
Format
Type
Format
Description
Date
YYYY-MM-DD
Year-Month-Day. Example: 2018-03-21
Learn
Learn how to use the API
API
Try the API
You'll need to create a plan for how to keep your data models synchronized. Data must be pulled from 360Alumni's API rather than pushed via an event-driven integration model. So your integration needs to periodically scan the data and provide a change log to act upon.
Once you have decided upon your synchronization model, you need to identify which fields you are going to keep synchronized between the two systems. Use the User Object reference page to help with your mapping. You can also download a copy of the following spreadsheet to use for your mapping:
Another consideration is the middleware that provides the "bridge" between 360Alumni and your database. Middleware provides enforcement of business logic such as conversion of the data format or structures. Another example of middleware tasks is adding a layer of protection so bad data or glitches can not create chaos in the destination system. An example of middleware is Zapier, which is a middleware "clearinghouse" - offering prepackaged middleware "scripts" for thousands of software applications. 360Alumni has a privately available "Zap" which can be used by our clients who run Salesforce.
One method of integrating your application with 360Alumni is via a polling and synchronization method. This involves checking the database periodically for changes and then updating records accordingly. A polling and sync integration works by running a script that checks for updates and then will update a target based on changes. You can make these integrations two-way by simply applying the business logic you create to both checks.
The following integration example uses a CRM to show how a sync integration can work. Awesome University has a CRM that they use to keep track of their alumni and ensure they can keep track of their donations. They have recently become a partner with 360Alumni and would like to ensure that their alumni database in their CRM and 360Alumni remains in sync. In order to accomplish this they will be setting up a sync with 360Alumni using the "Users" endpoint of the API.
For Awesome University's integration they have determined they want to perform a two way sync with 360Alumni and the contacts in their CRM system. They determined this by finding out the business requirements by talking with stakeholders in their organization. This involved a short series of meetings where they discussed what data they wanted to keep in sync with 360Alumni. They decided upon a two way sync because it would allow them to maintain their alumni directory both organically and still be able to manage it through their CRM.
Awesome University had to decide what parts of their contact data they wanted to keep in sync, so they referred to 360Alumni's field list and settled upon the first name, last name, email, and phone number fields only. They did this because they had only maintained these pieces of contact information in their CRM so they wanted to get them updated as users provided updates. They could have included additional fields but chose a lean approach for phase 1 of their integration.
Awesome University maintains a couple of in house servers so they decided their script will be written in node.js and run once a day at 1 AM on one of their linux environments. Their script will simply look at records that were changed in each system and then update or create records on each of the respective environments. This also allows Awesome University to put in any transformations they need.