# Add new ingredients

Endpoint: POST /ingredients
Version: 1.0.0
Security: jwt

## Request fields (application/json):

  - `kitchenId` (string, required)
    Example: "altman-family"

  - `name` (string, required)
    Example: "broccoli"

  - `quantity` (number, required)
    Example: 2

  - `unit` (string, required)
    Example: "cups"

  - `useBefore` (string, required)
    Example: "2019-08-24T14:15:22Z"

## Response 201 fields (application/json):

  - `id` (string)
    Example: "497f6eca-6276-4993-bfeb-53cbbbba6f08"

  - `object` (string)
    Example: "ingredient"

  - `kitchenId` (string)
    Example: "altman-family"

  - `name` (string)
    Example: "broccoli"

  - `quantity` (number)
    Example: 2

  - `unit` (string)
    Example: "cups"

  - `useBefore` (string)
    Example: "2019-08-24T14:15:22Z"

  - `createdAt` (string)
    Example: "2019-08-24T14:15:22Z"

## Response 401 fields (application/problem+json):

  - `type` (string, required)
    URI reference that uniquely identifies the problem type only in the context of the provided API. Opposed to the specification in RFC 9457 (formerly RFC 7807), it is neither recommended to be dereferenceable and point to a human-readable documentation nor globally unique for the problem type.
    Example: "/some/uri-reference"

  - `title` (string, required)
    Short summary of the problem type. Written in English and readable for engineers, usually not suited for non technical stakeholders and not localized.
    Example: "some title for the error situation"

  - `status` (integer, required)
    HTTP status code generated by the origin server for this occurrence of the problem.
    Example: 400

  - `detail` (string)
    Human readable explanation specific to this occurrence of the problem that is helpful to locate the problem and give advice on how to proceed. Written in English and readable for engineers, usually not suited for non technical stakeholders and not localized.
    Example: "some description for the error situation"

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem, e.g. by adding a fragment identifier or sub-path to the problem type. May be used to locate the root of this problem in the source code.
    Example: "/some/uri-reference#specific-occurrence-context"

  - `object` (string, required)
    Enum: "problem"

  - `errors` (array)
    Additional information about the error situation. May be omitted if no additional information is available.

## Response 403 fields (application/problem+json):

  - `type` (string, required)
    URI reference that uniquely identifies the problem type only in the context of the provided API. Opposed to the specification in RFC 9457 (formerly RFC 7807), it is neither recommended to be dereferenceable and point to a human-readable documentation nor globally unique for the problem type.
    Example: "/some/uri-reference"

  - `title` (string, required)
    Short summary of the problem type. Written in English and readable for engineers, usually not suited for non technical stakeholders and not localized.
    Example: "some title for the error situation"

  - `status` (integer, required)
    HTTP status code generated by the origin server for this occurrence of the problem.
    Example: 400

  - `detail` (string)
    Human readable explanation specific to this occurrence of the problem that is helpful to locate the problem and give advice on how to proceed. Written in English and readable for engineers, usually not suited for non technical stakeholders and not localized.
    Example: "some description for the error situation"

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem, e.g. by adding a fragment identifier or sub-path to the problem type. May be used to locate the root of this problem in the source code.
    Example: "/some/uri-reference#specific-occurrence-context"

  - `object` (string, required)
    Enum: "problem"

  - `errors` (array)
    Additional information about the error situation. May be omitted if no additional information is available.

## Response 404 fields (application/problem+json):

  - `type` (string, required)
    URI reference that uniquely identifies the problem type only in the context of the provided API. Opposed to the specification in RFC 9457 (formerly RFC 7807), it is neither recommended to be dereferenceable and point to a human-readable documentation nor globally unique for the problem type.
    Example: "/some/uri-reference"

  - `title` (string, required)
    Short summary of the problem type. Written in English and readable for engineers, usually not suited for non technical stakeholders and not localized.
    Example: "some title for the error situation"

  - `status` (integer, required)
    HTTP status code generated by the origin server for this occurrence of the problem.
    Example: 400

  - `detail` (string)
    Human readable explanation specific to this occurrence of the problem that is helpful to locate the problem and give advice on how to proceed. Written in English and readable for engineers, usually not suited for non technical stakeholders and not localized.
    Example: "some description for the error situation"

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem, e.g. by adding a fragment identifier or sub-path to the problem type. May be used to locate the root of this problem in the source code.
    Example: "/some/uri-reference#specific-occurrence-context"

  - `object` (string, required)
    Enum: "problem"

  - `errors` (array)
    Additional information about the error situation. May be omitted if no additional information is available.