Service Broker API Release Notes
- Add guidance for remembering the state of service instance and service binding operations
- Add guidance to handle 500 errors from Service Instance update
- Add guidance to handle requests with invalid data
- Allow Service Brokers to indicate if a Service Instance is still usable after a failed update or deprovisioning and if an update can be repeated
- Specify that Platforms SHOULD NOT reuse IDs
- Allow the platform to supply Service ID and Plan ID as hints when retrieving a service binding or a service instance
- Add CF and K8s annotations to the profile document
- Add support for ETag and If-Modified-Since headers
- Clarify the response code when Platform does not provide the required API version header
- Service Instances can be labelled with information defined by the Service Broker
- Add expiration date and time for bindings
- Added a delay to polling response for Service Instance and Service Binding last operations.
- Added a Service Offering specific async polling timeout.
- Allow a Service Instance context to be updated and add org name, space name, and instance names.
- Added list of endpoints to create Service Binding response body.
- Added mechanism for orphan mitigation.
- Allow brokers to return 200 for no-op update Service Instance requests.
- Allow brokers to not return parameters when returning a Service Instance or Service Binding.
- Add plan_updateable field to the Service Plan object.
- Clarify what happens when deleting during a provision/bind request.
- Restrict Operation strings to 10,000 chartacters in the response body for provisioning or deprovisioning a Service Instance, and binding or unbinding a Service Binding.
- Remove character restrictions on names of Service Offerings, and Service Plans.
- Allow empty descriptions in the response body for getting the last operations of Service Instances, and Service Bindings.
- Clarify broker behavior expected when deprovisioning while a provision request is in progress and unbinding while an unbind request is in progress.
- Clarify broker behavior when a provision request is received during a provision request for the same instance or when a binding request is received during a binding request for the same binding.
- Added maintenance info support to Service Plans.
- Added request identity header.
- Added GET endpoints for fetching a Service Instance and Service Binding
- Added support for asynchronous Service Bindings (PR) and a new last operation endpoint for Service Bindings endpoint
- Added clarity around concurrent updates (PR)
- Added clarity on how Platform's can clean up after a failed provision or bind (PR)
- Added Opaque Bearer Tokens to the Platform to Service Broker Authentication section (PR)
- Provided guidance for CLI-friendly names (PR)
- Allow for uppercase characters in Service and Service Plan names (PR)
- Clarify that extra fields in requests and responses are allowed (PR)
- Allow an updated
dashboard_urlto be provided when updating a Service Instance (PR)
- Added an OpenAPI 2.0 implementation
- Allow for periods in name fields (PR)
- Removed the need for Platforms to perform orphan mitigation when receiving an
HTTP 408response code (PR)
- Moved the
dashboard_clientfield to Cloud Foundry Catalog Extensions
- Added a compatibility matrix describing which optional features in the specification are supported by different Platforms
- Added clarity for returning Service Binding information via the GET endpoints (PR)
- Added guidance for supported string lengths (PR)
- Clarified that the
plan_updateablefield affects modifying the Service Plan, not parameters (PR)
- Clarified which Service Plan ID to use for polling the last operation endpoint after an update (PR)
- Clarified Platform behaviour when a dashboard URL is not returned (PR)
- Fixed an incompatible change introduced in v2.12 (PR)
- Added clarity around the state of resources after a failure (PR)
- Added Content Type guidelines
schemasfield to services in the catalog that brokers can use to declare the configuration parameters their service accepts for creating a service instance, updating a service instance and creating a service binding.
contextfield to request body for creating a service binding.
- Added warning text about using characters outside of the "Unreserved Characters" set in IDs.
- Added information about
binding_idMUST be globally unique non-empty strings.
- Allow non-BasicAuth authentication mechanisms.
- Added a Getting Started page including sample service brokers.
- Define what a CLI-friendly string is.
- Add service/plan metadata conventions.
- Add originating identity HTTP header.
contextfield to request body for provisioning a service instance (
PUT /v2/service_instances/:instance_id) and updating a service instance (
PATCH /v2/service_instances/:instance_id). Also added the profile.md file describing RECOMMENDED usage patterns for environment-specific extensions and variations.
contextwill replace the
space_guidrequest fields in future versions of the specification. In the interim, both SHOULD be used to ensure interoperability with old and new implementations.
- The specification now uses RFC2119 keywords to make it clearer when things are REQUIRED rather than OPTIONAL or RECOMMENDED.
- Request and response parameters of type string, if present, MUST be a non-empty string.
- Cleaned up text around status codes in responses, clarifying when they MUST be returned.
- Added clarity around the
- Clarified the semantics of
parametersfields in the updating a service instance request body.
- Clarified the default value of the
- Clarified when
route_service_urlis REQUIRED and when brokers can return extra data in bindings.
- Added field
bindableto plan objects in /v2/catalog response. This allows services to have both bindable and non-bindable plans.
- Service bind responses now include an optional field called
volume_mounts. Backward incompatible changes to
volume_mountsfield in service bind response from experimental 2.9 format to final format.
last_operationendpoint now supports
plan_idas request parameters.
A new field
operationmay now be returned by brokers in asynchronous responses for Provision, Update, Deprovision. This field enables brokers to provide an internal identifier for the operation that clients should provide back to the service broker when polling the
In support for Route Services, service broker may now return a
route_service_urlin the response for a create binding request.
A broker must specify
requires: ["route_forwarding"]in its catalog endpoint if it supports Route Services.
Clients may now send a new field
bind_resourcewith the bind request, under which the parameters required for the binding are found. This would include, for example,
app_guidfor an app binding and
routefor a route binding. For backwards compatibility,
app_guidwill remain a top-level key in addition to being included in the
Added support for Asynchronous Operations. Brokers may now return a 202 Accepted in response to provision, update, or deprovision requests to indicate the requested operation is in progress.
accepts_incomplete=truemust be passed by the broker client with requests for provision, update, or deprovision to indicate support for an asynchronous response. The broker can then choose to execute the request synchronously or asynchronously.
Added support for querying
last_operationstatus at a new endpoint:
app_guidfield is no longer guaranteed to be included with create service binding requests
service_idis required with update service instance requests
- Added support for Arbitrary Parameters: service-specific configuration parameters that can be included with provision, update and bind requests
- Added support for broker clients to change the service plan for a specified service instance using new Update Service Instance endpoint
dashboard_clientfield to /v2/catalog to enable broker client to provision OAuth client for a service dashboard
- Added field
freefor service plan in catalog endpoint
- New field
app_guidis required with bind requests