> ## Documentation Index > Fetch the complete documentation index at: https://mintlify.hoop.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Approve a sidecar login > Creates a sidecar in the caller's organization that the waiting sidecar's token reaches. A free organization holds 1 sidecar. ## OpenAPI ````yaml https://use.hoop.dev/api/openapiv3.json post /sidecars/login/{code}/approve openapi: 3.0.3 info: contact: email: help@hoop.dev name: Help url: https://help.hoop.dev description: >- Hoop.dev is an access gateway for databases and servers with an API for packet manipulation license: name: MIT url: https://opensource.org/license/mit termsOfService: https://hoop.dev/docs/legal/tos title: Hoop Api version: 1.281.8 servers: - url: https://use.hoop.dev/api security: [] tags: - description: > Hoop implements Oauth2 and OIDC protocol to authenticate users in the system. To obtain a valid access token users need to authenticate in their own identity provider which is generated as a JSON response to the endpoint `http(s)://use.hoop.dev/api/login`. The identity provider them redirects the user to the callback endpoint containing the access token. The recommended approach of obtaining an access token is by visiting the Webapp main's page or using the **Hoop command line**. Example: ```sh hoop config create --api-url https://use.hoop.dev # save the token after authenticating at $HOME/.hoop/config.toml hoop login # show token information hoop config view --raw ``` With an access token you could use any HTTP client to interact with the documented endpoints. The token must be sent through the `Authorization` header. Example: ```sh # obtain the current configuration of the server curl https://use.hoop.dev/api/serverinfo -H "Authorization: Bearer $ACCESS_TOKEN" ``` name: Authentication - description: > Users are active and assigned to the default organization when they signup. A user could be set to an inactive state preventing it from accessing the platform, however it’s recommended to manage the state of users in the identity provider. - The `sub` claim is used as the main identifier of the user in the platform. - The profile of the user is derived from the id_token claims `email` and `name`. When a user authenticates for the first time, it performs an automatic signup that persist the profile claims along with it’s unique identifier. ​ ### Groups Groups allows defining who may access or interact with certain resources. - For connection resources it’s possible to define which groups has access to a specific connection, this is enforced when the Access Control feature is enabled. - For review resources, it’s possible to define which groups are allowed to approve an execution, this is enforced when the Review feature is enabled. > This resource could be managed manually via Webapp or propagated by the identity provider via ID Token. In this mode, groups are sync when a user performs a login. ### Roles - The `admin` group is a special role that grants full access to all resources This role should be granted to users that are responsible for managing the Gateway. All other users are regular, meaning that they can access their own resources and interact with connections. name: User Management - name: Machine Identities - description: Routes used to manage and obtain information about the runtime server. name: Server Management - description: Features available in the gateway. See also **Plugin** resources. name: Features - description: >- Proxy manager endpoints controls how clients connect via gRPC in the gateway. These endpoints are meant to be used when a client is initialized via `hoop proxy-manager`. name: Proxy Manager - name: Connections - name: Agents - name: Sidecars - name: Runbooks - name: Guard Rails - name: Approvals - name: Sessions - name: Organization Management - name: Reports - description: > Security audit log API. Only users in the **admin** group can access these endpoints. Audit log entries record security-relevant events (who performed an action, when, on which resource, and whether it succeeded). Use the list endpoint with filters to query by actor, resource type, action, outcome, or date range. Results are paginated and ordered by `created_at` descending. name: Audit Logs paths: /sidecars/login/{code}/approve: post: tags: - Sidecars summary: Approve a sidecar login description: >- Creates a sidecar in the caller's organization that the waiting sidecar's token reaches. A free organization holds 1 sidecar. parameters: - description: The user code in: path name: code required: true schema: type: string requestBody: content: application/json: schema: $ref: '#/components/schemas/openapi.SidecarLoginApproveRequest' description: The request body resource x-originalParamName: request responses: '201': content: application/json: schema: $ref: '#/components/schemas/openapi.SidecarResponse' description: Created '400': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Bad Request '403': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Forbidden '404': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Not Found '409': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Conflict '410': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Gone '422': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Unprocessable Entity '429': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Too Many Requests '500': content: application/json: schema: $ref: '#/components/schemas/openapi.HTTPError' description: Internal Server Error components: schemas: openapi.SidecarLoginApproveRequest: properties: name: description: The sidecar's name. Empty keeps the name the sidecar asked for. example: payments-sidecar type: string type: object openapi.SidecarResponse: properties: applied_revision: example: 8f14e45fceea167a5a36dedd4bea2543 type: string bound_rules: description: >- BoundRules names the rules the control plane distributes to this sidecar, and the listener each one lands on. They are NOT inside Configuration and never will be: a bound rule is folded into the SERVED document on every handshake and nothing is stored, so one row update reaches a fleet. That is also why this field has to exist — a page reading Configuration alone shows a listener enforcing nothing while the sidecar enforces the rule. items: $ref: '#/components/schemas/openapi.SidecarRuleBinding' type: array bound_rules_unavailable: description: >- BoundRulesUnavailable is true when the bindings could not be read. BoundRules is then empty because it is unknown, not because nothing is bound, and a page must not read it as "no rules". type: boolean config_state: description: >- ConfigState is what the sidecar runs, read from the fields above and the clock: applied, applying (served under a heartbeat ago, not reported yet), not_applied (served longer ago and never reported, the shape of a sidecar that exits at boot on it), refused (by the sidecar), not_served (the control plane refused to serve this build, LastError says why), restart, or unknown (a build too old to report). Empty while nothing was served, before the first handshake, and for a sidecar running its own file; a refusal shows even then. example: applied type: string configuration: description: The stored daemon configuration. type: object created_at: description: Creation timestamp type: string created_by: description: Subject of the admin who created it type: string deprecations: description: |- Deprecations lists the deprecated spellings the stored configuration still uses, phrased for an operator. The sidecar folds them on load, where nobody reads the warning. items: type: string type: array detached_rules: allOf: - $ref: '#/components/schemas/openapi.SidecarDetachedRules' description: |- DetachedRules names the rules an owner switch removed, on the PATCH that switched. Deleted rules came from this sidecar's file; unbound rules stay for their other targets. id: description: Unique identifier format: uuid readOnly: true type: string identity_issuer: description: |- IdentityIssuer and IdentitySubject name the service account identity this sidecar is bound to: the first that reached it through hoop-sidecar-identity. Empty for a sidecar no identity reached, or whose binding an admin cleared. example: >- https://container.googleapis.com/v1/projects/my-project/locations/europe-west1/clusters/eu type: string identity_subject: example: system:serviceaccount:ws-123:hoop-sidecar type: string last_error: description: |- LastError is the reason the sidecar gave with a refused or restart outcome. Empty otherwise. example: >- the config file sent a config this build refuses: parse config: json: unknown field "future_key" type: string last_outcome: description: |- LastOutcome is what the sidecar did with the last configuration it handled: applied, unchanged, restart, refused or retry. It is the field that separates a sidecar enforcing the current rules from one that refused them and kept the old ones. A refusal, or a document needing a restart, leaves the sidecar handshaking on time with stale rules, and nothing else tells the two apart. Empty for a sidecar that has handled nothing yet, or one too old to report. Empty must read as unknown, never as converged. example: applied type: string last_seen_at: description: Last time the sidecar handshook. Empty until it does. type: string name: description: Human-readable name example: payments-sidecar type: string org_id: description: Organization ID format: uuid readOnly: true type: string reported_configuration: description: >- ReportedConfiguration is the config file the sidecar runs, as its last handshake reported it. The control plane adopts it only when an admin sends load_from_disk false. Absent for a build too old to report it. type: object reported_configuration_at: description: When the sidecar last reported ReportedConfiguration. type: string served_revision: description: >- ServedRevision names the configuration last answered to this sidecar, and AppliedRevision the one it says it is running. Equal means the sidecar is enforcing what the control plane holds. Both are opaque: the control plane issues them and compares them to itself. Nothing parses them. example: 8f14e45fceea167a5a36dedd4bea2543 type: string version: description: >- Version reported at the last handshake. Empty until the sidecar calls. example: 1.0.0 type: string type: object openapi.HTTPError: properties: message: example: the error description type: string type: object openapi.SidecarRuleBinding: properties: kind: description: >- Which feature the rule belongs to: guardrail, datamasking or analyzer example: guardrail type: string listener_name: description: The listener that enforces it example: appdb type: string rule_name: description: The rule's name example: no-destructive-sql type: string type: object openapi.SidecarDetachedRules: properties: deleted: allOf: - $ref: '#/components/schemas/openapi.SidecarRuleNames' description: >- Rules deleted: imported from this sidecar's file, with no target left. unbound: allOf: - $ref: '#/components/schemas/openapi.SidecarRuleNames' description: Rules only unbound from this sidecar. type: object openapi.SidecarRuleNames: properties: analyzers: items: type: string type: array data_masking: items: type: string type: array guardrails: items: type: string type: array type: object ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.