Manage end users

Prompt:

Invite sam@example.com to my app, and show me who has signed up so far.

Also works:

  • "Suspend this user; they have been abusing the site."
  • "Our sign-in keys may have leaked. Make every user sign in again."
  • "Remove this person and everything about them from my app."
  • "Keep people signed in for a week instead of a month."

What your tool does

  • Reads your manifest. Where its services array declares no accounts service, it adds {"kind": "accounts"} and resubmits the manifest with submit_manifest, as the platform's add-service skill describes. The submission creates an end-user realm for each environment the application has: production's alone on an application with one environment.
  • Where you have not yet chosen the sign-in methods or who may sign up, follows Add sign-in to your app first.
  • Calls read_realm for the environment it is about to change, to learn the realm's current sign-in methods, creation policy, and limits.
  • Calls configure_realm for any other setting you ask for, such as a limit or the session length. It calls once for production, and once more with environment: "development" where the application has a development environment, because each call reaches one realm.
  • For Sign in with Apple, asks you for the Services ID, the team identifier, the key identifier, and the name the signing key is stored under. It passes the name in apple, never the key.
  • For each person to invite, calls issue_invitation with the address and gives you the URL it returns. The platform sends no mail, so you deliver the URL yourself.
  • When you ask who is invited or who has signed up, calls list_invitations and list_end_users, following next_cursor until it is null. For one person, it passes their address as email to list_invitations.
  • For a suspension, calls revoke_end_user with the identifier list_end_users returned; to restore a user, reinstate_end_user. Neither asks for a browser approval, because both are reversible-tier actions.
  • For a deletion, calls delete_end_user, gives you the approval link, and reads the outcome with read_pending_action after you approve in the browser. No tool approves in your place.
  • For a suspected key compromise, calls revoke_realm_keys for the environment, and tells you that every user of that realm must sign in again.
  • Writes the manifest change into your project. Where the backend needs the signed-in user, it also writes code that builds the Account package's client from TURNZERO_CLOUD_REALM_KEYS and calls verifySession on each request.
  • Asks you for each address to invite, where the prompt gives none. It reports every value it configured, every invitation URL, and every change it made to a user's standing.

What you need

  • For invitation-only sign-up, the email addresses to invite and a way to deliver each invitation URL yourself.

Before your AI starts

This section is for your AI tool: what it checks and gathers before it begins. You don't need to do these steps yourself.

  • A connected, signed-in tool (Connect your tool).
  • An application, whose identifier list_applications returns, and its manifest (Author the manifest). Step 1 adds the accounts service if the manifest lacks it.
  • For a work-account setting, the client secret stored by name at the application's scope, in the realm's environment (Add sign-in to your app covers work accounts).
  • For Sign in with Apple: a Services ID registered in your Apple developer account with the platform's callback as its return URL, and a Sign in with Apple key. Store the key's .p8 file by name at the application's scope, in the realm's environment.
  • For backend verification, the Account package at version 0.9.0 or later (Account).

Steps

1. Declare the accounts service

Declare {"kind": "accounts"} in the manifest's services array. The application then gets one end-user realm for each environment it has. Each realm keeps its own users and their sign-ins, apart from any other environment's realm, other applications, and the platform's own accounts. An application with one environment has one realm, production's, where testers and live users sign in alike. The Account client lets your backend verify end-user sessions. Add sign-in to your app explains how to choose the realm's sign-in methods and who may sign up.

A development realm can have at most ten end users, on every plan. A sign-in that would create an eleventh is refused 403 development_realm_full. An existing user can always sign in.

Deleting the application deletes every realm it has. delete_environment deletes the development realm alone, with its users, passkeys, and invitations, and leaves the application with one environment. The next create_environment creates a new development realm with the default sign-in methods, google, github, email, and passkey, and open creation, then applies the manifest's realm member where there is one. Under an invited audience it is invitation-only instead. If the old realm had other settings the manifest does not name, configure them again with configure_realm (step 4).

A passkey is a faster way to sign in by emailed code, so a realm offers passkey only beside email. Where it offers both, a user with no passkey is offered one after each sign-in by emailed code, and never after a Google or GitHub sign-in. A user who declines is offered one again after thirty days. Leaving passkey out of sign_in_methods turns off both that offer and passkey sign-in.

To remove email from sign_in_methods naming passkey, remove passkey with it. The realm keeps its users' passkeys, unused, until both routes return. A realm whose stored sign-in methods name passkey without email serves no passkey route, and the detail of read_realm says so.

Only a user who holds the emailed code can register a passkey. GET /__account/passkeys answers levers, the routes the user signs in with, so your page shows a passkey control only where levers includes email. It also answers passkey_registration, whose admitted is true where the user can register one and otherwise false, beside a remedy that tells the user how to add the code. For any other user the register routes answer 409 passkey_requires_email. To add the code, the user signs in by code once at the address their Google or GitHub sign-in verified.

2. Where sign-in runs

  • Sign-in runs on the application's own hostnames under the path /__account/: the production hostname, and the development hostname where the application has a development environment. On an application with one environment, the development hostname returns 404 realm_not_declared there. Add sign-in to your app describes the sign-in page and what a halted environment returns there.
  • A passkey works only on the hostname it was registered on. A development passkey therefore works only on the development hostname.

Renaming the application changes its hostnames, so a passkey registered before the rename stops working. The person signs in another way and registers a new passkey. The old one is then called stranded:

  • GET /__account/passkeys, under the person's session, lists it under stranded, apart from the passkeys that still work.
  • POST /__account/passkeys/remove-stranded with its credential_id removes it under that session, with no passkey prompt. It returns the remaining lists.
  • A passkey that still works is refused there with 409 passkey_not_stranded. Remove it the ordinary way, which asks for the passkey.

POST /__account/passkeys/remove-lost with its credential_id removes a passkey the person deleted from their device. It needs a session that signed in again in the last five minutes, as does registering a passkey outside the offer after a sign-in by emailed code. To sign in again from a live session, the person uses any of these routes:

  • GET /__account/start/<provider>?intent=reauth&return=app, which shows the provider's account picker and must return the same account; Sign in with Apple shows its own confirmation sheet instead, which counts the same;
  • a POST of intent=reauth and return=app to /__account/email/start, which emails a code to the person's own verified address;
  • POST /__account/passkeys/reauth/options, then POST /__account/passkeys/reauth, which confirms the person with another of their passkeys.

Where the person's verified address is at a domain that no longer publishes a mail server, that POST is refused email_domain_undeliverable on a page offering their provider and passkey routes instead.

The provider and emailed-code routes return to your application's root. A POST that sends the session cookie must come from your application's own origin. Your backend presents the session as a bearer token instead.

A passkey change can be undone for three days. GET /__account/passkeys lists each open change under revertible, and POST /__account/passkeys/revert with its change_id, under the same fresh sign-in, undoes it. The undo signs out the user's other sessions and opens the caller's session again.

After a passkey sign-in, the application's sign-in page tells the user's passkey provider which of their passkeys still work, counting a passkey whose removal can be undone until its three days end. Where a user picks a passkey the realm does not have and cannot restore, the page tells the provider it is unknown, and a provider that supports these signals can hide or delete it.

3. Passkey notices

When a user registers or removes a passkey, the platform emails a notice from donotreply@turnzero.ai to every address the user's identities have verified. The subject includes the hostname label, as the emailed-code message does. The notice says what changed and when. It says nothing is needed if the user made the change, and otherwise to sign in and review their passkeys. It contains no link and nothing the user typed. A user with no verified address is sent nothing.

The platform removes a passkey whose user holds no emailed-code sign-in, at the latest the next time it is used, and announces and records that removal the same way.

Notices have their own limits, which you cannot change and which do not count toward the emailed-code limits in Add sign-in to your app:

  • at most five notice messages an hour across the platform, and two notices an hour for one user or account;
  • a notice past the limit is queued and sent later, with several changes combined into one message;
  • a notice still queued after seven days is dropped.

The change is recorded in the realm's event log either way.

4. Configure the realm

Call configure_realm with the application's identifier and the environment. The manifest must already declare the accounts service. Options you leave out keep their values. The change takes effect at once, with no redeploy. Add sign-in to your app explains sign_in_methods, creation, and entra; the table below lists every setting.

The manifest's realm member can set sign_in_methods, creation, entra, and apple for each realm the application has instead. While it names one of them, configure_realm refuses to change it, manifest_owned_field, and you change the manifest. Author the manifest shows the member.

Argument Meaning
application The application whose end users you manage. Always name it for this task.
environment development or production; production when left out. Every realm action below takes it the same way, except revoke_realm_keys, which requires it. Configuring both realms takes two calls. On an application with one environment, development is refused 409 environment_not_created.
sign_in_methods The complete list of enabled sign-in methods, replacing the current one: any of google, github, passkey, email, entra, and apple. An empty list turns sign-in off. passkey is accepted only beside email.
creation open or invited. Under a manifest whose audience is invited, every realm the application has is invitation-only whatever this is set to, and open is refused. The entra route cannot be used with invitation-only creation, whether set here or by the audience. The apple route can, because Apple verifies the address.
limits.creation_ceiling The most users the realm will create, a positive integer; 1,000 by default.
limits.signin_starts_per_hour Sign-in starts allowed from one source address per hour, a positive integer; 30 by default. An IPv6 address counts as its /64 network, so all addresses of one IPv6 network share the limit.
limits.code_sends_per_hour Emailed codes sent to one address per hour; 5 by default, 30 at most.
invitation_days Days an invitation lasts, a positive integer; 14 by default.
session_days Days an end-user session lasts, from 1 to 30; 30 by default. Sessions opened after the call use the new value, and open sessions keep their expiry. A native app's session is extended by this many days at each refresh.
session_cap_days The most days a native app's session may run from its creation, from session_days to 730; 365 by default. Each refresh extends the session up to this cap, and the session expires there.
clients The native apps that sign in through this realm, at most ten, replacing the current list. Each has a client_id, its redirect_uris, and optional ios, android, google_client_ids, minimum_version, and update_url members. Declare both builds on the production realm, or the debug build on the development realm where the application has two environments. Sign in from a native app covers the declaration. Once minimum_version is raised, the realm refuses older versions of the app, and the response's warnings lists the versions in use that it refuses (Keep installed clients compatible).
entra For work-account sign-in: tenant as a GUID, client_id, and client_secret_name, the name of the secret stored at this application's scope. Configuring moves the secret into the realm vault, where it stays under that name. Rotate it by name as before. No upstream declaration can use it, and a name that an upstream of this application already uses is refused. After a change of client_secret_name, the earlier name stays in the realm vault. The app registration lists the address read_realm returns in callbacks.entra as a web redirect URI, exactly as returned. On the production platform it is https://turnzero.ai/auth/entra/callback. It is never your application's hostname, and both environments of every application use it. Add sign-in to your app names the two optional claims the registration adds.
apple For Sign in with Apple: services_id, the Services ID the web sign-in uses; team_id and key_id, each ten characters; and key_secret_name, the name of the stored signing key. Configuring moves the key into the realm vault, as for entra. The platform reads it only to sign Apple's client secret, and no upstream may use the name.

A workforce audience allows only the work-account route of its declared tenant, so it never includes apple. Sign-in methods or tenant settings that contradict the audience are refused. Supplying entra or apple prepares that route's settings; name the route in sign_in_methods to turn it on.

The apple route signs people in on the sign-in page with Apple's own pages. Apple posts its response back to the platform's callback, the address read_realm returns in callbacks.apple. The Services ID lists that address, exactly as returned, as its return URL, and the address's host as its domain. On the production platform it is https://turnzero.ai/auth/apple/callback. It is never your application's hostname, and both environments of every application use it.

A person may hide their address behind Apple's private relay, which the realm accepts as any verified address. A native app also exchanges Apple's own ID token (Sign in from a native app).

Without application, configure_realm and the three invitation actions address the platform's own accounts, which only platform staff may change. A call from you in that form is refused grant_required.

5. Read the realm

read_realm with application and environment returns the realm's sign-in methods, creation policy, limits, invitation and session lifetimes, the session cap, the declared native clients, user and session counts, and secret names. Each client includes versions_seen, the app versions its requests stated in the last day. It never returns secret values, and a native client has none. Where the audience narrows the sign-in methods the realm offers, its detail says so. Under the invited audience, creation still shows the configured value, and the detail says creation is invitation-only because of the audience.

6. The emailed code

A new realm offers the emailed-code route. Where a realm's sign_in_methods leave out email, add it back on that realm. Add sign-in to your app explains how a user signs in by code, the message the platform sends, and the limits on codes. Of those limits, only limits.code_sends_per_hour can be raised, up to 30. The limit on codes one realm sends in an hour follows the application's plan.

A user who signs in by code with an address their Google or GitHub identity already verified reaches the same user, with the new route added. list_end_users shows the routes each user has.

7. Invite, list, suspend, delete

Name application in each call below, and environment for the development realm. Identifiers are the values the matching list or creation action returned.

Action Other arguments Result and effect
issue_invitation email Returns invitation with id, email, a single-use url, and expires_at. The platform does not email it; deliver the URL yourself. Open creation needs no invitations. products is refused here.
revoke_invitation invitation Returns its identifier and revoked_at. A redeemed invitation is unchanged, and a revoked one keeps its first revocation time.
list_invitations Optional email, limit, cursor Returns invitations and next_cursor. Each row contains the identifier, address, times of issue, expiry, redemption, and revocation, redeemed_by, and a state: standing, redeemed, revoked, or expired. An email keeps only that address's invitations, ignoring case and surrounding spaces. The URL is never returned again.
list_end_users Optional limit, cursor Returns end_users and next_cursor. Each row contains id, created_at, standing, routes, email (which may be null), and email_verified. Where the address comes from the work-account tenant, the row also has email_source set to tenant, and email_verified is true only where the tenant's token stated the domain owner verified it.
revoke_end_user end_user Suspends the user and ends their sessions. Returns the identifier, the suspended standing, and sessions_ended. Within sixty seconds, the header x-turnzero-cloud-session has the value invalid on the ended sessions' requests. A backend's cached result from the verification route can stay valid until its cache time ends.
reinstate_end_user end_user Restores active standing so the user can sign in again. Ended sessions stay ended.
revoke_realm_keys environment (required) Revokes every signing key of the realm, for a suspected key compromise. Every user of the realm signs in again. Returns revoked, the revoked key identifiers, and keys_changed_at, which is null for a realm no one has signed in to yet.
delete_end_user end_user Needs the browser approval described in Management action tiers and approvals. Removes the user's identities, sessions, passkeys, and record, and returns deleted and the removal counts. The realm's event and usage records remain.

Both list actions return 50 rows by default and accept a limit from 1 to 200. Rows are ordered by creation time, then identifier. Pass next_cursor to fetch the next page; null means there is none. A cursor works only with the email filter that produced it. If the cursor's row no longer exists, start again from the first page. Separate requests do not share one snapshot.

Verifying an end user describes how a revocation and a key rotation reach the routers.

An invitation issued before an application rename contains the old hostname, which no longer responds. Its token still works. If you kept the URL, replace the hostname with the new one before sending it. Otherwise revoke the invitation and issue a new one.

8. Verify a session from the backend

A signed-in end user has the cookie __Host-turnzero_cloud_realm on the application's hostname. Treat its value as untrusted until your backend verifies it. Verifying an end user explains the token, the two ways to verify it, key rotation, and what a sign-out or a revocation does.

The Account package's makeVerifyClient, version 0.9.0 or later, provides verifySession(session). Which way it verifies depends on how you build it:

  • With keys. Give it the realm and the TURNZERO_CLOUD_REALM_KEYS setting, which each deploy and promote puts into the container. It verifies the token locally, then reads the router's header x-turnzero-cloud-session, passed as sessionHeader, to catch sign-outs and revocations. A session it admits locally gives a user with empty addresses and routes, because the token carries neither. Verifying an end user shows a second client, built without keys, that reads the verified email.
  • Without keys. It calls POST /accounts/v0/verify under the application's platform credential for every request. That credential belongs to one environment and selects that environment's realm, so a hosted backend needs nothing more.

A credential that belongs to no environment, an account-wide credential or a minted token, must name the environment. Send the header x-turnzero-cloud-environment or the body member environment:

  • Naming neither is refused 400 environment_required.
  • Under a platform credential, naming another environment is refused 403 environment_mismatch.
  • A header and a body member that name different environments are refused 403 environment_mismatch.

A development session is verified against the development realm only; a production session is refused there. An application with one environment has no development realm. There a local run's development platform credential verifies sessions of the production realm, the one its testers signed in on, and opens none.

A successful response gives the user, the realm, the verified addresses, the routes, the standing, the verification time, how long it may be cached, and the session's expiry. Each verification through the route is a metered backend action. A request verified locally is counted once, as the forwarded request. Account lists the client's options, results, and failures.

9. The audience

The manifest's audience sets who may reach the application, and the platform checks it before it forwards a request:

  • public needs no end-user sign-in.
  • invited needs an end-user session and accepts new users only by invitation.
  • workforce allows only signed-in users of the declared Microsoft Entra tenant.

One manifest covers every environment the application has, so the audience applies to each. Under invited and workforce, the paths the audience lists in session_free_paths take requests without a session, so a provider's webhook can reach them. The route at each listed path checks the provider's signature itself. Add sign-in to your app explains what each audience refuses, how a provider's webhook reaches a listed path, and what a public development hostname exposes.

Expected result

configure_realm returns a realm object with the realm identifier, the sign_in_methods, the creation policy, the three limits, invitation_days, session_days, and the entra and apple settings where they are set. It also returns callbacks, the platform's addresses that the entra registration and the apple Services ID list. Its detail says the realm uses the configuration from now on and that deploying code changes none of it. read_realm returns the same members, with counts of users and sessions and the secrets names. The sign-in page on the application's hostname shows the enabled sign-in methods.

issue_invitation returns the invitation's id, email, single-use url, and expires_at, and its detail says nothing was emailed. After the person uses the URL, list_end_users lists them with standing: "active" and the route they used. list_invitations shows the row as redeemed, with redeemed_by identifying that user.

revoke_end_user returns standing: "suspended" and sessions_ended; reinstate_end_user returns standing: "active". revoke_realm_keys returns the revoked key identifiers and keys_changed_at. delete_end_user returns a pending action with its approval link, and after you approve, read_pending_action shows deleted: true with the removal counts. In the backend, verifySession gives a verified request the user, the realm, the verified addresses, the routes, the standing, and the session's expiry.

Refusals

A refusal identifies the action, states the cause in its detail, and changes nothing. The management actions return the rows down to token_scope_refused. The application's sign-in path and the verification route return the rows from development_realm_full on, to the person signing in or to the backend. Where the manifest's realm member sets the credential, custody_entry_missing, custody_entry_unmovable, and name_bound_to_setting come from submit_manifest or create_environment instead. There the manifest stays recorded, and the remedy is the value stored again, a new name in the manifest, or the binding removed (Author the manifest).

Refusal Status Cause Remedy
invalid_request 400 A member is missing or malformed, such as an unknown route, entra.tenant not a GUID, limits.code_sends_per_hour over 30, or a stale cursor. The detail names it. Correct the named member and call again. For a stale cursor, start again from the first page.
passkey_not_sole_route 400 sign_in_methods, set by configure_realm or by the manifest's realm member, names passkey without email. A passkey is a faster way to sign in by emailed code, not a route on its own. Name email beside passkey, or leave passkey out. To remove email from sign_in_methods naming passkey, remove passkey with it; the realm's passkeys stay unused until both return.
no_such_application 404 application is not one of the account's applications. Use the identifier list_applications returns.
realm_not_declared 404 The manifest declares no accounts service, so the environment has no realm. Declare {"kind": "accounts"} in the manifest, resubmit it with submit_manifest, and call again.
environment_not_created 409 A realm action named development on an application with one environment, which has no development realm. A call to the verification route under a minted token or an account-wide credential that names development is refused the same way. Name production, or leave environment out. To give development a realm of its own, call create_environment.
no_such_end_user 404 end_user matches no user in that application's realm for that environment. Use an identifier from list_end_users for the same environment.
not_found 404 revoke_invitation gives an invitation the realm does not have. Use an identifier issue_invitation or list_invitations returned for the same realm.
grant_required 403 configure_realm or an invitation action was called without application. Name an application of your account.
custody_entry_missing 409 configure_realm named a client secret or Apple signing key that is not stored at the application's scope in the realm's environment. Store it with store_secret, as Store a secret describes, naming the application and environment, then call configure_realm again.
platform_minted_name 409 configure_realm named a credential the platform minted, credential-<application id>, database-<application id>, or issue-tracking-<application id>, as the client secret or the Apple signing key. Store the client secret or the key under your own name with store_secret, as Store a secret describes, and name that.
name_bound_to_upstream 409 configure_realm named, as the client secret or the Apple signing key, a secret that an upstream of this application uses. Store the client secret or the key under another name at the application's scope, and name that.
name_bound_to_push 409 configure_realm named, as the client secret or the Apple signing key, a secret that a push configuration of this application uses as a provider credential. Store the client secret or the key under another name at the application's scope, and name that.
name_bound_to_setting 409 configure_realm named a client secret or Apple signing key that a setting binds. The binding can be in the manifest's settings, the running copy of either environment, or a deploy, promote, or redeploy in flight to one. The detail names the setting and where it is bound. Store the client secret or the key under another name at the application's scope, and name that. A running copy keeps the binding until that environment's next deploy or promote of a manifest without it. A deploy, promote, or redeploy in flight keeps it until it ends.
realm_vault_unregistered 409 The platform has no realm vault set up for the application's hosting cell, so the client secret or the Apple signing key has nowhere to move. Report it to platform staff; you cannot fix it yourself.
custody_entry_unmovable 409 The realm vault already has an entry under the name of the client secret or the Apple signing key, live or soft-deleted, at another version. Nothing moved. Store the value under a new name at the application's scope, and name that.
invited_realm_refuses_work_account 409 configure_realm combined invitation-only creation, by creation: "invited" or by the invited audience, with the entra route. Leave entra out of sign_in_methods. Where the realm's own setting makes it invitation-only, set creation: "open".
creation_contradicts_audience 409 configure_realm named creation: "open" under the invited audience. Leave creation out or name invited. To allow sign-ins without an invitation, change the audience to public and resubmit the manifest.
manifest_owned_field 409 configure_realm would change a field the manifest's realm member names. The detail names each field. Change the member in the manifest and resubmit it with submit_manifest.
route_set_contradicts_audience 409 Under a workforce audience, configure_realm named a route such as email, or an entra.tenant other than the declared one. Name entra alone with the declared tenant, or change the audience and resubmit the manifest.
token_scope_refused 403 A token bound to one application named another application, or left out application. Use a token for this application or for the whole account, and name the application.
development_realm_full 403 A sign-in would create an eleventh user in a development realm. Delete a development user with delete_end_user and environment: "development". Production has no such limit.
realm_creation_ceiling 403 A sign-in would create more users than creation_ceiling, 1,000 by default. Raise limits.creation_ceiling with configure_realm, or delete users.
unrecognized_invitation 403 Under invitation-only creation, a first sign-in came without a valid invitation for that address. Issue a new invitation for the address the person signs in with, and deliver its URL.
user_suspended 403 A suspended user signed in. Restore the user with reinstate_end_user.
passkey_requires_email 409 A passkey registration, at /__account/passkeys/register/options or /__account/passkeys/register, named a user who holds no emailed-code sign-in. The user signs in by code once at the address their Google or GitHub sign-in verified, which adds the code to their account, and then registers the passkey.
key_revoked 401 The session's token was signed by a key revoke_realm_keys revoked; the verification route returns session_revoked. The person signs in again.
signin_rate_limited 429 A source address passed signin_starts_per_hour, or its share of emailed-code starts in the hour across the platform. Or the address's passkey autofill requests on an application's sign-in page passed 120 in the hour, a window of its own that counts no sign-in start. The detail gives the share's number. Wait for the hour to pass. Raise the first limit with limits.signin_starts_per_hour; the share cannot be raised.
signin_code_rate_limited 429 An emailed-code start passed one of the four code limits in Add sign-in to your app. Wait for the hour to pass. Only limits.code_sends_per_hour can be raised.
email_domain_undeliverable 400 An emailed-code start was for an address whose domain publishes no mail server, so no code could reach it. A reauthentication, which sends to the verified address, is refused the same way. The person corrects a typo in the address and starts again. Where the start posted no address, they sign in with another route.
environment_halted 503 The environment is halted. Resume it with resume_environment.
environment_required 400 The verification route was called under an account-wide credential or a minted token without naming the environment. Send the header x-turnzero-cloud-environment or the body member environment.
environment_mismatch 403 The verification call gives an environment other than the platform credential's, or its header and body member disagree. Give the credential's own environment, or none, and make the header and body member agree.
invalid_request 400 A request on the sign-in path, or to the verification route, contained a NUL character (U+0000) or an unpaired UTF-16 surrogate. Its detail, or the page a browser is shown, identifies the character rather than a member. Send the request again without the character.