http://developer.fellowshipone.com/index.php/site/index/ Fellowship One RESTful API is a REST based web application that uses several open protocols and patterns to provide consumers access to secure resources. STANDARDS, PROTOCOLS, and PATTERNS - nothing else. As developers we see where there is major value in sticking with something that is "tried and true." If we could use web based patterns and protocols for a web based API we could not only get instant adoption but gain the efficiencies and effectiveness of technologies that "just work." en tracy.mazelin@activenetwork.com Copyright 2011 2011-11-29T20:04:38+00:00 https://developer.fellowshipone.com/index.php/blog/building_a_custom_login_for_your_church_website_using_the_api/ https://developer.fellowshipone.com/index.php/blog/building_a_custom_login_for_your_church_website_using_the_api/#When:20:04:38Z 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 for integrating with web based features of Fellowship One.  Those features include a profile editor, online giving, event registrations and volunteer opportunities. If all event registrations are placed together in an aggregate form within Fellowship One, this method provides a one-stop place for any integration between your church website and Fellowship One: Step 5: Launch WebLink sessions tied to the logged-in user At the time of this writing, WebLink is still the method used for accessing each of the above resources and since the script collected key fields via the API, a unique individual code has been collected - the icode. This icode can be concatenated to each URL to access each resource like this: <a href="https://integration.fellowshipone.com/integration/contribution/onlinecontribution.aspx?flo=true&iCode=<?php echo $_SESSION['iCode'];?>&cCode=[YourChurchCode]" target="_blank"></a> Step 6: 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 with custom built applications which remain consistent with the look and feel of the church website. API, Tips 2011-11-29T20:04:38+00:00 https://developer.fellowshipone.com/index.php/blog/roll_foward/ https://developer.fellowshipone.com/index.php/blog/roll_foward/#When:19:06:06Z If you are in software development or technical operations of any kind, you are probably familiar with the term “Roll Back”. For those of you who are not in either camp mentioned above, allow me to provide a brief definition: Rollback: To return the system, software, or database to some previous state (hopefully the state prior to your deployment). Back in August of 2010, our teams at Fellowship Technologies started on the long road to continuous delivery. Continuous delivery is the notion that you engineer your software to allow for a continuous deployment through all environments, up to and including Production (with little to no manual intervention). It is also the notion that your engineering practices are so solid that each change you make to the system is backed by a series of automated tests written by the development team. This of course provides confidence and empowers them to make changes to those creaky parts of the system that no one “used to” want to touch. In the past, our releases were huge chunks of software that required multiple levels of manual testing which of course took an in-ordinate amount of time and actually distracted us from obtaining the real goal; getting our software from our developer’s machine to Production once it is deemed “done” by the team. Our releases were flat out painful and we knew that we had to change. During our long “mock deployment” meetings, inevitably, we would discuss the infamous roll-back strategy. This strategy exists simply due to the low confidence of your team in their ability to deliver software. That confidence could stem from their own engineering practices to the actual environment or platform that they were deploying to. At any rate, the team owns those challenges and our teams set out on a course to remove the reasons that it so painful to deliver software. We practice Scrum as our framework for software development. Scrum’s job is to show our teams why we can’t obtain our goal mentioned above. Scrum was doing its job well and our team finally decided that it was time to focus on this problem. I think we could all agree as a team that we are no where near where we want to be, but that is what excites me about our teams. They have the drive to get better. While it never happens as quickly as we all would like, we learn each step how to do something better and apply that to the next challenge. Scrum is empirical in nature, meaning that we learn from observation and experience. Today (Aug 9) is our 1 year anniversary to the turning point in our engineering practices. This post is to celebrate all of the team’s accomplishments over the year. I am so grateful to be a part of a team that embraces continuous improvement and at the heart of our decisions has the desire to serve our customers as best we can. The path has been no bed of roses; no pleasure cruise. We have had our challenges, dis-agreements, and flat out failures (learning opportunities). However, I can say that I believe our confidence factor has improved by a factor of 10. Our teams are not afraid of any challenges nor do they shy away from those large “learning opportunities”. We continually improve in our ability to work as a team and learn to navigate the mine field of doing things the right way and doing what is best for our customers. In the end, we have removed the term “roll-back” from our deployment vocabulary and have replaced it with the self-confidence of “roll-forward”. We are confident that our engineering practices will continue to improve, thus helping us catch more of those “gotchas” up-front in our sprint cycles than when we get to Production. Congratulations to our teams, thank you so much for your attitude, aptitude, and drive to be the best development team on the planet. You deserve it, our organization deserves it, but most of all, our customers deserve our best. Roll forward! News 2011-08-09T19:06:06+00:00 https://developer.fellowshipone.com/index.php/blog/the_agile_triangle/ https://developer.fellowshipone.com/index.php/blog/the_agile_triangle/#When:16:02:12Z Jim Highsmith presented to DFW Scrum on July 26, 2011. We are grateful for his time and energy to come by and educate us on the true Agile Triangle and how to balance cost, scope, and schedule (which he ascertains are actually constraints, not foundational pieces of the Iron Triangle). Fellowship Technologies is a proud sponsor of DFW Scrum as they strive to concentrate on various "bands" in Scrum. The process is small and simple, and relatively easy to understand. Doing it... well that is another story altogether. Scrum says "start with a backlog, prioritize it, estimate it, commit to a piece of it in a sprint, deliver potentially shippable product in the end, look back on ways to improve, rinse and repeat". I also add that our job is to make our organization/customers happy along the way with transparency (which is another post for another time). However, those pieces have logistics all their own and their topics try to focus on each of those pieces to guide us in the actual practice. Jim Highsmith focused his presentation on value in the backlog. This means trying to ensure the business can actually quantify the user stories in value points against the development teams' story points (cost). He brought a wide array of knowledge focused primarily on managing the projects (either from a PM or Management/Executive stand point). One of the great points that stood out for me was the fact that Gantt Charts and traditional project management focused on following the plan with minimal changes while trying to juggle Gantt chart tasks and dependencies against the reality of what is taking place. The Agile leader however focuses on adapting successfully to the inevitable changes and focusing on value to the business over the traditional Iron Triangle notions of Scope, Cost, and Schedule. Another highlight of his presentation was The Gap's business value dials (their metrics for measuring their success). These metrics focus as much on quality and software development indices as they do on market value and quantitive measure of how much the feature is bringing to the bottom line. I think businesses need to hold our Product Managers more accountable to the features they are prioritizing by backing those features with quantitative market value points. Jim highlighted that he had come across very few companies who actually do that. Here is a PDF copy of Jim's presentation: Beyond Scope, Schedule, and Cost (The Agile Triangle) Tips 2011-07-27T16:02:12+00:00 https://developer.fellowshipone.com/index.php/blog/conversation_paralysis/ https://developer.fellowshipone.com/index.php/blog/conversation_paralysis/#When:20:11:49Z Scrum teaches us that feature requests (user stories) are to be written in the language of the customer (As <some role> I need <some feature> so that I can <get some value>.) These small sentences actually pack a load of information for the technical team reading them and it forces the user to really think about their feature and what they are trying to accomplish. All too often, even the customer doesn't know exactly what they want, so this format helps them to succinctly describe their problem. The beauty of the user story however is not necessarily the language or format. The user story is actually the place holder for the conversation that needs to take place. The team can then solve the user's problem by talking through the solution with the entire team's knowledge and wisdom at work (all the while conversing with the customer as well). What is even more beautiful, is that Scrum provides the guide rails that help ensure the team is talking about the problem and not acting as if they are robots on an assembly line. Remember that Scrum is a framework, not a prescriptive methodology. As we go, it places guide rails to help us with our behavior and discipline. In describing user stories, Scrum helps us to ensure we retain collaboration and teamwork. The more detail that is left out of the story, the more conversation that takes place, and the more conversation that takes place, the better the team and the solution become. Start out with the initial concept, talk about it, make notes, which then brings up other topics and considerations. Various opinions and experiences are injected and the end result should be a well-thought-out solution to a well-thought-out problem. User stories are usually adorned with acceptance criteria (bullet points that essentially explain to the team how they know they are done). In our organization we use the words "demonstrate" on acceptance criteria to enforce the spirit of Scrum in that the done feature is demonstrable product. The point is to communicate conditions of acceptance for the story, but not eliminate the need for the developers to converse about the final solution. Too often teams can run right down the list of acceptance criteria and start coding the solution as if everything they need to know is in that acceptance criteria. Ron Jeffries wrote a great post on "The 3 C's" which details the heart of what we were all taking about in our last DFW Scrum Meeting. Gary McCants stated that acceptance criteria are there to guide you, but don't let them paralyze your conversation-ability (if that is a word). Ron describes confirmation as the final deliverable to ensure we hit the mark. Remember that the conversation takes place over time and that the user story is simply the placeholder for those conversations. Don't write so much detail that you paralyze conversations from happening in your team. Tips 2011-07-07T20:11:49+00:00 https://developer.fellowshipone.com/index.php/blog/rest_api_picture_this_image_updates_creates/ https://developer.fellowshipone.com/index.php/blog/rest_api_picture_this_image_updates_creates/#When:19:57:02Z We just released another API update.  You can now create and update images from the People realm: People Images: Show (3rd) | Create (3rd) | Update (3rd) Any cool ideas on what you can do with this? Let us know what you’re doing with the API realms via twitter or forum. Nick Floyd is an Architect for Fellowship Technologies (part of Active Network).  Currently he is focused on improving, designing, and building the architecture around the Fellowship One platform.  He likes learning about new technologies and languages (the obscure and the vanilla) as well as learning about new trends and practices around getting really good software from development to the users, fast.  He is passionate about software development and helping other developers. API, News 2011-05-10T19:57:02+00:00 https://developer.fellowshipone.com/index.php/blog/a_rest_api_double_shot_groups_and_events_realms/ https://developer.fellowshipone.com/index.php/blog/a_rest_api_double_shot_groups_and_events_realms/#When:15:17:23Z We’re back again to bring you two new realms for accessing your data via FellowshipOne.  The Groups Realm and the Events Realm are the two newest members of our API family!  The Groups Realm opens up access to Fellowship One’s Groups 2.0 features and allows churches and vendors to create new Groups 2.0 capabilities or integrate with other solutions.  The Events Realm provides access to a primary event that can be associated with a Group within the Groups Realm. Note:  The Events Realm does not at this time provide access to Fellowship One Activities, Check-in, or Event Registration. Groups resources Groups Groups: List (3rd) | Show (3rd) | Search (3rd) Group Types: List (3rd) | Show (3rd) | Search (3rd) Members Members: Search (3rd) | List (3rd) | Show (3rd) | New (3rd) | Edit (3rd) | Create (3rd) | Update (3rd) | Delete (3rd) Member Types: List (3rd) | Show (3rd) Prospects Prospects: New (3rd) | Create (3rd) Events Events: List (3rd) DateRange Types DateRange Types: Show (3rd) |  List (3rd) Genders Genders: Show (3rd) |  List (3rd) Marital Statuses Marital Statuses: Show (3rd) |  List (3rd) Timezones Timezones: Show (3rd) |  List (3rd) Events resources Events Events: List (3rd) | Show (3rd) | Edit (3rd) | Update (3rd) Schedules Schedules:  List (3rd) | Show (3rd) | Edit (3rd) | New (3rd) | Create (3rd) | Update (3rd) | Delete (3rd) Locations Locations: List (3rd) | Show (3rd) | Edit (3rd) | New (3rd) | Create (3rd) | Update (3rd) | Delete (3rd) Recurrence Types Recurrence Types: List (3rd) | Show (3rd) Join me in welcoming these new APIs by consuming them!  As always let us know what you’re doing with the API realms via twitter or forum.  Please note that if you have existing API keys those keys will need to be activated for the new realms via your request.  Simply submit a key request noting in the details field that you are upgrading an existing key and then choose what realms you wan to add to it. Nick Floyd is an Architect for Fellowship Technologies (part of Active Network).  Currently he is focused on improving, designing, and building the architecture around the Fellowship One platform.  He likes learning about new technologies and languages (the obscure and the vanilla) as well as learning about new trends and practices around getting really good software from development to the users, fast.  He is passionate about software development and helping other developers. API, News 2011-05-09T15:17:23+00:00 https://developer.fellowshipone.com/index.php/blog/increasing_software_delivery_by_500/ https://developer.fellowshipone.com/index.php/blog/increasing_software_delivery_by_500/#When:12:00:49Z TL;DR (Too long; didn’t read) We are deploying software faster with a simple push of a button. This year alone we have deployed code to production 10 times versus 2 last year which is 500% more deployments this year.TL;DR (Too long; didn’t read) We are deploying software faster with a simple push of a button. This year alone we have deployed code to production 10 times versus 2 last year which is 500% more deployments this year. Introduction Here at Fellowship Technologies (part of Active Network) we have been working on ways to release our software with higher quality and faster than we ever have before. Many of us have read Continuous Delivery by Jez Humble and David Farley and used it as a guide for implementing a method of building a completely automated deployment system for moving our code into production. I will discuss Continuous Delivery and what that means for the development team here at FT in another blog post, but the book provided the guidance and the frameworks that we used to fix our deployment problem. This means that with the push of a button we can deliver software to customers. Since the button we push is the browser and stupid-looking, think of it as big red button on the wall that says “Deliver”. Push it and our code is on it’s way out the door. The problem At Fellowship Technologies we had a problem. We could not get the code that we worked on in our sprints out fast enough. There were reasons for this:   Releases were expensive We had multiple mock deployments which would require that several people get in a room and deploy code to our staging environment. We would miss configuration keys, we would find bugs that were introduced, and after we fixed all those things, we would do it again to make sure we didn’t miss them again.   We had a linchpin We had one guy who was deploying all of our code manually. If he was unavailable then we could not release. Having this single point of failure was something that more often than not came back to get us.   Humans were too involved in the process Delivery anti-pattern #1 in Jez and David’s book. We copied compiled code manually. We made configuration changes manually. Making changes manually led us to make many mistakes when deploying because we would simply forget one of the 50 steps that was required when we deployed code. Stopping the bleeding We needed to do something about all the time being wasted deploying our code. We started to go down the path of automation for our build and deployments. Using technologies that are standard to our stack (WebDeploy, Powershell, and MSBuild) and we needed something that would execute the scripts while letting us control who can do it and run under a admin account that has the rights to deploy our software. We chose Jenkins for the job of deploying software because we were already using Jenkins for our Continuous Integration needs. Configuration management Once we got an automated system in place to build our apps and deploy them, we needed a way for us to manage our configuration for our applications. For this we decided to utilize the YAML file format to generate our configuration files that we deploy. This way we can see all of our configuration values in one file and update them accordingly as well as run static analysis (I.e. make sure certain configuration values are present when we deploy to production). Here is an example of how our YAML looks: Config.Key: local: "local value" dev: "dev value" qa: "qa value" staging: "staging value" prod: "PRODUCTION value" Which, based on environment, gets translated to the following XML (for dev): <appSettings> <add key="Config.Key" value="dev value" /> </appSettings> Push it to the limit Once we had facilities to deploy we just needed to install the dependencies on our servers and configure the firewalls to deploy to them. After this initial configuration we were able to deploy software at the push of a button. Starting at zero One glaring issue is that with a push button deployment we might change a file as a user is accessing it, so we needed a way to address that. So we have zero downtime deployments. The way this works is that we signal the load balancer that a node is down without actually taking the whole site down. Once the load balancer sees the node as down it stops sending traffic to it and we can safely load new code because nobody is going to it. Once we finish deploying new code we can flag the node as normal again. Once the node is flagged as normal we re-introduce it into the server farm. Conclusion Now that we can deploy at the push of a button we can get new features and fixes out the door with at a much faster rate and with less impact because we are deploying smaller changes more often. It is worth noting that we could not have acheived automated deployments with out the help of our Technology Operations team. Without their knowledge we could not have gotten this off the ground. Without their faith that we would not totally mess up production and working with us to make sure that we didn’t we could not have achieved an automated build and deployment system. “If it hurts: do it more often.” - Martin Fowler   News 2011-05-03T12:00:49+00:00 https://developer.fellowshipone.com/index.php/blog/quick_people_api_realm_update/ https://developer.fellowshipone.com/index.php/blog/quick_people_api_realm_update/#When:20:20:55Z One of our consumers was nice enough to let us know about an “undocumented feature.”  Normally with bug fixes and small enhancements we’d just deliver the changes and let the docs tell the story, however, this change is around a more sensitive area and wanted to make sure that everyone knew about it. The change is to Creates and Updates of the people resource on status/comment. Prior to the change if you either [POST] https://churchcode.fellowshiponeapi.com/v1/people + a payload with a value for status/comment or [PUT] https://churchcode.fellowshiponeapi.com/v1/people/[id] + a payload with a value for status/comment The value for the “comment” node would not “create” or “update.” This has been fixed to now do what you might expect it to do in your sand box environment and we are planning on pushing the change to production tomorrow. If you have a chance please go check it out and let us know if you have any questions or concerns.  Happy consuming! Nick Floyd is an Architect for Fellowship Technologies.  Currently he is focused on improving, designing, and building the architecture around the Fellowship One platform.  He likes learning about new technologies and languages (the obscure and the vanilla) as well as learning about new trends and practices around getting really good software from development to the users, fast.  He is passionate about software development and helping other developers. API, News 2011-03-16T20:20:55+00:00 https://developer.fellowshipone.com/index.php/blog/introducing_the_new_rest_api_giving_realm/ https://developer.fellowshipone.com/index.php/blog/introducing_the_new_rest_api_giving_realm/#When:22:40:16Z The dev team has been working hard to bring you the next step in the Fellowship One REST API stack - the Giving Realm! We’ve opened up all sorts of resources to help you bring giving into your church.  From accounts to sub funds - all the resources you’ve been asking for served up on a RESTful plate. Realms You might also notice that we are using a new term to classify our API resource sets: REALMS. Realms are how we will be classifying groups of functionality exposed through the APIs and will help you manage your consumption through segmentation.  The realms will provide churches with the ability to allow or restrict what data consumer applications use and they will enable developers of consumer applications a platform to request specific application keys for specific functions a al carte or application keys that cover the entire stack. For instance, when requesting an API key as a developer you know that you’ll need both people and giving in your application, just request it and your key will be generated for both realms.  Resources Just as we did with the people realm we will be opening up more and more resources, so let us know what you’d like to see by chatting about it on our forum.  Note that any resource marked “3rd” will also be accessible by “1st” and “2nd” parties (if you’re not sure which one you are have a look at our authentication docs for more information). Accounts Accounts: Search(1st) | Show(1st) | Edit(1st) | New(3rd) | Create(3rd) | Update(1st) Account Types: List(3rd) | Show(3rd) Batches Batches: Search(3rd) | Show(3rd) | Edit(3rd) | New(3rd) | Create(3rd) | Update(3rd) Batch Types: List(3rd) | Show(3rd) Contribution Receipts Contribution Receipts: Search(3rd) | Show(3rd) | Edit(1st) | New(3rd) | Create(3rd) | Update(1st) Contribution Types Contribution Types: List(3rd) | Show(3rd) Funds Funds: List(3rd) | Show(3rd) | Edit(1st) | New(1st) | Create(1st) | Update(1st) Fund Types: List(3rd) | Show(3rd) Pledge Drives Pledge Drives: List(3rd) | Show(3rd) | Edit(1st) | New(1st) | Create(1st) | Update(1st) Remote Deposit Capture Batches (RDC) RDC Batches: List(1st) | Show(1st) | Edit(1st) | New(1st) | Create(1st) | Update(1st) RDC Batch Items: List(1st) | Show(1st) | Edit(1st) | New(1st) | Create(1st) | Update(1st) Reference Images Reference Images: Show(1st) | Create(1st) Sub Funds Sub Funds: List(3rd) | Show(3rd) | Edit(1st) | New(1st) | Create(1st) | Update(1st) Get to consuming and let us know what you’re doing with the API realms via twitter or forum. Nick Floyd is an Architect for Fellowship Technologies.  Currently he is focused on improving, designing, and building the architecture around the Fellowship One platform.  He likes learning about new technologies and languages (the obscure and the vanilla) as well as learning about new trends and practices around getting really good software from development to the users, fast.  He is passionate about software development and helping other developers. API, News 2011-03-08T22:40:16+00:00 https://developer.fellowshipone.com/index.php/blog/raising_the_bar/ https://developer.fellowshipone.com/index.php/blog/raising_the_bar/#When:18:51:45Z Raising The Bar Announcement from Fellowship Technologies on Vimeo. Fellowship Technologies started in 2004 and finished that year with 60 churches; this past year we added 465 churches and are now serving over 1,700 ministries worldwide. When we came to market, Software as a Service was a relatively new concept and we were able to offer our church partners capabilities that were not available in other solutions. And now it’s time to raise the bar again. Today we’re announcing that Fellowship Technologies is joining Active Network, a fast-growing Software as a Service company that wants to foster the growth of communities and businesses and help people participate in the activities they love. Check out this post for more information. News 2011-02-08T18:51:45+00:00