I'm trying to pull in Stripe transactions into Tessitura via my own integration and can't seem to figure out what entity/resource to work with. I've tried "Contributions" as the only one that actually allows me to "Post" to, (which shows it only applies to some "interceptor" plugin only), and do not know how to get a sample payment to show up for a constituent... Any help would be great! Thanks in advance!
It really all just depends on what you're trying to do. If you're looking to create the contributions in Tessitura on the fly as they come in, the API is the way to go. If you're just worried about importing the data in bulk and you're not necessarily concerned about it being available immediately then setting up an import process is the way to go. You can even set up a job to scan a network/FTP location and look for new files to import automatically. So rather than have the API do anything you can set up your application to create a data file, move it to an FTP location, and then let SQL Server/Tessitura take over from there.It just depends on the needs and how soon you need Tessitura to be updated with the transactions.
It's not so much that the transactions have to be realtime or near time synced, but that we would like to not have to do a manual process of using a utility to get the donations synced. We would like to just have a batch job that syncs the donors and donations over to Tessitura via the API.
Gotcha. Unfortunately I don't think that really exists for the API out of the box but the link that Joe sent is probably good to look at. You might be able to log accounts in using those methods and then automate the checkout process one at a time. Alternately, you can take steps to automate the import utility but it would not be via the API. Specifically you could write something to get the data you need, generate a text/data file, upload it to an FTP location, and then have the Tessitura import utility run on a schedule. Theoretically that should make it handsfree albeit a bit low-tech. You can also write your own custom API call that you could potentially accomplish what you need with that. You could pass whatever parameters you wanted if you set something up yourself.
Tunc Samiloglu -- I'm not entirely certain I've caught up 100% on the problem you're trying to solve, but I built a MobileCause integration while working at Arsht Center that imported donations from a 3rd-party in a way that sounds very much like what you're trying to do. You do not need to log a Constituent into a Session if you create a Business Facing Session using `POST` to `Web/Session/BusinessFacing`. You can set the Constituent ID of the Business Facing Session using `PUT` to `Web/Session/{sessionKey}/Constituents`.
I'm trying to get access back to the Postman queries that detail the process I used to integrate MobileCause for Arsht Center. But Business Facing Sessions was my go to for things like this.
Pinging Cliff Bailey and Joe Begly -- just to close the loop on your comments, this functionality absolutely does exist out-of-the-box via the REST API. It's just Business Facing Sessions and not the normal Sessions a lot of web integrators are used to using for Constituents who are expected to login or register an account.
I will look into this! what you did sounds exactly like what we're trying to do. Thank you!
That's really cool! I've actually never used that endpoint since most of the "bulk/import" stuff we've done is always in SQL. Great to know though, thanks for exposing me to that functionality.
I completely forgot about the BusinessFacing session. Very helpful. I'd be interested in seeing the resources you used for the MobileCause integration if you're able to find that. Thanks!
You bet, David Frederick! Here's the basic outline from memory:
POST
Finance/BatchMaintenance/Active
Finance/BatchMaintenance
Web/Session/BusinessFacing
SessionInfo
GET
CRM/Constituent/Search
CRM/Constituents/Snapshot
PUT
Web/Session/{sessionKey}/Constituents
Web/Cart/{sessionKey}/Contributions
Web/Cart/{sessionKey}/Checkout
I'll post the Postman docs if I'm able.