The Tessitura REST API is a fundamental service of the Tessitura platform. It is a central provider of Tessitura functionality available for use in your organizational and constituent facing applications and sites.
Using standard formats (XML/JSON) for requests and responses, the API can be used with nearly any platform or framework equipped to handle HTTP communication. While the services are written in .NET (C#), they conform to standard REST Service practices and can accept and return data in either XML or JSON format.
Starting with V12, what were five different services in v11 (AuthenticationService, CampaignService, ConstituentService, DataService, and ReferenceDataService) have been combined into one TessituraService.
TessituraService (REST API) is divided into broad functional areas.
| CRM | The core constituent resources of the API, such as Constituents (TessituraService/CRM/Constituents), addresses, and other constituent information. |
|---|---|
| Txn | Transaction related resources such as Performances (/TessituraService/Txn/Performances) and Prices. Also the resources that are called when an order or contribution is saved are found under this subheading. |
| Finance | Campaign, Appeal and Plan and Portfolio related resources, such as /TessituraService/Plans. |
| ReferenceData | System Tables related resources, such as Address Types (/TessituraService/ReferenceData/AddressTypes) |
| Reporting | Reporting related resources |
| Security | Authentication and Security related resources |
| PaymentGateway | Credit Card Processing |
| Web | A group of resources optimized for web based cart and transactions. |
| Other | In addition there are several service resources that do not fall under a category. |
| Batch (/TessituraService/Batch) | |
| Diagnostics (/TessituraService/Diagnostics) | |
| Custom (/TessituraService/Custom) Custom tables can be exposed through this resource. | |
| Email (/TessituraService/Email) Resource to send emails. |
The Tessitura REST API uses the four main HTTP verbs. Below is a description of each verb and what is expected to be sent and received for each
GET: Retrieve a resource
Request contains URI and HTTP headers, but no body. Response contains HTTP status code and XML/JSON body.
POST: Create a new resource or initiate a process
Request contains URI (without an Id), HTTP headers, and XML/JSON body. Response contains HTTP status code and XML/JSON body. POST verb is also used to do operations that accept a request object. Examples including Txn/Performances/Search and CRM/Constituents/ConvertToHousehold.
PUT: Update an existing resource
Request contains URI (with an Id), HTTP headers, and XML/JSON body. Response contains HTTP status code and XML/JSON body.
DELETE: Delete a specified resource
Request contains URI (with an Id) and HTTP headers, but no body. Response contains HTTP status code but no body
Curly braces, {}, in the URL indicate values you have to supply. Example: CRM/Addresses/{addressId}
{addressId} should be replaced by the id of the address. For example, CRM/Addresses/231
| The following data formats are supported. | ||
|---|---|---|
| Type | HTTP Header | Value |
| XML | accept | text/xml |
| JSON | accept | application/json |
Most resources have five audit properties:
None of the audit properties are required for a create (POST). They will be provided by the service on a successful create/update. UpdatedDateTime is required for an update (PUT) and is used for optimistic locking. The value sent should match the latest datetime value in the database. If the values do not match the service will return an error. For an update (PUT) all the non-audit properties must be specified. Any properties that are not submitted will be treated as null. The normal, recommended workflow is to retrieve (GET) a resource, merge any desired changes and then update (PUT).
Some resources have a summary representation. These are read-only representations of the resources that are useful for UI controls like dropdowns and combo boxes with a smaller response size.