URnetwork API: Other

Upload a log file for the caller, associated with a feedback id. The request body is the raw log file content, streamed to storage. Note the {clientId} path segment is actually the feedback id the log is attached to.

Buy a sku inline. Without an X-PAYMENT header the answer is 402 carrying the payment terms; the agent signs them and retries the SAME request with the signed payment in X-PAYMENT, which is settled and granted. The receipt is returned both as the body and in the X-PAYMENT-RESPONSE header. Requires a network session.

The same 402 round trip is also carried inline by POST /network/auth-client, where an agent meets the plan's concurrent-client limit.

The Stripe webhook. Authenticated by the Stripe-Signature header over the raw body, verified before the event is parsed; there is no URnetwork JWT. The subscription is granted here, never by the client. Only the fields the server reads are listed; Stripe sends a much larger event.

The Coinbase Commerce webhook, authenticated by the X-CC-Webhook-Signature HMAC over the raw body with the shared secret, checked before the event is parsed. Only the fields the server reads are listed.

The Play RTDN push, delivered through Google Pub/Sub and authenticated as a Pub/Sub push -- the Authorization bearer is verified as a Google-signed OIDC token before the body is parsed. The notification itself is base64 inside message.data; the server decodes it and credits the renewal through the same advisory-lock gate as /subscription/verify-play-purchase and the payment reconciler.

The Helius webhook for USDC transfers on Solana. Authenticated by the configured shared secret in the Authorization header, checked before the body is parsed. The server matches a transfer to a payment intent by the Solana Pay reference among the transaction's account keys, or by the memo text, and credits the plan or the data pack (see /solana/payment-intent and /pay/data/solana-intent).

The body is Helius's own enhanced-transaction ARRAY, not a wrapped object. One delivery carries a batch, and a customer's payment can sit behind any number of unrelated transfers, so a transaction that does not match is skipped rather than returned on. A per-transaction failure is reported only after the whole batch is examined, as a non-2xx, so Helius redelivers everything; the already-credited intents are no-ops on the retry.

The Circle programmable-wallets notification, authenticated by the X-Circle-Signature ECDSA signature over the raw body under the key named by X-Circle-Key-Id. Deprecated; it is the same handler as POST /account/circle-wallet.

The App Store Server Notification V2 endpoint. The envelope carries one field, signedPayload, a compact JWS; unknown envelope fields are rejected and the body is capped at 1 MiB.

Every JWS -- the notification and the signed transaction and renewal info nested inside it -- is verified independently: ES256, a three-certificate x5c chain carrying Apple's leaf and intermediate policy extensions, terminating at a PINNED Apple root, with the chain judged at the payload's own signedDate. The outer notification must additionally be within 24 hours old and no more than 5 minutes in the future, and its bundle id, environment and app Apple id must match this app; the nested payloads must match the outer notification. A SUBSCRIBED, DID_RENEW or EXPIRED notification without signed transaction info is rejected.

Anything that fails is a 400 with no detail. A verified notification answers 200 with an empty object, whether or not it changed anything.

When paying for a subscription with Stripe, create the payment intents, ephemeral key, and customer id needed to complete the purchase.

Create a Stripe customer portal URL for the caller to manage their subscription.

Buy a data pack with a card without signing in (the ur.io buy-data page). Starts a hosted Stripe checkout and returns the url to send the customer to. To pay with USDC on Solana use /pay/data/solana-intent.

With network_name, the data is applied to that network by the payment webhook as soon as the payment confirms, and the customer is emailed a note that the data is on the network (the code is included, already applied). The name is matched case-insensitively and exactly; an unknown name returns error.message "No network named ".

Without network_name, the customer receives a data code by email, as before. Stripe collects the email on its checkout page when email is not given.

The success url is the configured checkout success url plus item= and, when applying to a network, network=. Unauthenticated, per-ip rate limited. Errors are returned as error.message with a 200.

Whether a network with exactly this name exists, for the buy-data page. Matched the same way /pay/data/checkout resolves network_name (case-insensitive, exact). Unlike /auth/network-check, which is a sign-up similarity check, a name within a few characters of an existing one is NOT reported as existing. Returns only the canonical name, no id. Unauthenticated, per-ip rate limited.

Buy a data pack with USDC on Solana, without signing in or giving an email: the data goes straight to the network named by network_name (matched like /pay/data/network-lookup). Records the payment intent and returns the exact amount_usd to send in USDC. The client generates reference (a Solana Pay reference: a fresh base58 public key) and either opens a Solana Pay url carrying it, or shows the buyer the receiving address, the amount and memo (which is the reference) to send by hand from any wallet or exchange. The Helius webhook (/pay/solana) matches the transfer by the reference among the transaction's account keys OR by the memo text, then lands the data on the network (data only, valid for one year, no Pro) and emails the network's admin when their login is an email.

The intent expires after 24 hours (expires_at); a payment that arrives late still credits as long as the intent has not been swept. A reused reference, an unknown item or an unknown network return error.message with a 200. Unauthenticated, per-ip rate limited.

The state of a data pack payment started with /pay/data/solana-intent, for the buy-data page to poll while it waits: pending until the USDC transfer is credited, paid once the data is on the network, expired when the intent passed expires_at unpaid, unknown for a reference that is not a data pack intent (plan intents made by a signed-in wallet are not reported here). Unauthenticated, per-ip rate limited.

Create a Stripe Checkout Session for a subscription or data pack.

ui_mode selects which shape the result carries -- a single Stripe session cannot produce both:

• "hosted" (the default, so existing callers are unchanged): returns checkout_url, which the client opens in a browser. - "embedded": returns client_secret and publishable_key, which the client uses to mount Stripe Embedded Checkout inline (the desktop apps load ur.io/checkout in a webview with these).

The subscription is granted by the invoice.paid webhook, never by the client; the client only polls /subscription/balance afterwards.

One step of the validator's routing-verification protocol. The route accepts two body shapes:

• SEED starts a new trail through the validator-chosen entry provider.
• EXTEND claims the pending assigned hop of an active trail.

The request must egress from the provider being claimed - the server resolves the hop from the request source IP, never from the body. Authentication is the protocol's own Ed25519 signatures (over the canonical binary messages, not the JSON), not a JWT. A non-final step returns the assign result (the server's signed commitment to the next hop); the final step returns status "complete" and the published proof.

Attach the caller's subnet coldkey - the ss58 address that pool payouts are claimable by. Proof of key possession is required: message is the single-use challenge issued by POST /auth/wallet-challenge for blockchain TAO and signature is the coldkey's sr25519 signature over it. client_id scopes the wallet to one provider client (a client-scoped JWT selects its own client). Banned addresses are rejected. Not retroactive: the wallet applies from the next committed epoch's leaf set. This wallet is deliberately separate from the account payout wallet.

Checks an address before it is attached: ss58 syntax with the Bittensor prefix, the operator ban list, and whether the account exists on the subtensor chain. When the chain cannot be reached the result reports exists_on_chain: true with a message, so an outage never blocks a user. No authentication; chain lookups are rate limited per source address.

Store a device's consent for a fleet binding (WHITEPAPER 11.4): the canonical binding payload and the client's Ed25519 signature over its keccak256 digest, optionally with the head hotkey's sr25519 signature. When both signatures verify the response carries the bindFleetMember calldata for the operator to submit from their own key. The server never submits on chain.

Upload the exact bytes of one attempt object. Requires a CLIENT jwt. The identity is the same kind and hash pair the reader uses, and the server recomputes the sha256 of the body and refuses anything that differs, so an upload can only ever publish the object it names.

The framing is strict: exactly one Content-Type matching the kind (application/json for metadata, application/x-ndjson for records and proofs), a positive Content-Length within the object bound (32 MiB for records and proofs, 2 MiB for metadata), and no Content-Encoding, Content-Range, Range, transfer encoding or trailers -- a transformed or partial upload is forbidden. Size is charged against the account's byte budget BEFORE any storage work, and the active upload slots are bounded.

A validator may instead present a signed reserved-upload intent in X-Urnetwork-Validator-Upload, which admits the upload against the api's own reserved lifecycle. The reserved header never bypasses client authentication.

The answer is 204 with the content hash in ETag.

Publish a release-evidence envelope. There is no header credential: the authorization IS the envelope's own signature, which must verify and must be the operator's configured artifact key, and whose chain id, netuid, deployment id and genesis hash must all match this operator. The body is capped at 64 MiB. Every rejection is the same 400, so a caller cannot probe which check failed.

Publish one signed client-key observation and read back that client's key history. A key observation creates a durable signed public statement, so it is an explicit POST owned by an authenticated CLIENT session rather than a side effect of the public GET /key/{clientId} lookup, and the request cannot supply a key to sign.

The framing is strict: Content-Type: application/json, a positive Content-Length of at most 16 KiB, no content encoding, transfer encoding or trailers. The body must be exactly the canonical encoding of the request -- unknown fields, trailing JSON and any non-canonical re-encoding are refused -- and the full maximum response size is charged against the account's byte budget before any operator signature or public write, so a failed call still pays its admission.

The plural form of /sn/client-key/observation, with the same authenticated, bounded and charged publication contract: one HTTP body never becomes one logical quota item, so the maximum response size is charged once PER request in the batch before any work is done. The body is capped at 1 MiB and the responses come back in request order, each an encoded client-key history response.

A batch whose chain work cannot be admitted is refused with 413 and an X-Ur-Client-Key-Batch-Admission: work header.

Issue the caller's welcome offer: 25% off the first year of Pro (3 months free), valid validity_days (5) from issue, stacked on the 14-day trial, redeemable on every store. Issued ONCE per network: the call is idempotent and returns the existing offer in whatever state it is in (created: false); an expired offer is never re-issued. Call it the moment the offer surface renders (the intro plan step), so the deadline is real.

Refused with error when the onboarding config is absent, or when the caller is in the holdout variant of the in-app offer experiment (experiments["offer.in_app"]): those networks show the regular plan picker and reach the offer by email instead.

Budgeted per caller address (30 per 10 minutes): over budget the response is 429 with a Retry-After header.

Store a batch of product events (at most 200 per call) against the CLOSED event schema (see ClientEvent). The network id comes from the bearer token only; tier, path, experiment and variant are stamped by the server. platform is required and must be one of the known platforms: an event without one is rejected. Unknown event names, unknown prop keys, missing required props and ill-typed values are refused PER EVENT in rejected (the rest of the batch is stored); a rejection is final, the client must not resend that event. No free text is stored except feedback.submitted.text, which is redacted (emails, phone numbers, IP addresses) before storage.

Clients batch every 30 s or on background, drop an event after three failed calls, and never send more than 200 per call (a larger batch is a 400). Budgeted per caller address (120 calls per 10 minutes): over budget the response is 429 with a Retry-After header.

Record a campaign landing-page click. Every onboarding email link is https://ur.io/o/?t=; the landing page posts the token here, which writes the server-side landing.clicked attribution event and answers with the in-app destination to route to (onboarding/connect, onboarding/widgets, onboarding/offer, onboarding/feedback). An app open (/network/auth-client) within 48 h of the click is attributed to it as app.opened.

No authentication: the signed token is the credential, and the response carries nothing about the network. An expired token still returns step and destination (with ok: false, error: expired) so the page can route without attributing; an invalid token returns ok: false, error: invalid. Budgeted per caller address (60 per 10 minutes) -> 429 with Retry-After.

The Brevo transactional-email webhook. Brevo is registered (idempotently, by the server when onboarding.enabled is on) to post one event per delivery step.

Authentication is HTTP BASIC, not bearer and not a network token: the request must carry Authorization: Basic base64(:) where is one of the account's webhook_bearers (vault brevo.yml) and the password half is empty.

unsubscribe turns the account's product-updates preference off (the existing behavior). For the onboarding campaign the remaining events are recorded as server-written email.delivered|opened|clicked|bounced|complained|unsubscribed events against the network, with the campaign step taken from the stored send that message-id names. An event whose message id is not a known campaign send records nothing.

The event name is matched lower-cased against this exact set: delivered; opened, unique_opened, proxy_open; click, clicked; hard_bounce, blocked, invalid_email, error; spam, complaint; unsubscribed, unsubscribe. Anything else records no campaign event. A hard bounce or a complaint exits the network from the sequence.

The rfc 6749 token endpoint, as a form post. Two grants are supported: authorization_code (with the PKCE code_verifier, and optionally the rfc 8707 resource indicator) and refresh_token. Clients are public -- the token endpoint auth method is none -- so client_id is always required and there is no client secret.

Errors are the rfc 6749 section 5.2 envelope. The descriptions are deliberately terse and the detail is logged rather than returned, so an error cannot be used to probe which check failed. The response is never cached by a shared cache.

Dynamic client registration (rfc 7591). Deprecated by the MCP specification in favor of client id metadata documents, and kept for clients that predate it. The endpoint is openly writable, so it is metered per caller address before the body is parsed or anything is stored; over budget it answers 429 with Retry-After. Registered clients are public, so no secret is issued.

Token revocation (rfc 7009), as a form post. Always answers 200 with an empty body: per the rfc a client must not be able to tell an unknown token from a revoked one.

What the consent page on the ur.io origin needs to render: who is asking, for what scopes, and whether consent is actually required. The caller is the consent page passing through the signed-in user's URnetwork JWT.

The authorization request is validated here, BEFORE anything is rendered, so a hostile request never reaches a screen that could be used to phish approval; an invalid request is reported to the user rather than redirected, because a redirect uri is only trustworthy once it has matched the client's registered set. prompt=consent forces the screen even when the scopes are already approved. issuer is returned so the page can echo iss when the user declines, as rfc 9207 requires on error responses too.

Mint the authorization code for a request the user approved, and return the redirect the consent page should follow. The caller is the ur.io consent page passing through the signed-in user's URnetwork JWT. Consent is recorded HERE rather than when the screen is shown, so an abandoned screen grants nothing. The redirect carries code, the request's state when it had one, and iss per rfc 9207 so the client can detect a mix-up attack.