@@ -1,144 +0,0 @@ GET / This entrypoint handles two things. If connecting with a browser, it redirects to the public stat page on llamanodes.com. If connecting with a websocket, it is rate limited by IP and routes to the Web3 RPC. POST / This entrypoint handles two things. If connecting with a browser, it redirects to the public stat page on llamanodes.com. If connecting with a websocket, it is rate limited by IP and routes to the Web3 RPC. GET /rpc/:rpc_key This entrypoint handles two things. If connecting with a browser, it redirects to the key's stat page on llamanodes.com. If connecting with a websocket, it is rate limited by key and routes to the Web3 RPC. POST /rpc/:rpc_key This entrypoint handles two things. If connecting with a browser, it redirects to the key's stat page on llamanodes.com. If connecting with a websocket, it is rate limited by key and routes to the Web3 RPC. GET /debug/:rpc_key Similar to GET /rpc/:rpc_key but includes additional debugging information. POST /debug/:rpc_key Similar to POST /rpc/:rpc_key but includes additional debugging information. GET /health If servers are synced, this gives a 200 "OK". If no servers are synced, it gives a 502 ":(" GET /fastest Similar to POST /fastest, but for websocket connections. POST /fastest Routes the request to the fastest server. POST /fastest/:rpc_key Routes the authenticated request to the fastest server. POST /versus This is an experimental endpoint for testing Web3 RPC performance. GET /versus Similar to POST /versus, but for websocket connections. POST /versus/:rpc_key This is an authenticated version of the /versus endpoint. GET /versus/:rpc_key Similar to POST /versus/:rpc_key, but for websocket connections. GET /fastest/:rpc_key Similar to POST /fastest/:rpc_key, but for websocket connections. GET /user/login/:user_address Displays a "Sign in With Ethereum" message to be signed by the address's private key. Once signed, continue to `POST /user/login` GET /user/login/:user_address/:message_eip Similar to `GET /user/login/:user_address` but gives the message in different formats depending on the eip. Wallets have varying support. This shouldn't be needed by most users. The message_eip should be hidden behind a small gear icon near the login button. Once signed, continue to `POST /user/login` Supported: EIP191 as bytes EIP191 as a hash EIP4361 (the default) Support coming soon: EIP1271 for contract signing POST /user/login?invite_code=SOMETHING_SECRET Verifies the user's signed message. The post should have JSON data containing "sig" (the signature) and "msg" (the original message). Optionally requires an invite_code. The invite code is only needed for new users. Once registered, it is not necessary. If the invite code and signature are valid, this returns JSON data containing "rpc_keys", "bearer_token" and the "user". "rpc_keys" contains the key and settings for all of the user's keys. If the user is new, an "rpc_key" will be created for them. The "bearer_token" is required by some endpoints. Include it in the "AUTHORIZATION" header in this format: "bearer :bearer_token". The token is good for 4 weeks and the 4 week time will reset whenever the token is used. The "user" just has an address at first, but you can prompt them to add an email address. See `POST /user` GET /user Checks the "AUTHORIZATION" header for a valid bearer token. If valid, display's the user's data as JSON. POST /user POST the data in the same format that `GET /user` gives it. If you do not want to update a field, do not include it in the POSTed JSON. If you want to delete a field, include the data's key and set the value to an empty string. Checks the "AUTHORIZATION" header for a valid bearer token. If valid, updates the user's data and returns the updated data as JSON. GET /user/balance Not yet implemented. Checks the "AUTHORIZATION" header for a valid bearer token. If valid, displays data about the user's balance and payments as JSON. POST /user/balance/:txid Rate limited by IP. Checks the ":txid" for a transaction that updates a user's balance. The backend will be watching for these transactions, so this should not be needed in the common case. However, log susbcriptions are not perfect and so it might sometimes be needed. Any authorized user can call this endpoint for any other user's transaction. GET /user/keys Checks the "AUTHORIZATION" header for a valid bearer token. If valid, displays data about the user's keys as JSON. GET /status Gives information about the system's status. GET /status/backups_needed Indicates if backups are needed for the system. GET /user/subuser Modifies (adds or removes) a specific subuser to a certain rpc_key. Takes in "rpc_key", "subuser_address", "new_status" (one of "upsert", "remove"), "new_role" (one of "owner", "admin", "collaborator") as query-parameters GET /user/subusers Retrieves all the subusers of a given user's rpc key, including their roles and addresses. Takes in "rpc_key" as a query-parameter GET /subuser/rpc_keys Retrieves RPC keys for the subuser (i.e. all RPC-keys that were shared with me, being the subuser) GET /user/deposits Retrieves the user's deposit history. GET /user/referral Fetches a user's referral link. GET /admin/increase_balance Increases the balance for a user. This is an administrative endpoint. Query parameters are: - "user_address" - "note" - "amount" (Decimal) Can only be called by admins GET /admin/modify_role Changes the role of a user. This is an administrative endpoint. Query parameters are: - "user_address" - "user_tier_title" Can only be called by admins GET /admin/imitate-login/:admin_address/:user_address Allows an admin to imitate a login as another user. Query parameters are: - "admin_address" - "user_address" This creates a login-message, you can use this message and login with the /admin/imitate-login/:admin_address/:user_address/:message_eip to imitate the user POST /admin/imitate-login Verifies the admin's imitation login request. (Similar to the login flow) POST /admin/imitate-logout Allows an admin to imitate a logout operation. POST or PUT /user/keys Checks the "AUTHORIZATION" header for a valid bearer token. If valid, allows the user to create a new key or change options on their keys. The POSTed JSON can have these fields: key_id: Option, description: Option, private_txs: Option, active: Option, allowed_ips: Option, allowed_origins: Option, allowed_referers: Option, allowed_user_agents: Option, The PUTed JSON has the same fields as the POSTed JSON, except for there is no `key_id` If you do not want to update a field, do not include it in the POSTed JSON. If you want to delete a string field, include the data's key and set the value to an empty string. `allowed_ips`, `allowed_origins`, `allowed_referers`, and `allowed_user_agents` can have multiple values by separating them with commas. `allowed_ips` must be in CIDR Notation (ex: "10.1.1.0/24" for a network, "10.1.1.10/32" for a single address). The spec technically allows for bytes in `allowed_origins` or `allowed_referers`, but our code currently only supports strings. If a customer needs bytes, then we can code support for them. `private_txs` are not currently recommended. If high gas is not supplied then they will likely never be included. Improvements to this are in the works Soon, the POST data will also have a `log_revert_trace: Option`. This will by the percent chance to log any calls that "revert" to the database. Large dapps probably want this to be a small percent, but development keys will probably want 100%. This will not be enabled until automatic pruning is coded. GET `/user/revert_logs` Checks the "AUTHORIZATION" header for a valid bearer token. If valid, fetches paginated revert logs for the user. More documentation will be written here once revert logging is enabled. GET /user/stats/aggregate Checks the "AUTHORIZATION" header for a valid bearer token. If valid, fetches paginated aggregated stats for the user. Pages are limited to 200 entries. The backend config can change this page size if necessary. Can be filtered by: `chain_id` - set to 0 for all. 0 is the default. `query_start` - The start date in unix epoch time. `query_window_seconds` - How many seconds to aggregate the stats over. `page` - The page to request. Defaults to 0. GET /user/stats/detailed Checks the "AUTHORIZATION" header for a valid bearer token. If valid, fetches paginated stats for the user with more detail. The request method is included. For user privacy, we intentionally do not include the request's calldata. Can be filtered the same as `GET /user/stats/aggregate` Soon will also be filterable by "method" POST /user/logout Checks the "AUTHORIZATION" header for a valid bearer token. If valid, deletes the bearer token from the proxy. The user will need to `POST /user/login` to get a new bearer token.