Tenderbase API Help Page
Tenderbase Cloud Infrastructure (TCI) is a comprehensive collection of cloud services that empower you to develop and operate various applications and services within a resilient hosted environment.
Tenderbase Cloud Infrastructure (TCI) is a comprehensive collection of cloud services that empower you to develop and operate various applications and services within a resilient hosted environment.
Tenderbase Cloud Infrastructure (TCI) offers a suite of cloud services that empower you to create and operate a diverse array of applications and services within a reliable hosted environment. TCI provides top-notch computing power (in the form of physical hardware instances) and flexible storage capacity, all within a secure virtual network overlay that seamlessly integrates with your on-premises network.
TenderbaseAPI is undergoing an update. With Version 2 of the API, we strive to enhance the organization and streamline the methods to assist users in efficiently submitting and retrieving notices. To learn more about the updates, please visit Version 2.
This document aims to outline the procedures through which opportunity providers and other entities can submit their opportunities to the Tenderbase. This can be accomplished through the WebAPI, either individually upon publication or through a bulk import process at a more convenient time. Both methods utilize standardized interfaces, with the latter enabling the submission of data collections in a single operation.
The purpose of this document is to outline the available interfaces for approved external notice publication providers, enabling them to publish their notices in the Tenderbase.
While primarily serving as a specification document for the inbound interface, this document will also provide insights into how certain aspects of the specification are handled by the inbound feed. Specifically, it will address the handling of category and region information. Additionally, it will outline any specific data types and field length limitations imposed on external providers to ensure proper aggregation of their opportunities within the Tenderbase.
This document will offer an overview of how warnings and error messages will be communicated to providers. However, please note that specific warnings or errors are not included currently.
This document aims to provide an overview of the interfaces accessible to approved external notice publication providers. These interfaces empower them to seamlessly publish their notices within the Tenderbase services.
Representational State Transfer (REST) is a modern architectural style that draws inspiration from the web's architecture and leverages the power of HTTP. In REST, clients send requests to servers, which then process these requests and provide suitable responses. The communication between clients and servers revolves around the exchange of "representations" of "resources". In the context of the Tenderbase service, the primary resource of interest is the procurement opportunity.
There is a potential for confusion as each notice within Tenderbase has two distinct identifiers. The first identifier is created by the notice creator and follows a format that is meaningful to them. This identifier must be unique within the organization creating the notice. The second identifier is assigned internally by Tenderbase and takes the form of a GUID.
When creating a new notice, the creator needs to provide a unique identifier specific to their organization. It is important to ensure that this identifier has not been previously used by the originating organization, as it would result in a validation error. Upon successful creation of a notice, a new unique identifier in the form of a GUID is returned. This newly generated identifier is then utilized throughout the Web API to carry out further operations related to the notice.
Authentication is required to access all of the Web API. To obtain an access token you must POST to the token endpoint. The POST request must include a basic authorization containing { "api_token":"2YotnFZFEjr1zCsicMWpAA", "licence_key":2YotnFZFEjr1zCsicMWpAA } in POST Request.
The region(s) of a notice specify the geographical location where the contract works will be carried out, known as the delivery location. Providers have the option to provide one or more regions, postcode information, or select the "Any Region" option. It is mandatory for providers to supply at least one of these choices, depending on their preference and the scope of the delivery. In cases where postcode information is provided, it will be used to retrieve geo-coordinates and determine the corresponding region.
Email addresses must adhere to the standard pattern, typically in the format ofgiven.family@domain.ext. No additional validation checks are performed beyond verifying the conformance to this pattern.
Email addresses must follow the standard pattern, such as given.family@domain.ext. No additional validation checks are conducted. For the country field, the value must be selected from the countries API method and should be a valid "name" value. No further validation checks are performed beyond this requirement.
All times mentioned are local UK time, either GMT or BST, depending on the prevailing time zone on the given date.To indicate the time zone, the date-time is accompanied by time zone information. "Z" denotes GMT (October to March), while "+01:00" signifies BST (March to October).The time component is applicable to the Deadline Date field for notices published starting from 1 August 2020.
The valid notice types are determined by the NoticeType enumeration.
Search for published notice OCDS releases package with optional search criteria.
Search for published notice OCDS releases package with tender id.