Your account

Overview

Your account is the identity everything else hangs off: the name on your commits and comments, the person a merge request is assigned to, the owner of your tokens and of your personal namespace. From it you can change the username and email you are shown as, put a picture on it, look other people up by username or email address, see how many bytes your credentials have pulled this hour and today, and close the account when you are done with it.

You never sign up for it. Signing in for the first time creates the profile and a personal namespace for you, so the tasks below are all edits to something that already exists.

Before you start

How it works

Your account is created for you

The first time you authenticate, the platform derives a username from the local part of your email address, creates the profile, and creates a private top-level group with that same name — your personal namespace, the place your own repositories go when you do not pick a group. Every later sign-in re-checks both. The profile is verified before you are issued a session, so you can never hold a token without one; the namespace is created on a later sign-in if it did not go through at signup.

The derivation lowercases the local part, replaces everything that is not a letter, digit or hyphen with a hyphen, collapses runs of hyphens, and trims the ends. If the result is shorter than two characters it falls back to user-0. If the name is taken, a number is appended.

A username is also the path of your personal group, so it is checked like an organisation's name: a word Gitmoap keeps, a well-known organisation's name or one that looks like it, and a name an organisation gave up recently are never derived. A refused name falls back to user-0, numbered past whoever already has it, and if that is refused too, to user- followed by eight letters and digits. Owning the domain in your email address makes no difference — a domain unlocks a reserved name only for an organisation, never for a person. The Groups page lists what is kept back and why.

None of this is permanent — the derived name is a starting point, and changing it is one of the tasks below.

What is public, and what is not

Profiles are public because they have to be: a public repository's commit authors, its contributors and the participants on a merge request all have to resolve for a reader who has no account. The email lookup is the one read that is gated, because answering it confirms an address that the caller typed rather than resolving one the platform published, and that answer is worth something to somebody guessing addresses. A profile never carries the email address: reading one by id or by username returns the id, the username and the avatar, and only your own account (GET /user) shows your email.

Your picture is addressed by your email

An avatar is stored under a fingerprint of your email address, and the URL other pages load it from is computed from that same address. Two consequences follow, and both surprise people:

• Change your email and your picture appears to reset. The image is still there under the old address, but nothing points at it any more. Upload it again after the change.
• You have a picture address whether or not you upload anything. It is computed from your email address rather than stored, so an account that has never uploaded an image still resolves to the default image served at that address rather than to a blank.

Your id is the account's own, not your sign-in's

Your account's id is chosen by the platform when the account is created, and it never changes. It is not the identifier your identity provider uses for you, and it is not anything in your sign-in token — so the way you sign in can change without your account changing.

You can reach one account in more than one way: with a password, and through your organisation's single sign-on, for example. The first time a new way of signing in reaches the platform, it is joined to the account that already holds its email address — as long as that address has been verified, either by the code sent to it when you signed up or by your organisation's identity provider on a domain the organisation has proved it owns. A sign-in whose address has not been verified is refused rather than given a second account: verify the address and sign in again. Your repositories, memberships, tokens and history stay where they are, whichever way you came in.

Because your id is not in your sign-in token, a program that needs it asks for it — the call under Find out which account you are signed in as — rather than reading it out of the token.

Your username is a label; your id is the identity

Everything that stores a reference to you stores your id, so renaming yourself breaks nothing: your memberships, tokens, commits, reviews and work items all follow. What does not follow is anything spelled with the old name — a bookmarked profile link stops resolving, and your personal namespace keeps its original path. Renaming yourself and renaming that group are two separate acts; do the second one as well if you want them to match.

How to

Find out which account you are signed in as

Ask for your own account and you get a profile's fields plus the one only you see — the id, the username, the avatar and your email address — for whoever the credential belongs to. It is the way for a script or an app to learn your id: store that id, not the username, which you can change.

See your profile

A profile carries three things and no more: the id, the username and the avatar. There is no bio, no location and no pronoun field to fill in. The read takes an id and answers anybody, signed in or not.

Change your username or email

Both fields are edited together and both are unique across the platform, so a name somebody else already holds is refused rather than taken from them. Sending only one field changes only that field. A new username is checked the way an organisation's name is: a word Gitmoap keeps, a well-known organisation's name or one that looks like it, and a name an organisation gave up recently are refused, and no domain you own unlocks one. Sending the username you already have changes nothing and is never refused.

Changing the email on your profile does not change the address you sign in with — that one belongs to whoever authenticates you. It does change the address the email lookup resolves, the address your picture is keyed to, and the address commits are matched against when the platform works out which commits are yours.

Set a profile picture

Uploading is two calls, because the bytes never pass through the API. You ask for an upload link, declaring the file's exact size and type; you then send the file to the link you got back. The size you declared is bound into that link, so the upload has to be exactly that many bytes — a file that changed between the two steps is refused by storage rather than accepted and served wrong.

Remove your profile picture

Removing the image is its own action, and the only one — editing a profile can set the avatar field but has no way to clear it, so there is no second route to the same result. Removing the image does not blank your profile either: the address it was served from is unchanged, and the default image appears there instead.

Look somebody up by username

The lookup is exact, not a search — it resolves one name to one person, and answers 404 for anything else. Case does not matter: usernames are lowercase, and what you send is lowercased first, so Jane-Doe finds jane-doe. Use it to turn an @name into an id before you add somebody to a repository or assign them a work item.

Find somebody by their email address

The by-address lookup is the way to reach somebody who is not in the group you are working in — an external collaborator you want to add as a member, or a commit author you want to resolve to an account. It needs you to be signed in, and it matches the whole address exactly, ignoring case.

List the people in a group

The listing is scoped to one group — the organisation's top-level group in the normal case — and you have to be a member of it, at any level, because a group's roster is not public even though every individual profile is. The group's own member list (under Members) asks for more — Reporter or above — whatever the group's visibility. It returns that group's direct members only, so somebody who reaches a subgroup through a membership held higher up does not appear in the subgroup's list. Each row carries the id, username, email address and avatar. Ask for up to 100 rows at a time and follow the token in the response for the next page.

Check how much data you have pulled

Every clone, fetch, package download, release asset, archive, diff and log tail is charged against the identity that asked for it, in two windows at once: a short hourly burst allowance and a larger daily one. The self-view reports what you have spent in each and what the ceiling is, so you can tell a 429 on a clone from a network problem before you start debugging the wrong thing.

The windows roll: the hourly figure resets on the hour and the daily one at midnight UTC, and the response names the exact window each number covers so you can tell a reset from a wrong number. Budgets are per identity, not per token — every personal access token you sign requests with spends the same one, while a service account has its own.

Register a profile by hand

Signing in does this for you, so the only reason to call it is a credential that has authenticated but has no profile behind it. It takes a username and an email, and it always creates the profile for the caller — you cannot register somebody else. Calling it a second time is refused with 409, which is safe to treat as success. It is never refused because a version of the Terms is waiting for you: you accept the Terms as yourself, so the profile has to exist first.

Delete your account

Two checks stand between you and a deletion, and both are refusals rather than partial deletions:

• You cannot be the sole Owner of an organisation. If you are the only Owner of a top-level group, the request is refused and the response names every such group. Add another Owner, or delete the organisation, then try again. Being the last direct Owner of a subgroup or a repository does not block you — the organisation's Owners administer those. Expect this one on your first attempt: signing in created a private top-level group for you and made you its only Owner, so it is on the list until you hand it over or delete it.
• You cannot be credited as the creator or author of anything that still exists. Authorship is kept deliberately, so an account that created a group or a repository, or opened a merge request, is refused as well — this time with a 409 that names nothing, because what blocks it is a reference held by somebody else's record rather than a resource of yours. Delete or transfer what you created where you can. Past that, removing an identity that authored work is an anonymisation rather than a deletion, and it is not what this call does.

Reference

Every read here is addressed by an id, except the two lookups that exist precisely because you have a name or an address instead, and your own account and transfer view, which are always about the credential you called with. Every write below is self-only.

Limits

An avatar may be at most 5 MiB (5 242 880 bytes) per upload, and it must be one of image/png, image/jpeg, image/gif or image/webp. The limit is flat: no plan raises it, because an avatar is one image per account rather than something a busy account accumulates more of.

The size is checked before anything is uploaded. You declare the exact byte count when you ask for the upload link; a count of zero or one over the limit is refused with 400 there and then, and no link is issued — so an oversized image costs you one small request rather than a failed transfer. The declared size is then bound into the link itself, so an upload that does not send exactly that many bytes is rejected by storage. Uploading again replaces the image in place; there is no cap on how often you do it and no history of previous ones.

Outbound data is metered per identity in two windows — an hourly burst allowance and a daily one — and an exhausted budget answers 429 TOO_MANY_REQUESTS on the transfer that would have crossed it, never on the profile calls on this page. Your own transfer view reports the free-plan allowance, which is a floor rather than the number that will be enforced: a transfer is gated against the plan of the namespace you are pulling from, so pulling from one on a paid plan gives you a higher ceiling than the view shows. The usage figures beside it are exact. The view also reports its limits as the enforced values even where enforcement is switched off, so it answers what a transfer would cost you rather than what is switched on today.

Troubleshooting

Related