# Get Participant

# Overview
Use this API to Get details of an existing Participant
## Scope
Client application must have 'app.conversation.conversationmgr.manage' or 'app.conversation.conversationmgr.read' scope assigned.

Endpoint: GET /participants/{id}
Security: oAuthClient

## Path parameters:

  - `id` (string, required)
    id of object

## Response 200 fields (application/json):

  - `id` (string)

  - `created` (string)
    Last modified time in GMT

  - `modified` (string)
    Last modified time in GMT

  - `name` (string, required)
    Unique name for participant

  - `type` (string, required)
    Type of participant. eGain Bot participants are created automatically when bot is created in eGain VA application.
    Enum: "custom_bot", "egain_bot"

  - `description` (string)

  - `active` (boolean)

  - `application` (object, required)

  - `application.id` (string, required)
    ID to clientApplication, messages for this participant are sent to call back url registered in this client application
    Example: d987d07a-d59c-11ea-87d0-0242ac130001

  - `intents` (object)
    Intents supported by bot.

  - `intents.intent` (array, required)

  - `intents.intent.value` (string, required)
    Internal value for intent.

  - `intents.intent.displayValue` (string, required)
    Display value for intent.

  - `options` (array)

  - `options.name` (string, required)
    name of attribute

  - `options.value` (string, required)
    value of attribute

## Response 400 fields (application/json):

  - `code` (string, required)
    String that follow the pattern {integer}-{integer}.
* The first part is http status code.  The code is unique as a whole. Nothing common between 400-101 and 404-101

  - `developerMessage` (string, required)
    Response explaining what happened

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly message only supported by some API.
* Client must request explicitly by passing X-egain-error-message=yes header

## Response 401 fields (application/json):

  - `code` (string, required)
    String that follow the pattern {integer}-{integer}.
* The first part is http status code.  The code is unique as a whole. Nothing common between 400-101 and 404-101

  - `developerMessage` (string, required)
    Response explaining what happened

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly message only supported by some API.
* Client must request explicitly by passing X-egain-error-message=yes header

## Response 403 fields (application/json):

  - `code` (string, required)
    String that follow the pattern {integer}-{integer}.
* The first part is http status code.  The code is unique as a whole. Nothing common between 400-101 and 404-101

  - `developerMessage` (string, required)
    Response explaining what happened

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly message only supported by some API.
* Client must request explicitly by passing X-egain-error-message=yes header

## Response 500 fields (application/json):

  - `code` (string, required)
    String that follow the pattern {integer}-{integer}.
* The first part is http status code.  The code is unique as a whole. Nothing common between 400-101 and 404-101

  - `developerMessage` (string, required)
    Response explaining what happened

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly message only supported by some API.
* Client must request explicitly by passing X-egain-error-message=yes header