Question 1

What is Surplus Intelligence?

Accepted Answer

Surplus is an open marketplace for AI inference. Buyers call one OpenAI-compatible base URL and each request is sent to eligible seller capacity. Sellers connect supported provider endpoints, set prices and limits, and earn USDC when their offers serve completed requests.

Question 2

Who is Surplus for?

Accepted Answer

- Buyers and developers who want lower-cost model access through one OpenAI-compatible API. - Sellers and providers who have unused, prepaid, discounted, or otherwise monetizable API capacity. - Agents and applications that need programmatic payments through API keys, x402, or MPP-compatible flows.

Question 3

Why can prices be much lower than direct-provider prices?

Accepted Answer

Sellers set their own prices in an open order book. Some are monetizing capacity that would otherwise expire or go unused; others have discounted provider access. Prices and available capacity can change as seller balances, caps, health, and upstream-provider conditions change.

Question 4

Is Surplus the same as OpenRouter or a model provider?

Accepted Answer

Surplus is a marketplace and router, not the creator of most models it lists. It can route among independent seller endpoints and supports provider filtering, seller health/backoff, buyer-owned priority keys, and multiple payment rails.

Question 5

Can I whitelabel Surplus or build my own router on top of it?

Accepted Answer

Not under the standard Terms on their own, and not as a self-serve entitlement. [Terms of Service §8](/terms-of-service) prohibit reselling, redistributing, or wholesale repackaging the Service or provider API access, and prohibit using the Service to build a directly competing routing service. Listing your own capacity as a Seller under §6 is the one resale path the standard Terms allow by themselves. With a written arrangement in place, there are two technical shapes it takes, depending on who owns per-customer isolation and billing. - Surplus provisions a key per customer. In an organization, an admin key (infadmin...) mints, scopes, rotates, and revokes one buyer key per downstream customer through /v1/keys, and Surplus enforces isolation, budgets, and usage per key. - Your gateway in front. Your gateway owns per-customer isolation and billing, and you call Surplus with a small pool of high-capacity keys under one dedicated organization, reconciling cost back to your own accounts. Talk to us before you build: email support@surplusintelligence.ai or use the Enterprise contact form. Full technical walkthrough, including the provisioning API and reconciliation surfaces: [Whitelabel & Reseller Setups](/docs/getting-started/whitelabel).

Question 6

Do you have a reseller, partner, or enterprise plan?

Accepted Answer

There is no self-serve reseller tier, and reselling is not permitted by the standard Terms ([§8](/terms-of-service)) without a written arrangement, so the first step is always to talk to us rather than to sign up for something. There is also no separate technical tier to buy. Capacity is architectural (horizontally scaled fleets) and a reseller runs against the same guardrails as everyone else: the per-key and per-IP rate limits, and your prepaid balance. There is no per-account throttle to raise. What an agreed high-volume reseller gets is a dedicated organization, so usage, billing, and keys stay cleanly separated, plus a direct line to plan capacity and the per-IP allowance for sustained volume. To start that conversation, use the Enterprise contact form on the site or email support@surplusintelligence.ai with your expected volume and the models you plan to route.

Question 7

How do I start buying inference?

Accepted Answer

1. Sign in at https://surplusintelligence.ai. 2. Create or copy an inf buyer API key. 3. Fund your account: top up credits with a card, or deposit USDC on Base. 4. Point an OpenAI-compatible client at the Surplus gateway (https://api.surplusintelligence.ai/v1). Example: Never post an API key or private key in Discord.

Question 8

Why can I only see a short prefix of my API key?

Accepted Answer

The full API-key secret is shown when the key is created; later screens may show only a prefix. If you did not save the full key, revoke it, create a new one, and store it in a password manager or secret manager. Surplus support should never ask you to paste the key into Discord.

Question 9

What payment methods are supported?

Accepted Answer

There are two ways to fund your account: card-funded credits (card top-ups through Stripe) and deposited USDC on Base (bought through MoonPay via Privy or Peer/ZKP2P, or sent from a wallet you already hold). Card credit is spendable but never withdrawable; deposited USDC is spendable and withdrawable. A request can also be paid on its own over x402 or MPP, with no account balance. Seller payouts use USDC on Base.

Question 10

Which network and token should I use?

Accepted Answer

Use native USDC on Base (chain ID 8453). Sending USDC over BNB Chain, Ethereum, or another network does not fund the Base balance. If you used the wrong network, recover the funds from the same wallet/account and bridge or resend them as Base USDC.

Question 11

My card top-up window closes, flashes, or declines. What should I do?

Accepted Answer

- Allow pop-ups and temporarily disable checkout-blocking extensions. - Complete any bank OTP or identity-verification prompt. - Confirm that your bank supports the card and Stripe transaction. - Try another live funding method, such as MoonPay, Peer, or Base USDC. - If the payment succeeded but the balance did not update, open a ticket with the checkout time, amount, and payment reference. Never send full card details.

Question 12

How many API keys can I create?

Accepted Answer

These are counts of active keys, not request-rate limits. - 25 active keys per wallet, per type on the self-serve surface (buyer and seller keys are counted separately). Revoke one to free a slot. - 200 active keys per workspace on the /v1/keys provisioning surface used for whitelabelling.

Question 13

How do I reconcile Surplus cost against what I bill my customers?

Accepted Answer

Every request exposes its cost so you can attribute it downstream: - On a NON-streamed response, the x-si-buyer-cost-micro header carries the buyer cost of that request in integer micro-USD (1 USD = 1,000,000), and the same figure sits on usage.buyercostmicro in the body. It is omitted rather than sent as 0 when the charge is not known at response time. - On a STREAMED response the header cannot exist, because HTTP headers freeze at the first byte. The figure rides usage.buyercostmicro on the terminal usage event instead, which needs streamoptions: {"includeusage": true} and an upstream that emits usage. Both inline paths are best-effort, so never read a missing value as a zero cost. - GET /v1/requests returns the per-request log (model, tokens, cost, status) and needs the requestlog.read capability; GET /v1/requests/{id} is also readable by the inf key that made that request, so a key can pull its own settlement and cost rows. - GET /v1/buyer/me and GET /v1/buyer/usage/export give usage stats and a CSV export. The export is capped at 50,000 rows (or a lower limit you pass) and sets x-si-export-truncated: true when rows remain, so check that header and narrow the window rather than assuming the file is complete. Use the inline figure for real-time margin where it is present, and reconcile against the request log on a schedule. GET /v1/requests/{id} is the authoritative per-request record when a cost never appeared inline.

Question 14

How does routing work?

Accepted Answer

Surplus evaluates eligible seller offers in a set order. The normal routing order is: 1. Your model-specific priority provider, if configured. 2. Active marketplace offers that pass trust, provider, health, cap, and price filters. 3. The cheapest estimated eligible offer first. 4. Your catch-all fallback provider (model: null), if configured. 5. The universal fallback, where available. If an offer fails, it enters backoff and Surplus tries the next eligible offer when the error is failover-safe.

Question 15

Does "cheapest" mean the lowest displayed input price?

Accepted Answer

Not always. The router estimates total request cost from input size, expected output, and metered components such as cache reads/writes. It also excludes offers that are unhealthy, capped, outside a price threshold, outside the requested provider set, or disallowed by the trust setting.

Question 16

Can I choose a provider?

Accepted Answer

Yes. Advanced requests can pass provider, providerurl, or providerbaseurl. provider may be one provider or an allow-list. This narrows the eligible order book to matching provider hosts. Provider pinning does not select one exact seller offer; Surplus still chooses the cheapest healthy eligible offer within the pinned provider set.

Question 17

Can I choose one exact seller?

Accepted Answer

The standard buyer API does not expose exact-offer selection. You can narrow routing by provider and trust level, set a minimum discount, or configure your own priority provider.

Question 18

How do I stop routing below a minimum discount?

Accepted Answer

Three ways, and the strictest one wins: set a minimum discount on the API key itself, send the X-Min-Discount header, or call the /min{N}/... route. A per-request value can only tighten the key’s floor, never loosen it. Requests fail rather than route to an offer below the threshold. Price ceilings (maxpriceper1m) are retired — a per-1M input rate ignored output and cache rates, and said nothing about whether you were getting a good price. The filter applies to marketplace offers, not buyer-owned priority/fallback providers, and it is not applied to embeddings, which carry no reference price to discount against.

Question 19

What do "Account default", "Trusted providers only", and "All providers" mean?

Accepted Answer

Trusted-only routing is the default for new accounts. "Account default" inherits the account-level routing preference. "All providers" opts the key into untrusted providers as well as trusted ones. Trusted status lowers risk but is not proof that a provider served an exact model.

Question 20

Does Surplus verify that a seller served the exact model advertised?

Accepted Answer

Not cryptographically or semantically today. Surplus verifies reachability, authentication, response validity, and operational health, and it classifies known provider domains as trusted. Buyers needing stronger assurance should keep trusted-only routing or use their own BYOK priority provider.

Question 21

Where can I see which provider served my request?

Accepted Answer

The current request-log API is GET /v1/requests. Rows include the serving provider’s stable public ID, route source, whether fallback was used, status, token counts, cost, and latency. It is cursor-paginated and supports server-side model, provider, key, status, and text filters. The Analytics/Request Log UI is the corresponding dashboard surface.

Question 22

Is my prompt private?

Accepted Answer

For normal synchronous chat/completions, Surplus stores usage and settlement metadata rather than full prompt and response bodies by default. The selected upstream provider still receives the request and may apply its own logging or retention policy. Async media jobs retain request and provider-job metadata for orchestration. There is no cryptographic ZDR guarantee across all marketplace sellers.

Question 23

Does using Surplus violate OpenAI, Anthropic, or other provider terms?

Accepted Answer

Surplus is a routing layer and does not host or operate any model itself; each request is fulfilled by a third-party model provider through a seller endpoint. Because of that, the underlying provider's terms still apply to your use, and you are responsible for reviewing and complying with them for each model you use. This is set out in [Terms of Service §5.2](/terms-of-service). Sellers who list an endpoint must be authorized to provide and resell access to the credentials they submit, and must comply with the provider's terms, including any prohibition on reselling or third-party access. See the [Acceptable Use Policy](/acceptable-use-policy) and [Terms §6](/terms-of-service). This is a summary, not legal advice; the linked policies are authoritative.

Question 24

Where can I see supported models and current prices?

Accepted Answer

Use the live endpoints: Model availability and seller health can change, so do not rely on a static model count.

Question 25

Which API base URL should I use?

Accepted Answer

Point your OpenAI-compatible client at the Surplus gateway: The most common text endpoint is POST /v1/chat/completions. Surplus also supports other model-appropriate surfaces, including Responses, Anthropic Messages compatibility, images, video, music, speech, transcription, and embeddings. Use the endpoint and parameters documented for that model and modality.

Question 26

Why does a model work in one client but fail in another?

Accepted Answer

Clients differ in the API wire and parameters they send. Common causes include: - using Chat Completions when the model/client expects Responses; - unsupported streamoptions, responseformat, tool, or reasoning fields; - provider-specific JSON/schema restrictions; - a context window exceeded by accumulated chat history; - an unavailable provider after trust/provider filtering. Start with a minimal request, confirm the endpoint, then add optional parameters one at a time.

Question 27

Why did a long conversation stop responding?

Accepted Answer

The full conversation sent by your client counts toward the model context window. Check the model metadata from /v1/models, start a new conversation, or enable your client's history compression. A model's advertised maximum may also differ by provider or API surface.

Question 28

Why am I billed for reasoning tokens when I cannot see reasoning text?

Accepted Answer

Some models use hidden internal reasoning tokens but do not expose the reasoning trace. Usage can therefore report reasoning tokens even when the response contains only the final answer. A reasoning-effort flag controls effort where supported; it does not guarantee that reasoning text will be returned.

Question 29

How is prompt caching priced?

Accepted Answer

Cache reads and writes can be separately metered. Cost-multiplier offers apply the multiplier to the model's applicable reference components; explicit per-token offers may carry separate cache rates. Check /v1/prices and the request detail rather than inferring cache cost only from input/output prices.

Question 30

Where can I see the exact cost after a request runs?

Accepted Answer

Use the Analytics Request Log or GET /v1/requests. The current row schema includes buyercostmicro, sellercostmicro, directcostmicro, provider, token counts, and latency. Open the request detail for settlement status, transaction hash, settlement basis, and cache-savings fields. List prices are estimates; the request detail is the per-request record.

Question 31

Why do I see unsupported_provider, no_sellers_for_model, or 503?

Accepted Answer

- 400 unsupportedprovider: every provider pin was unrecognized. - 404 nosellersformodel: the provider/model is supported, but no matching active healthy offer is available. - 404 nocompatiblesellers: the request replays reasoning only another provider can continue, and your provider pin or providersblocked excludes every seller that can; the message names the providers that can serve it. - 503 or overload/timeout: eligible sellers failed or were unavailable. - 401: the Surplus key or an upstream seller key was rejected. - 402: buyer funds or upstream seller quota may be insufficient. - 429: a Surplus or upstream-provider rate limit was reached. Remove an unnecessary provider pin, check trust settings and funding, inspect the request log, and retry with backoff.

Question 32

What are the rate limits?

Accepted Answer

Current per-minute guardrails are 1,200 completion calls, 600 buyer-control-plane calls, 1,200 seller calls, 1,200 general reads, 300 analytics calls, and 180 public market calls. Every response carries an X-RateLimit-Limit header, so /v1/models and POST /v1/chat/completions report 1200 and /api/markets reports 180. A separate edge ceiling also blocks any single source IP past 6,000 requests per 5-minute window (about 1,200/min), before the application sees the request. It counts every request from an address regardless of how many keys they carry, so pooling keys behind one NAT address does not lift this ceiling. Contact support before planning higher volume from one source IP.

Question 33

How do I start selling?

Accepted Answer

1. Sign in and open the Sell page, or authenticate programmatically through seller SIWE. 2. Use a dedicated, provider-capped API key. 3. Discover or select a supported model. 4. Set a price or cost multiplier, daily cap, and payout address. 5. Confirm the offer is active and healthy in the seller dashboard and public market. Seller endpoints should be OpenAI-compatible for the relevant model surface, so the router can forward buyer traffic to them.

Question 34

How do sellers get paid?

Accepted Answer

Seller amounts are paid in USDC on Base to the seller wallet or the offer's payout address. Direct on-chain sales can confirm per request. Credit-funded sales can first appear as accrued and then move through payout processing.

Question 35

I see sales, but my payout balance is not going up. Why?

Accepted Answer

Usually this is the difference between earning and being paid, which under batched payouts is expected rather than a fault. - Your earnings accrue per request the moment each response completes, but payouts are batched and grouped by payout recipient, so you are paid when a group becomes eligible, not once per request. - A group becomes eligible for an automatic payout when either its available balance reaches $5 (the current floor, reported live as thresholdusdc) or its oldest available earning reaches 72 hours. - Because payouts are group-level, an individual request row in your CSV can stay settlementstatus = accrued even after its earnings were paid in a batch. A large accrued count does not by itself mean you are unpaid. - The authoritative record of payment is your payout history and its Base transaction hash, not the per-request status. Check GET /v1/seller/payouts (history[], where status: "paid" carries the txhash). If a payout instead looks stuck, that is not the normal cycle: an eligible balance that is not moving, a history entry stuck at claimed or submitting far longer than a cycle, a group whose nexttrigger is riskhold or unresolvedrecipient, or a history entry at needsoperator (terminal for automation, so it will not self-resolve). See the [settlement and payout lifecycle](/docs/api-reference/seller-endpointssettlement-and-payout-lifecycle) and contact support with your wallet address and the payoutid.

Question 36

How do batched payouts work?

Accepted Answer

To save on-chain fees, your sales accrue into a balance and Surplus pays it out in USDC on Base as one transfer per payout, rather than one transfer per sale. A payout runs automatically when the balance reaches a minimum (currently $5) or the oldest unpaid earning is 72 hours old, whichever comes first, on a roughly 10-minute cadence, with Surplus covering the gas. The balance is tracked per payout recipient, not per seller. The recipient is fixed when each sale is earned (the offer's payoutaddress, otherwise your default wallet), so if some offers override it you have more than one group, each reaching its own trigger and paid by its own transaction. Merging them would pay one recipient money owed to another. If every offer pays to the same wallet you have one group, and so one transfer. Track every group and its next trigger with GET /v1/seller/payouts.

Question 37

When does my balance get paid out?

Accepted Answer

You are paid on the next scheduled run once your balance reaches the minimum (currently $5) or your oldest unpaid earning turns 72 hours old, whichever comes first. A smaller balance rolls forward and keeps accruing until one of those triggers. A payout can also wait a run if your account is under a risk review. Check your balance and the next trigger with GET /v1/seller/payouts, or trigger one yourself with Payout now.

Question 38

Can I trigger a payout myself?

Accepted Answer

Yes. Payout now (POST /v1/seller/payouts/withdraw) claims your available balance immediately, with no minimum and no 72-hour wait. It goes to the same recipient a scheduled payout would use. By default we broadcast it and pay the Base gas, exactly like a scheduled run, and the response comes back scheduled. Send selfsubmit: true instead and you get a signed authorization to submit yourself, paying your own gas; the balance then stays held until that transfer confirms or the authorization expires, because a signature we have handed out cannot be recalled. On that path we sign for one payout group at a time unless you also pass a destination, which consolidates every group into a single transfer to that address. A payout hold still applies either way: the response comes back held with a reason rather than moving the money.

Question 39

What do accrued, pending, submitted, and confirmed mean?

Accepted Answer

These are the per-request settlementstatus values in your usage CSV. They describe the REQUEST, not whether you have been paid. - accrued: a credit-rail sale, recorded in the payout ledger and payable. Under batched payouts most rows stay here even after the earnings were paid in a batch, so an accrued count is not a measure of what you are owed. - pending: an on-chain or x402 sale whose settlement transaction has not confirmed yet. - submitted: an x402 sale broadcast on chain whose receipt could not be read in time. It may still have landed. - confirmed: the row carries an on-chain hash. On the direct on-chain rail that is the settlement itself; on the credit rail it is a best-effort display writeback that does not cover every paid row. - failed: settlement did not complete for that row; retries or manual reconciliation may be required. To check whether money actually moved, read your payout history instead: GET /v1/seller/payouts, where a history entry with status: "paid" carries the Base txhash. See the [settlement and payout lifecycle](/docs/api-reference/seller-endpointssettlement-and-payout-lifecycle).

Question 40

Why is my provider dashboard usage higher than my Surplus payout?

Accepted Answer

Provider-native usage is not the same metric as settled marketplace sales. An upstream provider may charge for a request that timed out or kept running after Surplus closed the connection, even though the buyer never received it and no successful sale settled. Also, DIEM/credits consumed are provider-native units, while Surplus pays the offer's USDC price based on metered delivered usage. Compare the same UTC window, model, key, and request set. Include the Surplus request IDs and provider usage timestamps in a support ticket.

Question 41

Why did buyers reach my offer when cheaper offers existed?

Accepted Answer

Cheaper offers may have been unhealthy, rate-limited, out of provider credits, capped, excluded by a buyer's trust/provider filter, or more expensive for that request's input/output mix. The router tries the cheapest eligible offer, not simply the lowest visible headline price.

Question 42

Why is my offer unhealthy?

Accepted Answer

Common causes include an invalid/revoked provider key, exhausted quota or DIEM, provider 401/402/403, rate limits, timeouts, malformed responses, an unsupported model mapping, or an upstream outage. Check GET /v1/seller/health-log, fix the provider-side issue, and allow the backoff/recovery flow to run.

Question 43

Can I cap how much of my provider balance is sold?

Accepted Answer

Inference offers support a marketplace-side daily USD cap. Provider-side model restrictions, spend caps, and rate limits remain the strongest protection. There is not a marketplace-side DIEM-unit cap or separate hourly USD cap in the current published design.

Question 44

Does Surplus consume seller credits for health checks?

Accepted Answer

Yes, in bounded cases. Creating or testing an offer performs a real probe for the selected model. Healthy offers are not continuously pinged, but an offer marked unhealthy enters a recovery queue, and the prober sweeps every three minutes to send due unhealthy offers a small real check. Text probes cap output at 16 tokens; the recovery prober uses a 45-second timeout, while create and test probes use a 20-second default. These calls can consume a small amount of upstream quota, so use a dedicated provider key with provider-side limits.

Question 45

How do I change my payout wallet?

Accepted Answer

Set the payout address on the offer and verify each active offer points to the intended Base wallet. Different Privy sign-in methods can create or select different embedded wallets, and older offers may retain the payout address set when they were created. After a change, use a small test sale and confirm the Base transaction before restoring full traffic.

Question 46

Why do I see multiple wallets or a different account after signing in?

Accepted Answer

Privy identities can differ when you sign in by wallet, email, Google, Farcaster, or another method. Use the same login method that created the seller/API key and offers. If the correct account is not visible, open a ticket with the login method, public wallet addresses, and offer IDs. Never send private keys.

Question 47

How do I access an embedded wallet Privy created for me?

Accepted Answer

If you sign in with email, Google, or X without connecting an external wallet, Privy creates an embedded wallet and Surplus uses it as your active wallet, so funding and payouts go to it. Its address, with a copy button, is in the account menu (the profile icon, top right), and it is the same address shown as your funding target on the Buy page. Two limits to know: - Once you connect an external wallet, Surplus prefers it and hides the embedded wallet from the account menu, so a balance can be stranded in one you can no longer select. - There is no in-app key export or send button for an embedded wallet on-chain balance; the withdraw controls only move your Surplus credit, treasury, and payout balances. To recover funds stranded in an embedded wallet, open a ticket with your login method and the public wallet address, and never share a private key. To avoid it, connect and switch to your intended wallet before funding or before setting a seller payout address.

Question 48

Are seller provider keys secure, and are they deleted when I remove an offer?

Accepted Answer

Provider keys are encrypted using AES-256-GCM with AWS KMS envelope encryption; encrypted payloads are stored privately. Offer deletion is currently a soft delete, so encrypted key material is not automatically hard-purged. Revoke the key at the upstream provider when retiring an offer, and contact support if you need manual erasure.

Question 49

Which payout assets are supported?

Accepted Answer

The marketplace pays sellers in USDC on Base. USDT on TRON or other chains is not a seller-payout option.

Question 50

Are payouts and platform fees always zero-fee?

Accepted Answer

Today, yes — platform fees are zero and seller payouts settle at a 1.0x on-chain multiplier with no flat platform fee. If a platform fee is ever enabled, it is folded into the per-1M prices shown on a model's offer list rather than added on top of them: the effective price shown on a text offer there is what you pay, and the discount shown is measured against it. Your exact per-request cost is always available on GET /v1/requests/{id}, which is the authoritative figure for any offer or surface.

Question 51

How do I get more than the recent seller-sales window?

Accepted Answer

GET /v1/seller/earnings exposes precomputed earnings and a recent-sales window. GET /v1/payments/seller/earnings exposes live ledger state and up to 50 recent ledger activities. For the full history, GET /v1/seller/usage/export returns a CSV of every sale row (up to 50,000) as a short-lived download link. Beyond that cap, or for a cursor-paginated feed, contact support with the seller wallet and UTC range.

Question 52

Can Surplus add my provider or model?

Accepted Answer

Usually, if the provider has a stable OpenAI-compatible API, documented model IDs, measurable usage, acceptable terms, and a testable pricing model. Share public API documentation and model/pricing information through a ticket. Send test credentials only through an approved secure channel, never a public Discord message.

Question 53

What does Surplus test before adding a provider?

Accepted Answer

Typical checks include /models, a minimal completion on each supported API wire, authentication and error semantics, usage fields, model identity, latency, pricing, and whether marketplace resale is allowed. Media models require modality-specific quote/job/poll validation.

Question 54

Why is a provider or model missing even though the upstream provider offers it?

Accepted Answer

A mapping may not exist yet, the provider may not expose a compatible endpoint, no seller may have listed it, every offer may be unhealthy, or terms/pricing/identity may still need validation. Check /v1/models and /api/markets/{model} first, then file a model/provider request.

Question 55

How do image, video, music, TTS, and transcription requests work?

Accepted Answer

Use the model's documented modality endpoint. Video and music are asynchronous: submit a job, poll its status, then download the artifact. Availability depends on healthy seller support for that exact model and modality; a text-compatible provider does not automatically support image/video calls.

Question 56

What does "per job" mean for media pricing?

Accepted Answer

It means the billable unit is a generation job rather than one million text tokens, but the effective price may still depend on model-specific parameters such as duration, resolution, quality, or output count. Use the live model metering metadata and /v1/prices for that exact media model.

Question 57

What can each organization role do?

Accepted Answer

Every member of an organization has one role that sets what they can do. From most to least access: - Owner: Full access to everything, including billing. - Admin: Manage members, workspaces, API keys, offers, and settings. Cannot manage billing or withdraw payouts. - Billing admin: Manage billing, wallets, and payouts (including withdrawals). Cannot manage API keys or members. - Developer: Spend, manage API keys, and manage offers. Cannot see the organization's bill or org-wide finance. - Analyst: Read-only access to usage, audit, finance, and request logs. Cannot spend or change anything. - Member: Spend from credit and view their own usage. - Viewer: View their own usage only. You can only assign roles at or below your own. Change a member's role anytime from the Members tab in Settings.

Question 58

Am I charged for a failed or timed-out request?

Accepted Answer

A request that never completes should not be represented as a successful settled buyer charge. Check GET /v1/requests and the request-detail settlement status. If the request failed but a buyer charge finalized, open a ticket with the request ID and transaction reference. An upstream seller provider may still charge the seller for work that continued after a timeout; that is a separate provider-vs-marketplace reconciliation issue.

Question 59

Can I get a refund?

Accepted Answer

- For a failed request that appears to have charged successfully, open a ticket for request-level review. - Refunds of unused card-funded credits are handled by support and can depend on payment status, payment-processor rules, and applicable law. - Do not post full payment-card or identity details in Discord.

Question 60

What information should I include in a support ticket?

Accepted Answer

Include: - buyer or seller role; - UTC date/time and timezone; - request ID(s), offer ID(s), and model; - endpoint/API wire and whether streaming was enabled; - HTTP status and sanitized error text; - public wallet/account address and transaction link, if relevant; - provider usage timestamp and amount for seller reconciliation; - expected result versus actual result. Do not include API keys, private keys, card numbers, auth headers, cookies, or signed payment payloads.

Question 61

How do I know a DM, token, airdrop, or payment request is official?

Accepted Answer

Treat unsolicited DMs, surprise tokens, and requests for keys or wallet secrets as scams unless confirmed through the server's official links and staff. Surplus support does not need your private key or seed phrase. If unsure, post a screenshot with sensitive data removed and ask in a ticket.

Questions, answered.

About Surplus

Buyer setup and funding

Routing, providers and trust

Models and API compatibility

Sellers and offers

Provider onboarding

Organizations and roles

Failures, refunds and support

Still stuck?