The functions provided by the HDF5 C-API are grouped into the following modules:

Attributes — Management of HDF5 attributes (H5A)
Datasets — Management of HDF5 datasets (H5D)
Dataspaces — Management of HDF5 dataspaces which describe the shape of datasets and attributes (H5S)
Datatypes — Management of datatypes which describe elements of datasets and attributes (H5T)
Error Handling — Functions for handling HDF5 errors (H5E)
Event Sets — Functions for handling HDF5 event sets (H5ES)
Files — Management of HDF5 files (H5F)
Filters — Configuration of filters that process data during I/O operation (H5Z)
Groups — Management of groups in HDF5 files (H5G)
Identifiers — Management of object identifiers and object names (H5I)
Library — General purpose library functions (H5)
Links — Management of links in HDF5 groups (H5L)
Maps — Management of HDF5 maps (H5M)
Objects — Management of objects in HDF5 files (H5O)
Plugins — Programmatic control over dynamically loaded plugins (H5PL)
Property Lists — Management of property lists to control HDF5 library behavior (H5P)
References — Management of references to specific objects and data regions in an HDF5 file (H5R)
Virtual Object Layer — Management of the Virtual Object Layer (H5VL)

Deprecated Functions and Types: A list of deprecated functions and types can be found here.

Etiquette

Here are a few simple rules to follow:

Handle discipline: If you acquire a handle (by creation or copy), you own it! (..., i.e., you have to close it.)
Dynamic memory allocation: ...
Use of locations: Identifier + name combo

Attention: C++ Developers using HDF5 C-API functions beware:
Several functions in this C-API take function pointers or callbacks as arguments. Examples include H5Pset_elink_cb(), H5Pset_type_conv_cb(), H5Tconvert(), and H5Ewalk2(). Application code must ensure that those callback functions return normally such to allow the HDF5 to manage its resources and maintain a consistent state. For instance, those functions must not use the C setjmp / longjmp mechanism to leave those callback functions. Within the context of C++, any exceptions thrown within the callback function must be caught, such as with a catch(…) statement. Any exception state can be placed within the provided user data function call arguments, and may be thrown again once the calling function has returned. Exceptions raised and not handled inside the callback are not supported as it might leave the HDF5 library in an inconsistent state. Similarly, using C++20 coroutines cannot be used as callbacks, since they do not support plain return statements. If a callback function yields execution to another C++20 coroutine calling HDF5 functions as well, this may lead to undefined behavior.