The API package header lists the API parameters with descriptive comments. You can use SQL*Plus to describe the API, listing the parameters. Each published API has a set of parameters, most of which may be specified. Most parameters map to an HRMS database column. There are additional processing control parameters that do not map to a database column. These are discussed separately in this FAQ. Each API parameter name is prefixed with p_. If the parameter maps to a database column, the remainder of the name will usually be the same as the table column name. API parameters can be categorized into IN, OUT, and IN OUT. IN parameters that have a default defined do not need to be passed to the API call; otherwise, you need to specify the parameter in the API call. OUT parameters must remain null but declared and passed in the API call. Normally OUT parameters are generated by the API call, such as messages and warnings. IN OUT must be passed in the API call, but these parameters require you to be aware of your HRMS setup to identify which IN OUT parameters must remain null and which must pass a value in the call to the API. For example, if you have automatic employee numbering defined in your business group, the employee number parameter must remain NULL in the call to the API; however, if employee numbering is manual, then you need to pass an employee number in the call to the API. You can override defaulted parameters, to address your business rules. Finally, APIs support SQL named notation: if you do not directly assign variables in your API parameter call list, then number and sequence of parameters in the calling and called procedures must match.