> ## Documentation Index > Fetch the complete documentation index at: https://docs.0xkey.io/llms.txt > Use this file to discover all available pages before exploring further. # Get authenticator > Get details about an authenticator. ## OpenAPI ````yaml /scripts/openapi-gen/openapi.json post /public/v1/query/get_authenticator openapi: 3.0.1 info: title: API Reference description: Review our [API Introduction](../api-introduction) to get started. contact: {} version: '1.0' servers: - url: https://api.0xkey.io security: - ApiKeyAuth: [] - AuthenticatorAuth: [] tags: - name: Organizations description: >- An Organization is the highest level of hierarchy in 0xkey. It can contain many Users, Private Keys, and Policies managed by a Root Quorum. The Root Quorum consists of a set of Users with a consensus threshold. This consensus threshold must be reached by Quorum members in order for any actions to take place. See [Root Quorum](../concepts/users/root-quorum) for more information - name: Invitations description: >- Invitations allow you to invite Users into your Organization via email. Alternatively, Users can be added directly without an Invitation if their ApiKey or Authenticator credentials are known ahead of time. See [Users](./api#tag/Users) for more information - name: Policies description: >- Policies allow for deep customization of the security of your Organization. They can be used to grant permissions or restrict usage of Users and Private Keys. The Policy Engine analyzes all of your Policies on each request to determine whether an Activity is allowed. See [Policy Overview](../managing-policies/overview) for more information - name: Wallets description: >- Wallets contain collections of deterministically generated cryptographic public / private key pairs that share a common seed. 0xkey securely holds the common seed, but only you can access it. In most cases, Wallets should be preferred over Private Keys since they can be represented by a mnemonic phrase, used across a variety of cryptographic curves, and can derive many addresses. Derived addresses can be used to create digital signatures using the corresponding underlying private key. See [Signing](./api#tag/Signing) for more information - name: Signing description: >- Signers allow you to create digital signatures. Signatures are used to validate the authenticity and integrity of a digital message. 0xkey makes it easy to produce signatures by allowing you to sign with an address. If 0xkey doesn't yet support an address format you need, you can generate and sign with the public key instead by using the address format `ADDRESS_FORMAT_COMPRESSED`. - name: Private Keys description: >- Private Keys are cryptographic public / private key pairs that can be used for cryptocurrency needs or more generalized encryption. 0xkey securely holds all private key materials for you, but only you can access them. The Private Key ID or any derived address can be used to create digital signatures. See [Signing](./api#tag/Signing) for more information - name: Private Key Tags description: >- Private Key Tags allow you to easily group and permission Private Keys through Policies. - name: Users description: >- Users are responsible for any action taken within an Organization. They can have ApiKey or Authenticator credentials, allowing you to onboard teammates to the Organization, or create API-only Users to run as part of your infrastructure. - name: User Tags description: >- User Key Tags allow you to easily group and permission Users through Policies. - name: Authenticators description: >- Authenticators are WebAuthN hardware devices, such as a Macbook TouchID or Yubikey, that can be used to authenticate requests. - name: API Keys description: >- API Keys are used to authenticate requests See our [CLI](https://github.com/0xkey-io) for instructions on generating API Keys - name: Activities description: >- Activities encapsulate all the possible actions that can be taken with 0xkey. Some examples include adding a new user, creating a private key, and signing a transaction. Activities that modify your Organization are processed asynchronously. To confirm processing is complete and retrieve the Activity results, these activities must be polled until that status has been updated to a finalized state: `COMPLETED` when the activity is successful or `FAILED` when the activity has failed - name: Consensus description: >- Policies can enforce consensus requirements for Activities. For example, adding a new user requires two admins to approve the request. Activities that have been proposed, but don't yet meet the Consensus requirements will have the status: `REQUIRES_CONSENSUS`. Activities in this state can be approved or rejected using the unique fingerprint generated when an Activity is created. - name: PublicApiService paths: /public/v1/query/get_authenticator: post: tags: - Authenticators summary: Get authenticator description: Get details about an authenticator. operationId: PublicApiService_GetAuthenticator requestBody: content: application/json: schema: $ref: '#/components/schemas/v1GetAuthenticatorRequest' required: true responses: '200': description: A successful response. content: application/json: schema: $ref: '#/components/schemas/v1GetAuthenticatorResponse' default: description: An unexpected error response. content: application/json: schema: $ref: '#/components/schemas/rpcStatus' components: schemas: v1GetAuthenticatorRequest: type: object properties: organizationId: type: string description: Unique identifier for a given organization. authenticatorId: type: string description: Unique identifier for a given authenticator. required: - organizationId - authenticatorId v1GetAuthenticatorResponse: type: object properties: authenticator: $ref: '#/components/schemas/v1Authenticator' required: - authenticator rpcStatus: type: object properties: code: type: integer format: int32 description: |- The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code]. message: type: string description: >- A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client. details: type: array items: $ref: '#/components/schemas/protobufAny' description: >- A list of messages that carry the error details. There is a common set of message types for APIs to use. description: >- The `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). Each `Status` message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the [API Design Guide](https://cloud.google.com/apis/design/errors). v1Authenticator: type: object properties: transports: type: array items: $ref: '#/components/schemas/v1AuthenticatorTransport' description: >- Types of transports that may be used by an Authenticator (e.g., USB, NFC, BLE). attestationType: type: string aaguid: type: string description: Identifier indicating the type of the Security Key. credentialId: type: string description: Unique identifier for a WebAuthn credential. model: type: string description: The type of Authenticator device. credential: $ref: '#/components/schemas/externaldatav1Credential' authenticatorId: type: string description: Unique identifier for a given Authenticator. authenticatorName: type: string description: Human-readable name for an Authenticator. createdAt: $ref: '#/components/schemas/externaldatav1Timestamp' updatedAt: $ref: '#/components/schemas/externaldatav1Timestamp' required: - transports - attestationType - aaguid - credentialId - model - credential - authenticatorId - authenticatorName - createdAt - updatedAt protobufAny: type: object properties: '@type': type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. As of May 2023, there are no widely used type server implementations and no plans to implement one. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. additionalProperties: {} description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } // or ... if (any.isSameTypeAs(Foo.getDefaultInstance())) { foo = any.unpack(Foo.getDefaultInstance()); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON ==== The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } v1AuthenticatorTransport: type: string enum: - AUTHENTICATOR_TRANSPORT_UNSPECIFIED - AUTHENTICATOR_TRANSPORT_BLE - AUTHENTICATOR_TRANSPORT_INTERNAL - AUTHENTICATOR_TRANSPORT_NFC - AUTHENTICATOR_TRANSPORT_USB - AUTHENTICATOR_TRANSPORT_HYBRID default: AUTHENTICATOR_TRANSPORT_UNSPECIFIED externaldatav1Credential: type: object properties: publicKey: type: string description: >- The public component of a cryptographic key pair used to sign messages and transactions. type: $ref: '#/components/schemas/v1CredentialType' required: - publicKey - type externaldatav1Timestamp: type: object properties: seconds: type: string title: Stringified int nanos: type: string title: Stringified int required: - seconds - nanos v1CredentialType: type: string enum: - CREDENTIAL_TYPE_UNSPECIFIED - CREDENTIAL_TYPE_WEBAUTHN_AUTHENTICATOR - CREDENTIAL_TYPE_API_KEY_P256 - CREDENTIAL_TYPE_RECOVER_USER_KEY_P256 - CREDENTIAL_TYPE_API_KEY_SECP256K1 - CREDENTIAL_TYPE_EMAIL_AUTH_KEY_P256 - CREDENTIAL_TYPE_API_KEY_ED25519 - CREDENTIAL_TYPE_OTP_AUTH_KEY_P256 - CREDENTIAL_TYPE_READ_WRITE_SESSION_KEY_P256 - CREDENTIAL_TYPE_OAUTH_KEY_P256 - CREDENTIAL_TYPE_LOGIN default: CREDENTIAL_TYPE_UNSPECIFIED securitySchemes: ApiKeyAuth: type: apiKey name: X-Stamp in: header AuthenticatorAuth: type: apiKey name: X-Stamp-WebAuthn in: header ````