Skip to content

Allowing an application to connect

Check an application's identity and permissions before allowing access, and revoke it whenever you need to.

On this page

A personal token works well for a script you control. OAuth is safer for an application built by somebody else: the application asks Ebbe for access, you review the request, and your password is never shared with it.

You arrive here because a program sent you. Read four things before pressing Allow.

The name. This is whatever the application called itself. It is not verified and cannot be — anyone can claim to be anything. Treat it as a label, not as evidence.

The origin. For an application that identifies itself by a published address, Ebbe shows the host that address was fetched from. This one is evidence: DNS and TLS vouch for it, and an impostor can copy a name but cannot serve from somebody else’s hostname. If a name and an origin disagree — an application calling itself something familiar, served from a host you have never heard of — that disagreement is the whole warning.

The redirect host. Where you will be sent back to afterwards. The specification requires it be shown, and the reason is that it is where an authorization code would go.

A loopback warning, if the redirect goes to your own machine. That is normal for a desktop or command-line tool, and it carries an unavoidable caveat: any program on the machine could have bound that port and claimed to be the one you meant. Fine if you just started the tool yourself; worth a pause if you did not.

Then the permissions, as switches. Read is always granted and cannot be turned off — a connection that may do nothing at all is not a connection. Write you can refuse while still allowing the rest, and the application gets exactly what is left switched on, which may be less than it asked for.

Below, the account this would act as, so you can see you are signed in as who you think you are.

Deny is a real answer, and it is the right one whenever anything above does not add up.

What it can do afterwards

Only what you allowed. Never your password, never your address, never your account, never anything administrative — the same closed list as a personal token.

Its access expires every hour and is renewed silently in the background, for as long as the connection lasts, which is thirty days of use. Stop using it and it lapses on its own.

Getting back out

Account → API access → Connected applications. One row per connection: what it is called, what it may do, whether it is for the API or for MCP, and when you allowed it.

Remove access revokes it immediately — not at the end of the hour, not “within a day”. The next thing that application tries stops working.

A badge marks an application that registered itself rather than being entered by an administrator. This helps you distinguish automatically supplied application details from entries created by the operator.

Nothing is deleted when you revoke. Your budget is untouched; you are only withdrawing permission to reach it.

If nothing is listed

The section does not appear at all when you have never connected anything, which is the normal state. If you expected to see something and do not, the authorization probably never completed — go back to the application and try again.