The Open Procurement API is the only interface to Open Procurement database that is core unit of Open Procurement infrastructure.
The Open Procurement API is a REST-ful interface that provides programmatic access to Tender database of Open Procurement system. It provides predictable URLs for accessing resources, and uses built-in HTTP features to receive commands and return responses. This makes it easy to communicate with.
The API accepts JSON or form-encoded content in requests. It returns JSON content in all of its responses, including errors. Only the UTF-8 character encoding is supported for both requests and responses.
All API POST and PUT requests expect a top-level object with a single element in it named data. Successful responses will mirror this format. The data element should itself be an object, containing the parameters for the request. In the case of creating a new tender, these are the fields we want to set on the tender itself.
If the request was successful, we will get a response code of 201 indicating the object was created. That response will have a data field at its top level, which will contain complete information on the new tender, including its ID.
If something went wrong during the request, we’ll get a different status code and the JSON returned will have an errors field at the top level containing a list of problems. We look at the first one and print out its message.
The project has pre alpha status.
The source repository for this project is on GitHub: https://github.com/openprocurement/openprocurement.api
You can leave feedback by raising a new issue on the issue tracker (GitHub registration necessary).
For general discussion use Open Procurement General maillist.
General information, roadmap, and technical specifications for the Open Procurement project can be found at openprocurement.org.
Information on work with Negotiation procurement procedure is in this tutorial.
Instructions for the Open Procurement Open UA procedure can be found in this documentation.
API is highly unstable, and while API endpoints are expected to remain relatively stable the data exchange formats are expected to be changed a lot. The changes in the API are communicated via Open Procurement API maillist.
- Stand-still period for each of the awards independently
- Added new cancellation API
- Set title, classification and additionalClassifications required
- Added validation identical cpv groups of items
- Added upload tender documents by auction user
- Closing tender by registering contract
- Strict mode for patching operation
- Cancalling active award
- Authenticated couchdb access
- Fixed authentication of PUT and PATCH methods
- Optimized calls to db on start
- Fixed deliveryLocation fields
- Fixed edit format field in Documents
- Fixed restrictions uploading documents of bid
- Token Broker authorization
- Actor token authorization
- Added Item.deliveryLocation
- Pending complaints Tender completion blocking
- Rescheduling of failed auctions
Released: not released
- Actor token generation
- Added Item.deliveryAddress
- Award sequential review logic
- Tender.deliveryDate moved to Item.deliveryDate
- Filing Complaint on award
- Complaint attachments
- Tender Cancelling
- Question authors visibility
- Tender status codelist harmonized
- Asking Questions
- Filing Complaint on tender conditions
- Answer Question
- Publish Complaint resolution
- Retrieve Questions and Answers, Complaints and Resolutions
- Auction Scheduler
- Auction Runner
- Tender Listing Batching (optimized for sync operations)
- Documents retrieval
- Change tracking
- Options: Pretty-print, JSONP
- Introduction of state machine and time-based state switching
- Set up general build, testing, deployment, and ci framework.
- Creating/modifying tender
- Adding/modifying/cancelling tender proposal
- Awarding/disqualification of tender proposals