Fellowship One - Developer Community RSS Feed

3rd Party App Showcase

2013-03-22T15:22:47+00:00

Check out our new gallery of 3rd party vendor applications that integrate with Fellowship One using our API! To enable an application, you can login to Fellowship One and select Admin and Applications. Our new app showcase features screenshots of the apps along with additional details of what the app does and how to contact the vendor. If you are a vendor looking to integrate with Fellowship One, please use the gallery to view the types of apps we currently offer to determine how you can best integrate and extend the functionality of Fellowship One. The process starts by applying for an API key. You will receive a sandbox environment in which to build and test your code. Once development is complete, you would then need to submit your code to our API Code Review team and upon approval, the app will be transitioned over to our live production environment where customers can begin using it. If you have questions, check out our developer forum and our comprehensive documentation Click here to Apply for an API Key.

API Communication Value Changes

2012-11-02T17:47:47+00:00

As many of you know, earlier this year we began to streamline the types of communication values available in Fellowship One. More information about the project can be found on our community blog here, and also on the developer blog here. As a result of this project, we enhanced functionality around communication values via our API, and last week we pushed the enhancements to production. You, our developer community, responded very well to the changes. You rock! Here is a review of the changes and enhancements: Reduction in Communication Types.GET https:// demo.fellowshiponeapi.com/v1/communications/communicationtypes Response: { "communicationTypes":{ "communicationType":[ { "@array":"true", "@id":"1", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/1", "@generalType":"Telephone", "name":"Home Phone" }, { "@array":"true", "@id":"2", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/2", "@generalType":"Telephone", "name":"Work Phone" }, { "@array":"true", "@id":"3", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/3", "@generalType":"Telephone", "name":"Mobile Phone" }, { "@array":"true", "@id":"138", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/138", "@generalType":"Telephone", "name":"Emergency Phone" }, { "@array":"true", "@id":"5", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/5", "@generalType":"Email", "name":"Home Email" }, { "@array":"true", "@id":"4", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/4", "@generalType":"Email", "name":"Email" }, { "@array":"true", "@id":"6", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/6", "@generalType":"Email", "name":"InFellowship Login" }, { "@array":"true", "@id":"102", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/102", "@generalType":"Web", "name":"Web Address" }, { "@array":"true", "@id":"201", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/201", "@generalType":"SocialMedia", "name":"Facebook" }, { "@array":"true", "@id":"203", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/203", "@generalType":"SocialMedia", "name":"Twitter" }, { "@array":"true", "@id":"202", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/202", "@generalType":"SocialMedia", "name":"Linkedin" } ] } } The list of available communication types has been reduced. It is important to note that the labels for the communication values in portal will change depending on how many communication values exist in a record. Example: Because this individual has an inFellowship ID, the individual email address is listed as ‘Alternate’. If no inFellowship ID existed, that same value would be labeled ‘Personal’. Via the API, the individual email address is always Type 4 - Email, no matter what the label says in portal. A household email address is always Type 5 - Home Email. An inFellowship Communication Value is always Type 6. The Listed Node has been Removed and Replaced with PreferredGET https://demo.fellowshiponeapi.com/v1/People/17173182/communications/new Response {"communication":{ "@id":"", "@uri":"", "household":{ "@id":"11695333", "@uri":"https://demo.fellowshiponeapi.com/v1/Households/11695333"}, "person":{ "@id":"17173182", "@uri":"https://demo.fellowshiponeapi.com/v1/People/17173182"}, "communicationType":{"@id":"", "@uri":"", "name":null}, "communicationGeneralType":null, "communicationValue":null, "searchCommunicationValue":null, "preferred":null, "communicationComment":null, "createdDate":null, "lastUpdatedDate":null}} Remember, it is ALWAYS a good idea to call ‘New’ before ‘Create’. That way, you will always receive the correct model for the resource from the server: ‘Unsubscribed’ Node in v2 of a person Resource Instead of versioning the entire people realm for a minor change like this, the unsubscribed value can be obtained by passing a custom content-type header. This allows enhanced functionality without breaking current compatibility. Given GET https://demo.fellowshiponeapi.com/v1/People/17173182 Content-Type: application/vnd.fellowshiponeapi.com.people.people.v2+json Returns: ... "firstRecord":"2007-11-05T23:12:24", "lastMatchDate":"2012-10-25T11:48:01", "unsubscribed":"false", "createdDate":"2007-11-05T23:12:24", "lastUpdatedDate":"2012-10-25T11:48:01" This node will not exist if the custom content-type is not passed. That’s all! Again, we thank you for being such an awesome developer community and look forward to hearing about the new and exciting ways you are consuming our API to maximize ministry and minimize administration. Nom. Nom. Nom!

API Enhancement: Create and Edit Groups!

2012-08-13T19:33:50+00:00

We have released another API enhancement to production! It is now possible to create and edit Groups via the API. Check out this video that demonstrates how to consume these new API methods using the Google Chrome HTTP Dev Client:

API Enhancement: Requirements Exposed

2012-06-25T16:09:02+00:00

We are excited to announce our latest API enhancement - Individual Requirements! Individual Requirements are typically used for two reasons: to track items that need to be completed before a person can volunteer for a job and to track different stages of membership. Requirements can be specific and fully customized. This API feature enhancement expands the capacity of our API to both churches and vendors alike. Both will now be able to create, read, update and delete Individual Requirements via the API, which opens up the potential for new vendors to partner with Fellowship One in delivering automated background check solutions. Active Network | Faith already partners with a few well-known background check companies and the integration is written directly into Fellowship One. By exposing individual requirements via our publically facing API, the opportunity for any vendor to integrate with Fellowship One is now a reality. With this release we are introducing a new feature, which allows a user to show, create, or update a document in the context of an individual requirement. This document can contain report data from an outside source. The content-types allowed to be passed for this method are: application/pdf application/msword application/help image/jpeg image/png image/tiff image/gif text/plain text/richtext text/html A binary stream will be sent or received for the above formats. In short, you will be able to insert documents into Fellowship One via the API for any custom use you may have. Hello paperless church world! These enhancements are currently live in staging and the documentation can be accessed via application/help. We welcome your feedback and would love to hear the exiting ways in which you plan to use this aspect of our growing API. Thank you for being a part of the Fellowship One Developer Community!

Webhooks

2012-05-23T14:01:45+00:00

The video above is a tutorial to show how it is possible to use a web service such as Formstack to collect data on your church website and have the data go directly into Fellowship One via a webhook. The concepts carry true for other web services that feature webhooks, such as Wufoo - another online form builder solution - or Mail Chimp, which offers email marketing and email list management. Utilizing webhooks along with the Fellowship One API allows you to keep Fellowship One as the authoritative database of record by intelligently pushing in data - in real time - from other web services. Watch the video and let us know in the comments section if this is something your church could use! If you don’t have an API key yet, sign up for one here and specify that you want to create a webhook.

Resource Versioning

2012-04-24T20:03:56+00:00

Enhanced Functionality without breaking CompatibilityWe’re excited to announce a few changes coming to the API! If you have been following along with the Community Blog, you will be aware of the initiative to streamline communication values. If not take a look at the posts here and here. It follows that these changes will be reflected through the API also. As part of this effort, the "listed" functionality around each communication resource will soon be discontinued as well as the node being removed. Instead, we will be adding a new node to the people resource called "unsubscribed". Currently, the "listed" node is returned with each communication resource as follows: [GET] https://demo.fellowshiponeapi.com/v1/Households/1552366/Communications.json Response: ... "communicationType":{ "@id":"1", "@uri":"https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes/1", "name":"Home Phone" }, "communicationGeneralType":"Telephone", "communicationValue":"214-759-2756", "searchCommunicationValue":"2147592756", "listed":"true", "communicationComment":null, "createdDate":"2005-01-20T01:04:55", "lastUpdatedDate":"2005-01-20T01:04:55" ... In 30-45 days, this node will be removed. If you are using the API to retrieve or create communication resources, you will want to make sure you are using the correct data model. It is always a good idea to call NEW before CREATE. See the Ten Commandments of API Consumption here. The new "unsubscribed" node will be added on the people resource level for the xml or json being returned or received and this resource will be versioned. HATEOAS HATEOAS, is the abbreviation for Hypermedia as the Engine of Application State and it is a constraint of the REST architecture. It serves to decouple the client and server in a way that allows the server to evolve functionality without breaking compatibility. In consistency with this constraint, we are creating a new content-type so that existing users will not be impacted by this functionality enhancement. To use version two of the people resource with the new “unsubscribed” node, you will need to pass in a custom content-type: Content-Type: application/vnd.fellowshiponeapi.com.people.people.v2+xml or Content-Type: application/vnd.fellowshiponeapi.com.people.people.v2+json Example Given: [GET] http://demo.fellowshiponeapi.com/v1/Households/1999107/People Content-Type: application/vnd.fellowshiponeapi.com.people.people.v2+json Response: "people": { "person": [ { "@array": "true", "@id": "8711560", "@uri": "http://demo.fellowshiponeapi.com/v1/People/8711560", ... "firstRecord": "2006-02-03T11:27:40", "lastMatchDate": null, "unsubscribed:" false, "createdDate": "2006-02-03T11:27:40", ... Versioning of this resource is currently live in production - give it a try! Reduction of Communication Types Given: [GET] https://demo.fellowshiponeapi.com/v1/Communications/CommunicationTypes Returns a list of communication types. Following the completion of the reduction of communication types project, the following communication types will no longer be returned by the API: For a Household: Alternate Phone; Alternate Email; Children Phone; CR Safe Phone; Emergency Phone; Fax; Mobile; Pager; Previous Phone; School Phone; School Email;Vacation Phone; Work Phone; Work Email. For an Individual: Alternate Phone; Alternate Email; Children Phone; CR Safe Phone; Fax; Pager; Previous Phone; School; Phone; School Email; Vacation Phone; Work Email. Attempting to request any of these specific CommunicationType resources in the current version will return an HTTP 404 - Not Found. Please let us know if you have any questions and as always, thank you for being part of the Fellowship One Developer Community!

Enter Visitor Data via Your Church Website

2012-03-16T14:49:39+00:00

Possibilities For Ministry Use Capture contact information dynamically during a worship service instead of using visitor cards Allow volunteers to enter simple data into Fellowship One through your church website Setup a kiosk where visitors can enter their own contact information The Code The following is the PHP code used to process the form entries and write the data into Fellowship One through the API. This example uses the PHP Helper Class, ‘FellowshipOne.php’ contributed by a member of our developer community, Daniel Boorn. A few methods were added to the helper class and you will find a link to all the source code below this code example. Please feel free to use and adapt this as necessary. If you don’t already have an API key, you can apply for one here: https://developer.fellowshipone.com/index.php/key <?php require('FellowshipOne.php'); $settings = array( 'key'=>'your key here', 'secret'=>'your secret here', 'username'=>'portal username here - must be linked to a person in f1', 'password'=>'password', 'baseUrl'=>'https://yourchurchcode.fellowshiponeapi.com', 'debug'=>true, ); //instantiate the f1 class $f1 = new FellowshipOne($settings); if(($r = $f1->login()) === false){ die("Failed to login"); } //Get F1 Household json model $model = $f1->householdModel; //Update model with form info $model['household']['householdName'] = $_POST['firstName'].' '.$_POST['lastName']; $model['household']['householdSortName'] = $_POST['lastName']; $model['household']['householdFirstName'] = $_POST['firstName']; //Create Household in F1 $results = $f1->createHousehold($model); //Create a person in the household we just created //First determine household position $householdPosition = $_POST['householdPosition']; if($householdPosition == "Head"){ $householdMemberType = "1"; } elseif($householdPosition == "Spouse"){ $householdMemberType = "2"; } else { $householdMemberType = "3"; } $today = new DateTime('now'); //Get the F1 Person json model $model = $f1->personModel; //Update the person model with the form info $model['person']['@householdID'] = $results['household']['@id']; $model['person']['firstName'] = $_POST['firstName']; $model['person']['lastName'] = $_POST['lastName']; $model['person']['gender'] = $_POST['gender']; $model['person']['dateOfBirth'] = date(DATE_ATOM,mktime(0,0,0,$_POST['month'],$_POST['day'],$_POST['year'])); $model['person']['maritalStatus'] = $_POST['maritalStatus']; $model['person']['householdMemberType']['@id'] = $householdMemberType; $model['person']['householdMemberType']['name'] = $householdPosition; $model['person']['status']['@id'] = '110'; // example $model['person']['status']['date'] = $today->format(DATE_ATOM); //Write the person in the household into F1 $r = $f1->createPerson($model); //Store the personID $personID = $r['person']['@id']; //get the communications json model from F1 $model = $f1->getCommunicationModel($personID); //Update the json model with the email address $model['communication']['communicationType']['@id'] = "4"; $model['communication']['communicationType']['name'] = "email"; $model['communication']['communicationValue'] = $_POST['email']; //Write the email communication into F1 $r = $f1->createCommunication($model, $personID); //Update the json model with the telephone info $model['communication']['communicationType']['@id'] = "1"; $model['communication']['communicationType']['name'] = "telephone"; $model['communication']['communicationValue'] = $_POST['primaryPhone']; //Write the telephone value into F1 $r = $f1->createCommunication($model, $personID); //Check if a file was uploaded and move it out of the temp directory then write it to F1 if ($_FILES['image']['name']){ define('UPLOAD_DIR', '/path/to/directory/'); move_uploaded_file($_FILES['image']['tmp_name'], UPLOAD_DIR.$_FILES['image']['name']); $imageStr = file_get_contents(UPLOAD_DIR.$_FILES['image']['name']); $r = $f1->createImage($imageStr, $personID); } ?> All Source Code https://github.com/tracymazelin/F1-Guest-Entry

Fellowship One & Planning Center Online

2012-03-01T16:31:27+00:00

How to Fork, Host, Deploy and Contribute to this open source projectIt is now possible to sync your Fellowship One people demographic data to your Planning Center Online Account via an open source application that utilizes both the Fellowship One API and the Planning Center Online API. This blog post is going to walk you through the process of setting up and hosting this application. What you will need: An account on github (free) An account on a fully hosted .NET platform as a service such as AppHarbor (free) Microsoft SQL Server Management Studio (free) Consumer Key and Secret from F1 (apply here) Consumer Key and Secret from Planning Center (apply here) Step 1: Fork the Repo and make a local clone In order to contribute to another developers project or use their project as a starting point for your own, you will need to fork the repo. This is done by simply clicking fork on this page https://github.com/fellowshiptech/f1-pco: Once you have done this, you will need to clone a copy of the code to your local machine. Instructions for doing this can be found here: http://help.github.com/fork-a-repo/ Step 2: Setup your application in AppHarborSince this is an ASP.NET MVC application, you will need the appropriate server environment in which to deploy the application. AppHarbor is a fully hosted .NET Platform as a Service solution, which allows you to deploy any standard .NET application. They offer a free account with ample resources for a project like this. Sign up here: https://appharbor.com/ Once you have created your account, you will need to create a new application: Step 3: Install the Free SQL Server Add-onInstalling an MS SQL Server is necessary to run this application. AppHarbor offers a free add-on for a shared SQL Server instance. Select the “Yocto” version and click “Install”. Step 4: Use MS SQL Management Studio to connect to DatabaseOnce you have installed the SQL server, AppHarbor will assign a user id and password to access it. This can be found by clicking the Go to “SQL Server” link found on your SQL Server page in AppHarbor. You will need the following information: Connection String (save for step 6) Host Username Password Now you will need to open up SQL Management Studio and enter these credentials here, using the “Host” string as the “Server Name” and entering the Login and Password information: Step 5: Run Database ScriptUpon successful connection to the SQL server, you will need to run the database script provided in the repo: Scripts/DBScript.sql. Select File -> Open -> Locate Script -> Execute. Step 6: Edit web.configOpen up the web.config file and enter the following information: Connection String (from step 4) F1Consumer Key F1Consumer Secret PCO Consumer Key PCO Consumer Secret Step 7: Deploy Application to AppHarborThe last thing you need to do is push the local repository to your AppHarbor Repository URL. Doing so will trigger the build on AppHarbor. You will need to get the AppHarbor Repository URL. Add the remote repository like this: git remote add appharbor MY_REPOSITORY_URL Deploy using: git push appharbor master That’s it! Your integration between the two applications is now complete. By offering this open source code, our hope is that you will contribute back to this project by adding features and functionality. It is important to note that this is currently setup for one-way syncing only. The direction is Fellowship One to PCO. Developing multi-directional syncing capabilities would be a great way to enhance this project! Also, the application has multi-tenant functionality built in. If you use this as a single solution for your church, you may want to remove the multi-tenant functionality (requesting church code etc.) and set it up as a 2nd party application. We hope you find this useful and look forward to hearing about the awesome ways you build upon this framework for enhancing integration between Fellowship One and Planning Center Online!

API Libraries and Sample Code

2012-02-07T15:07:08+00:00

Code libraries make it easier for you to use the Fellowship One API in the language or framework of your choice. We have compiled a list of code libraries along with some sample code to help get you started with your API project. We are thankful to numerous members of our developer community for being willing to contribute their work to help others get their projects off the ground. If you have developed your own library, or you have any code examples you would be willing to share, please . We would love to add your work to the list. Check out the library here: https://developer.fellowshipone.com/libraries Tracy Mazelin is the newest member of the API Developer Team at Fellowship Technologies (part of Active Network). She is passionate about evangelizing the API and giving users the tools they need to take them to the next level of API utilization.

Building a custom login for your church website using the API

2011-11-29T20:04:48+00:00

Background The Application Programming Interface (API) of Fellowship One provides a way for churches to leverage their own church data within custom built applications. This tutorial is going to outline how you can use our API to build a custom login to your church website by authorizing the user based on their WebLink or InFellowship login credentials. This is a 2nd party application and this post builds upon the foundation laid by Jas Singh here. You will find links to the PHP oAuth library and more detail about 2nd party authorization in his post. Step 1: Build a login form First, you will need to build a login form requesting a username and password. If the majority of your church has already converted their WebLink login to an InFellowship login, then you will want to ask for their email address as their username. The authentication is designed to accept either a WebLink or InFellowship username. Here is an example of the code you would need to use to collect the username and password and also print a login failure message if the credentials submitted do not match what is in your Fellowship One database: <form action="authenticate.php" method="post"> <p> <?php if(isset($_GET['login']) && $_GET['login'] == "failed") echo '<span style="color:red">Incorrect Username or Password</span>';?> <label for="username">Username or Email Address:</label> <input name="username" type="text" size="20"/> </p> <p> <label for="password">Password:</label> <input name="password" type="password" size="20" /> <input type="submit" value="Log In" name="submit" /> <input type="hidden" name="redirect" value="<?php echo $_GET['redirect']?>"/> </p> <p> <a href="https://integration.fellowshipone.com/integration/Conversion/Create.aspx? cCode=[YourChurchCode]" target="_blank">Create Account</a> | <a href="https://integration.fellowshipone.com/integration/loginhelp.aspx? cCode=[YourChurchCode]">Forgot Password?<br /> </a> </p></form> Step 2: Process the submission Once the user enters login credentials and clicks submit, a form action is required. This is where your church website will need to talk to Fellowship One to see if this user exists and if the credentials are correct. This will be done through the API. As part of the authentication process for accessing protected resources, the API needs the username and password separated by a space and base64 & URL encoded. Below is an example script in PHP for submitting the username and password to the API and collecting key user information for use in your own church website. See comments in the code for explanations: <?php //Get these files from the PHP oAuth library require_once 'OAuth/AppConfig.php'; require_once 'OAuth/OAuthClient.php'; // Create a session session_start(); $results = array(); //Create an instance of oAuthClient $apiConsumer = new OAuthClient(AppConfig::$base_url, AppConfig::$consumer_key, AppConfig::$consumer_secret); //Post the username and password collected on the login page to the request to get an access token if(isset($_POST["submit"])) { if($apiConsumer->getAccessToken2ndParty($_POST['username'],$_POST['password'])) //Get the token and token secret and store them in cookies { $_SESSION['token'] = $apiConsumer->getToken(); $_SESSION['tokenSecret'] = $apiConsumer->getTokenSecret(); } else { session_destroy(); $_SESSION = array(); //If the tokens are not given, the authentication failed. //The login form reads the redirect url and displays a login failure message header('Location:../login.php?login=failed'); exit(); } //Upon successful authentication, the server will send back a response //We want to get the person location from the response $responseHeaders = $apiConsumer->getResponseHeader(); foreach ($responseHeaders as $val) { $start = 'Content-Location:'; $contentLocation = substr( $val, 0, 17 ); if ($contentLocation == $start) { $personLocation = str_replace($start, "", $val); if( $contentLocation == $start ) { $personLocation = str_replace($start, "", $val); $_SESSION['personurl'] = trim($personLocation); } } } } //if no username or password was entered see if there is already a session else if (isset($_SESSION['token'])) { //Initialize the Access Token. $apiConsumer->initAccessToken($_SESSION['token'],$_SESSION['tokenSecret']); } // if no credentials and no existing session redirect to login page else { header("Location:login.php"); exit(); } $url = $_SESSION['personurl'].".json"; //We want to get some fields from the API and store them in cookies for use within our site $person=$apiConsumer->dorequest($url); $results = json_decode(strstr($person, '{"person":{'), true); $_SESSION['iCode'] = $results['person']['@iCode']; $_SESSION['firstName'] = $results['person']['firstName']; $_SESSION['lastName'] = $results['person']['lastName']; $_SESSION['personID'] = $results['person']['@id']; //Another call to get address information $resource = AppConfig::$f1_people_address; $f1_people_address = str_replace('{personID}', $_SESSION['personID'], $resource); $url = AppConfig::$base_url.$f1_people_address.".json"; $addresses=$apiConsumer->dorequest($url); $addresses=json_decode(strstr($addresses, '{"addresses":{"address":[{')); $_SESSION['address1'] = $addresses->addresses->address[0]->address1; $_SESSION['address2'] = $addresses->addresses->address[0]->address2; $_SESSION['address3'] = $addresses->addresses->address[0]->address3; $_SESSION['city'] = $addresses->addresses->address[0]->city; $_SESSION['stProvince'] = $addresses->addresses->address[0]->stProvince; $_SESSION['postalCode'] = $addresses->addresses->address[0]->postalCode; //Store other commonly used fields here //Take the user to the members area of your website. Put your own path to the members page here header("Location:members.php"); ?> Step 3: Add this code to your OAuthClient.php file public function getAccessToken2ndParty($username, $password) { curl_setopt( $this->connection, CURLOPT_NOBODY, true ); //register a callback function which will process the response headers curl_setopt($this->connection, CURLOPT_HEADERFUNCTION, array(&$this,'readHeader')); $requestURL = sprintf( "%s%s", $this->baseUrl, $this->accesstoken_path ); // SET the username and password $requestBody = Util::urlencode_rfc3986(base64_encode( sprintf( "%s %s", $username, $password))); $getContentType = array("Accept: application/json", "Content-type: application/json"); $requestBody = $this->postRequest($requestURL, $requestBody , $getContentType, 200); preg_match( "~oauth_token\=([^\&]+)\&oauth_token_secret\=([^\&]+)~i", $requestBody, $tokens ); if( !isset( $tokens[1] ) || !isset( $tokens[2] ) ) { return false; } $this->requestToken = $tokens[1] ; $this->tokenSecret = $tokens[2] ; return true; } Step 4: Send the logged-in user to a member area Once authentication is complete and key fields are stored, the script redirects the user to a private area of the church website. You now have key data from the api and can easily make calls to retrieve other resources. Step 5: Build your own integration applications! As you can see, the API provides churches with an extra layer of intelligence behind the church website and eliminates the need to store any data in a separate web based database. Single sign on is just the beginning of the functionality afforded to churches. Using the API, it is possible to replace numerous aspects of WebLink/InFellowship with custom built applications which remain consistent with the look and feel of the church website.