GraphQL API

Authorizer instance supports GraphQL natively and thus helps you share the common schema for your frontend applications.

You can play with GraphQL API using the GraphQL playground that comes with your Authorizer instance. Access GraphQL playground on the instance same as of your Authorizer instance URL.

Note super admin only queries / mutations starts with underscore _.

Table of Contents

Queries

meta

Query to get the meta information about your authorizer instance. eg, version, configurations, etc It returns Meta type with the following possible values

KeyDescription
versionAuthorizer version that is currently deployed
client_idIdentifier for your instance
is_google_login_enabledIt gives information if google login is configured or not
is_github_login_enabledIt gives information if github login is configured or not
is_facebook_login_enabledIt gives information if facebook login is configured or not
is_email_verification_enabledIt gives information if email verification is enabled or not
is_basic_authentication_enabledIt gives information, if basic auth is enabled or not
is_magic_link_login_enabledIt gives information if password less login is enabled or not
is_sign_up_enabledIt gives information if sign up is enabled or not

Sample Query

query {
meta {
version
client_id
is_google_login_enabled
is_github_login_enabled
is_facebook_login_enabled
is_email_verification_enabled
is_basic_authentication_enabled
is_magic_link_login_enabled
is_sign_up_enabled
}
}

session

Query to get the session information.

Note: Session information should be present as HTTP Cookie. If the information is not present or an invalid data is present it throws unauthorized error

This query can take a optional input params of type SessionQueryInput which includes roles to verify if the current token is valid for a given roles.

Request Params

KeyDescriptionRequired
rolesArray of string with valid rolesfalse
scopeList of openID scopes. If not present default scopes ['openid', 'email', 'profile'] is usedfalse

It returns AuthResponse type with the following keys.

Response

KeyDescription
messageError / Success message from server
access_tokenaccessToken that frontend application can use for further authorized requests
expires_intimestamp when the current token is going to expire, so that frontend can request for new access token
id_tokenJWT token holding the user information
refresh_tokenWhen scope includes offline_access, Long living token is returned which can be used to get new access tokens. This is rotated with each request
userUser object with all the basic profile information

Sample Query

query {
session(params: { roles: ["admin"] }) {
message
accessToken
expires_in
user {
id
email
roles
}
}
}

profile

Query to get the profile information of a user. It returns User type with the following keys.

Note: this is authorized route, so Authorization Header with bearer access token must be present.

KeyDescription
iduser unique identifier
emailemail address of user
given_namefirst name of user
family_namelast name of user
signup_methodsmethods using which user have signed up, eg: google,github
email_verifiedtimestamp at which the email address was verified
pictureprofile picture URL
rolesList of roles assigned to user
middle_namemiddle name of user
nicknamenick name of user
preferred_usernamepreferred username (defaults to email currently)
gendergender of user
birthdatebirthdate of user
phone_numberphone number of user
phone_number_verifiedif phone number is verified
created_attimestamp at which the user entry was created
updated_attimestamp at which the user entry was updated

Sample Query

query {
profile {
given_name
family_name
email
picture
roles
}
}

validate_jwt_token

Query to validate the given jwt token. This query needs input params of type ValidateJWTTokenInput

Request Parameters

KeyDescriptionRequired
token_typeType of token that needs to be validated. It can be one of access_token, refresh_token or id_tokentrue
tokenJwt token stringtrue
rolesArray of roles to validate jwt token forfalse

It returns ValidateJWTTokenResponse type with the following keys.

Response

KeyDescription
is_validBoolean indicating if given token was valid or not

Sample Query

query {
validate_jwt_token(token_type: "access_token", token: "some jwt token") {
is_valid
}
}

_users

Query to get all the _users. This query is only allowed for super admins. It returns array of users Users with below mentioned keys.

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer.admin as http only cookie.

{
"x-authorizer-admin-secret": "ADMIN_SECRET"
}

It can take optional params input of type PaginatedInput with following keys

Request Params

KeyDescriptionRequiredDefault
pageNumber of page that you wantfalse1
limitNumber of rows that you wantfalse10

Sample Query

query {
_users(params: {
pagination: {
page: 2
limit: 10
}
}) {
pagination: {
offset
total
page
limit
}
users {
id
given_name
family_name
email
picture
roles
}
}
}

_verification_requests

Query to get all the _verification_requests. This query is only allowed for super admins. It returns array of verification requests [VerificationRequest!]! with following keys.

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

{
"x-authorizer-admin-secret": "ADMIN_SECRET"
}

It can take optional params input of type PaginatedInput with following keys

Request Params

KeyDescriptionRequiredDefault
pageNumber of page that you wantfalse1
limitNumber of rows that you wantfalse10

Sample Query

query {
_verification_requests(params: { pagination: { limit: 10, page: 2 } }) {
pagination {
limit
offset
page
}
verification_requests {
id
token
email
expires
identifier
}
}
}

_admin_session

Query to get admin session for dashboard

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

{
"x-authorizer-admin-secret": "ADMIN_SECRET"
}
KeyDescription
messageSuccess response message from server

Sample Query

query {
_admin_session {
message
}
}

_env

Query to get all the environment variables.

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

{
"x-authorizer-admin-secret": "ADMIN_SECRET"
}

All the environment variables values can be obtained using this this.

Sample Query

query {
_env {
DATABASE_TYPE
DATABASE_URL
DATABASE_NAME
CLIENT_ID
CLIENT_SECRET
...
}
}

_webhook

Query to get webhook by its identifier. This query is allowed for admins only. It accepts params of type WebhookRequest with following keys and returns Webhook

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
idIdentifier of the webhooktrue

Response

KeyDescription
idIdentifier of the webhook
event_nameEvent for which the webhook will be executed
endpointEndpoint that is to be called
enabledBoolean to know if webhook is enabled or disabled
headersJSON key, value pair object with the set of headers to be sent for webhook
created_atTime at which the webhook entry was created
updated_atTime at which the webhook entry was updated

Sample Query

query {
_webhook(params: { id: "123-adfa-123412-asdfasda" }) {
id
event_name
}
}

_webhooks

Query to get list of webhooks. This query is allowed for admins only.

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

It can take optional params input of type PaginatedInput with following keys

Request Params

KeyDescriptionRequiredDefault
pageNumber of page that you wantfalse1
limitNumber of rows that you wantfalse10

Response

It returns response of type Webhooks with following keys

KeyDescription
paginationobject with limit, page, offset & total value
webhooksList of webhook with params mentioned here

Sample Query

_webhooks(params: {limit: 10, page: 1}) {
pagination {
limit
offset
total
}
webhooks {
id
event_name
endpoint
}
}

_webhook_logs

Query to get list of webhook logs. This query is allowed for admins only.

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

It can take optional params input of type ListWebhookLogRequest with following keys

Request Params

KeyDescriptionRequiredDefault
paginationPagination object with limit & pagefalse{limit: 10, page: 1}
webhook_idIdentifier for the webhookfalsenull

Response

It returns response of type WebhookLogs with following keys

KeyDescription
paginationobject with limit, page, offset & total value
webhook_logsList of webhook log (id, http_status, request, response, webhook_id, created_at, updated_at)

Sample Query

_webhook_logs(params: {
pagination: {
limit: 10
}
webhook_id: "test"
}) {
pagination {
limit
offset
total
}
webhook_logs {
id
http_status
request
response
webhook_id
}
}

_email_templates

Query to get list of email templates. This query is allowed for admins only.

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

It can take optional params input of type PaginatedInput with following keys

Request Params

KeyDescriptionRequiredDefault
pageNumber of page that you wantfalse1
limitNumber of rows that you wantfalse10

Response

It returns response of type EmailTemplates with following keys

KeyDescription
paginationobject with limit, page, offset & total value
email_templatesList of email template

Sample Query

_email_templates(params: {limit: 10, page: 1}) {
pagination {
limit
offset
total
}
webhooks {
id
template
event_name
created_at
updated_at
}
}

Mutations

signup

A mutation to signup users using email and password. It accepts params of type SignUpInput with following keys as parameter

Request Params

KeyDescriptionRequired
emailEmail address of usertrue
passwordPassword that user wants to settrue
confirm_passwordValue same as password to make sure that its user and not robottrue
given_nameFirst name of the userfalse
family_nameLast name of the userfalse
pictureProfile picture URLfalse
rolesList of roles to be assigned. If not specified DEFAULT_ROLE value of env will be usedfalse
middle_namemiddle name of userfalse
nicknamenick name of userfalse
gendergender of userfalse
birthdatebirthdate of userfalse
phone_numberphone number of userfalse
scopeList of openID scopes. If not present default scopes ['openid', 'email', 'profile'] is usedfalse
redirect_uriURI where the user should be redirected after signup verificationfalse

This mutation returns AuthResponse type with following keys

Response

KeyDescription
messageSuccess / Error message from server
access_tokenToken that can be used for further authorized requests. This is only returned if DISABLE_EMAIL_NOTIFICATION is set to true in environment variables
expires_inTimestamp when the access Token will expire so that frontend can request new token. This is only returned if DISABLE_EMAIL_NOTIFICATION is set to true in environment variables
userUser object with its profile keys mentioned above. This is only returned if DISABLE_EMAIL_NOTIFICATION is set to true in environment variables

Sample Mutation

mutation {
signup(
params: { email: "foo@bar.com", password: "test", confirm_password: "test" }
) {
message
}
}

login

A mutation to login users using email and password. It accepts params of type LoginInput with following keys as parameter

Request Params

KeyDescriptionRequired
emailEmail address of usertrue
passwordPassword that user wants to settrue
rolesRoles to login withfalse
scopeList of openID scopes. If not present default scopes ['openid', 'email', 'profile'] is usedfalse

This mutation returns AuthResponse type with following keys

Response

KeyDescription
messageSuccess / Error message from server
access_tokenaccessToken that frontend application can use for further authorized requests
expires_intimestamp when the current token is going to expire, so that frontend can request for new access token
id_tokenJWT token holding the user information
refresh_tokenWhen scope includes offline_access, Long living token is returned which can be used to get new access tokens. This is rotated with each request
userUser object with its profile keys mentioned above.

Sample Mutation

mutation {
login(params: { email: "foo@bar.com", password: "test" }) {
user {
email
given_name
family_name
picture
roles
}
accessToken
expires_in
message
}
}

magic_link_login

A mutation to perform password less login. It accepts params of type MagicLinkLoginInput with following keys as parameter. When the operation is successful, it sends user email with magic link to login. This link is valid for 30 minutes only.

Note: You will need a SMTP server with an email address and password configured as authorizer environment using which system can send emails.

Request Params

KeyDescriptionRequired
emailEmail address of usertrue
rolesRoles to login withfalse
scopeList of openID scopes. If not present default scopes ['openid', 'email', 'profile'] is usedfalse
redirect_uriURL where user should be redirect after email verificationfalse
stateUnique string used to verify OAuth statefalse

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
magic_link_login(params: { email: "foo@bar.com" }) {
message
}
}

logout

Mutation to logout user. This is authorized request and accepts token as HTTP cookie or Authorization header with Bearer token. This action clears the session data from server. It returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
logout {
message
}
}

update_profile

Mutation to update profile of user. It accepts params of type UpdateProfileInput with following keys as parameter

Note: this is authorized route and Authorization with bearer access token is required

Request Params

KeyDescriptionRequired
given_nameNew first name of the userfalse
family_nameNew last name of the userfalse
emailNew email of th user. This will logout the user and send the new verification mail to user if DISABLE_EMAIL_NOTIFICATION is set to falsefalse
old_passwordIn case if user wants to change password they need to specify the older password here. In this scenario newPassword and confirmNewPassword will be required.false
newPasswordNew password that user wants to set. In this scenario old_password and confirmNewPassword will be requiredfalse
confirmNewPasswordValue same as the new password to make sure it matches the password entered by user. In this scenario old_password and newPassword will be requiredfalse
middle_nameNew middle name of userfalse
nicknameNew nick name of userfalse
genderNew gender of userfalse
birthdateNew birthdate of userfalse
phone_numberNew phone number of userfalse

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
update_profile(params: { given_name: "bob" }) {
message
}
}

verify_email

Mutation to verify email address of user. It accepts params of type VerifyEmailInput with following keys as parameter

Request Params

KeyDescriptionRequired
tokenToken sent for verifying usertrue

This mutation returns AuthResponse type with following keys

Response

KeyDescription
messageSuccess / Error message from server
access_tokenaccessToken that frontend application can use for further authorized requests
expires_intimestamp when the current token is going to expire, so that frontend can request for new access token
id_tokenJWT token holding the user information
refresh_tokenWhen scope includes offline_access, Long living token is returned which can be used to get new access tokens. This is rotated with each request
userUser object with its profile keys mentioned above.

Sample Mutation

mutation {
verify_email(params: { token: "some token" }) {
user {
email
given_name
family_name
picture
}
accessToken
expires_in
message
}
}

resend_verify_email

Mutation to resend verification email. This is helpful if user does not receive verification email. It accepts params of type ResendVerifyEmailInput with following keys as parameter

Request Params

KeyDescriptionRequired
emailEmail on which the verification email is not receivedtrue
identifierWhich type of verification request it is. basic_auth_signup, update_email, forgot_password are the supported identifierstrue

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
resend_verify_email(
params: { email: "foo@bar.com", identifier: "basic_auth_signup" }
) {
message
}
}

forgot_password

Mutation to reset the password in case user have forgotten it. For security reasons this is 2 step process, we send email to the registered and then the are redirect to reset password url through the link in that email. In the first step, it accepts params of type ForgotPasswordInput with following keys as parameter

Request Params

KeyDescriptionRequired
emailEmail for which password needs to be changedtrue

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
forgot_password(params: { email: "foo@bar.com" }) {
message
}
}

reset_password

Mutation to reset the password. For security reasons this is 2 step process, we send email to the registered and then the are redirect to reset password url through the link in that email. In the second step, it accepts params of type ResetPasswordInput with following keys as parameter

Request Params

KeyDescriptionRequired
tokenToken sent via email in step 1true
passwordNew password that user wants to settrue
confirm_passwordSame as password just to make sure the values match and is entered by humantrue

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
reset_password(
params: { token: "some token", password: "test", confirm_password: "test" }
) {
message
}
}

revoke

Mutation to revoke refresh token.

Request Params

KeyDescriptionRequired
refresh_tokenRefresh token that needs to revokedtrue
mutation {
revoke(params: { refresh_token: "token" }) {
message
}
}

_admin_signup

Mutation to signup administrator. This only works if ADMIN_SECRET env is not set. It accepts params of type AdminSignupInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

KeyDescriptionRequired
admin_secretSecure secret with >= 6 characterstrue

This mutation returns Response type with message

Sample Mutation

mutation {
_admin_signup(params: { admin_secret: "some string" }) {
message
}
}

_admin_login

Mutation to login administrator. It accepts params of type AdminLoginInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

KeyDescriptionRequired
admin_secretSecure secret with >= 6 characterstrue

This mutation returns Response type with message

Sample Mutation

mutation {
_admin_login(params: { admin_secret: "some string" }) {
message
}
}

_admin_logout

Mutation to logout administrator. It does not have any params

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

This mutation returns Response type with message

Sample Mutation

mutation {
_admin_logout {
message
}
}

_update_env

Mutation to update environment variables. It accepts params of type UpdateEnvInput with keys present in environment variables

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

This mutation returns Response type with message

Sample Mutation

mutation {
_update_env(params: { DATABASE_URL: "data.db", DATABASE_TYPE: "sqlite" }) {
message
}
}

_update_user

Mutation to update the profile of users. This mutation is only allowed for super admins. It accepts params of type UpdateUserInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

{
"x-authorizer-admin-secret": "ADMIN_SECRET"
}

Request Params

KeyDescriptionRequired
idID of user to be updatedtrue
emailNew email address of userfalse
given_nameUpdated first name of userfalse
family_nameUpdated last name of userfalse
pictureUpdated picture url of userfalse
rolesSet of new roles for a given userfalse
middle_nameNew middle name of userfalse
nicknameNew nick name of userfalse
genderNew gender of userfalse
birthdateNew birthdate of userfalse
phone_numberNew phone number of userfalse

This mutation returns User type with update values

Sample Mutation

mutation {
_update_user(
params: { id: "20", given_name: "Bob", roles: ["user", "admin"] }
) {
id
given_name
roles
createdAt
updatedAt
}
}

_delete_user

Mutation to delete user. This mutation is only allowed for super admins. It accepts params of type DeleteUserInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
emailEmail of user that needs to be removed from platformtrue

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_delete_user(params: { email: "foo@bar.com" }) {
message
}
}

_invite_members

Mutation to invite members. This mutation is only allowed for super admins. It accepts params of type InviteMemberInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
emailsList of emails that needs to be invited on platformtrue
redirect_uriURI to which user should be redirected when they click on invitation link. Defaults to authorizer app pagefalse

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_invite_members(params: { emails: ["foo@yopmail.com"] }) {
message
}
}

_revoke_access

Mutation to revoke access of a given user. This mutation is only allowed for super admins. It accepts params of type UpdateAccessInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
user_idId of user whose access is to be revokedtrue

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_revoke_access(params: { user_id: "test" }) {
message
}
}

_enable_access

Mutation to enable access of a given user whose access revoked earlier. This mutation is only allowed for super admins. It accepts params of type UpdateAccessInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
user_idId of user whose access is to be enabledtrue

This mutation returns Response type with following keys

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_enable_access(params: { user_id: "test" }) {
message
}
}

_generate_jwt_keys

Mutation to generate new jwt keys based on given jwt algorithm. This mutation is only allowed for super admins. It accepts params of type GenerateJWTKeysInput with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
typeJWT algorithm for which keys are to be generate. It supports HS256,HS384,HS512,RS256,RS384,RS512,ES256,ES384,ES512true

This mutation returns GenerateJWTKeysResponse type with following keys

Response

KeyDescription
secretIn case of HMAC algorithm it returns secret
public_keyIn case of RSA / ECDSA it returns public key string
private_keyIn case of RSA / ECDSA it returns private key string

Sample Mutation

mutation {
_generate_jwt_keys(params: { type: "RS256" }) {
public_key
private_key
}
}

_test_endpoint

Mutation to test webhook endpoint. This mutation is allowed for admins only. It accepts params of type TestEndpointRequest with following keys and returns TestEndpointResponse

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
event_nameName of event for which webhook should be called. Currently, supports user.login, user.created, user.signup, user.access_revoked, user.access_enabled, user.deleted events only. This is a unique field, means you can have one webhook for each event.true
endpointEndpoint that needs to be called for a given eventtrue
headersJSON of key, value pair which are extra HTTP headers to be sent. Default header added is content-type: application/jsonfalse

It sends following data to your webhook with POST method

{
"event_name": "user.login", // whatever is called
"user": {}, // [user object](https://docs.authorizer.dev/core/graphql-api#profile)
"auth_recipe": "basic_auth" // optional key sent for signup / login event to describe the login/signup method used.
}

Response

KeyDescription
http_statusHTTP status integer from the webhook endpoint
responseJSON response sent by webhook

Sample Mutation

mutation {
_test_endpoint(params: {
event_name: "user.login",
endpoint: "https://foo.com/webhook",
headers: {"Authorization": "Basic test"}
}) {
http_status
response
}
}

_add_webhook

Mutation to add webhook. This mutation is allowed for admins only. It accepts params of type AddWebhookRequest with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
event_nameName of event for which webhook should be called. Currently, supports user.login, user.created, user.signup, user.access_revoked, user.access_enabled, user.deleted events only. This is a unique field, means you can have one webhook for each event.true
endpointEndpoint that needs to be called for a given eventtrue
enabledBoolean to state if the webhook is enabled or disabledtrue
headersJSON of key, value pair which are extra HTTP headers to be sent. Default header added is content-type: application/jsonfalse

It sends following data to your webhook with POST method

{
"event_name": "user.login", // whatever is called
"user": {}, // [user object](https://docs.authorizer.dev/core/graphql-api#profile)
"auth_recipe": "basic_auth" // optional key sent for signup / login event to describe the login/signup method used.
}

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_add_webhook(params: {
event_name: "user.login",
endpoint: "https://foo.com/webhook",
enabled: true,
headers: {"Authorization": "Basic test"}
}) {
message
}
}

_update_webhook

Mutation to update webhook. This mutation is allowed for admins only. It accepts params of type UpdateWebhookRequest with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
idIdentifier of the webhooktrue
event_nameName of event for which webhook should be called. Currently, supports user.login, user.created, user.signup, user.access_revoked, user.access_enabled, user.deleted events only. This is a unique field, means you can have one webhook for each event.false
endpointEndpoint that needs to be called for a given eventfalse
enabledBoolean to state if the webhook is enabled or disabledfalse
headersJSON of key, value pair which are extra HTTP headers to be sent. Default header added is content-type: application/jsonfalse

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_update_webhook(params: {
id: "123-adfa-123412-asdfasda",
event_name: "user.login",
endpoint: "https://foo.com/webhook",
enabled: true,
headers: {"Authorization": "Basic test"}
}) {
message
}
}

_delete_webhook

Mutation to delete webhook. This mutation is allowed for admins only. It accepts params of type WebhookRequest with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
idIdentifier of the webhooktrue

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_delete_webhook(params: { id: "123-adfa-123412-asdfasda" }) {
message
}
}

_add_email_template

Mutation to add email template that will be used while sending emails. This mutation is allowed for admins only. It accepts params of type AddEmailTemplateRequest with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
event_nameName of event for which email template should be called. Currently, supports basic_auth_signup, magic_link_login, update_email, forgot_password events only. This is a unique field, means you can have one template for each event.true
templateHTML template that will be used while sending emailstrue

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_add_email_template(
params: { event_name: "user.login", template: "hello world" }
) {
message
}
}

_update_email_template

Mutation to update email template. This mutation is allowed for admins only. It accepts params of type UpdateEmailTemplateRequest with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
idIdentifier of the email templatetrue
event_nameName of event for which email template should be called. Currently, supports basic_auth_signup, magic_link_login, update_email, forgot_password events only. This is a unique field, means you can have one template for each event.false
templateHTML template that will be used while sending emailsfalse

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_update_email_Template(
params: {
id: "123-adfa-123412-asdfasda"
event_name: "update_email"
template: "Welcome back!"
}
) {
message
}
}

_delete_email_template

Mutation to delete email template. This mutation is allowed for admins only. It accepts params of type DeleteEmailTemplateRequest with following keys

Note: the super admin query can be access via special header with super admin secret (this is set via ENV) or authorizer-admin as http only cookie.

Request Params

KeyDescriptionRequired
idIdentifier of the email templatetrue

Response

KeyDescription
messageSuccess / Error message from server

Sample Mutation

mutation {
_delete_email_template(params: { id: "123-adfa-123412-asdfasda" }) {
message
}
}