This presentation will include insights and updates on the development of three OGC APIs, namely OGC API Features, OGC API Records and OGC Environmental Data Retrieval API. OGC API - Features provides the fundamental API building blocks to create, modify, and query geospatial vector data on the Web, building on widely used web standards and practices with good tool support. Part 1, approved by the OGC membership in 2019 after two years of testing, focuses on capabilities that almost everyone will need who wants to share vector data via an API (support for basic spatial and temporal queries, WGS84 as the coordinate reference system). Part 2 followed a year later with support for other coordinate reference systems. Additional parts are under development to specify frequently requested API capabilities for those that need them (filtering, queries, create/update/delete, schema support, etc). This presentation will describe what is in Parts 1 and 2 of the standard, and will also explain the emerging extensions of the API. OGC API - Records specifies the behaviour of an API for searching collections of descriptive information, called records. A record contains summary information about a resource that a provider wishes to make discoverable. A resource can be a data collection, a service, a process, a style, a code list, an Earth observation asset, a machine learning model, etc. The core API of OGC API Records is the same as that defined for OGC API Features with several additional query parameters that are specifically targeted for searching collections of records. It defines several encodings for a record, including a GeoJSON, a HTML and an ATOM encoding. It builds on the work already done in other OGC APIs and endeavours to be compatible to the previous OGC catalogue specification, OGC (CSW). It furthermore endeavours to align with the STAC suite of specifications by defining a GeoJSON encoding for a record, using the same OGC API Features-based API and harmonizing API parameter names. The OGC API – Environmental Data Retrieval (EDR) candidate standard uses current web technologies and best practices to enable end-users – or anyone with web development experience – to easily identify and retrieve a subset of data from ‘big data’ stores. The idea is to save those users interested in environmental (or other) data from having to transfer and deal with datasets that inevitably contain data concerning areas or time periods that are irrelevant to their interests. The OGC API – EDR standard specifies the fundamental API building blocks required to access environmental data resources by requesting data at a Position, within an Area, or along a Trajectory, including optional time and/or vertical coordinates. In addition, as a web API, it uses a well-understood and -established mode of interaction that comes with a shallow learning curve.