Choose who will keep the account and secret
Decide who will retain the account password and where the server will read the archive key before submitting the form. The product’s users need access to your feature, not this credential. Preparing its destination now avoids treating the one-time display as something another operator can retrieve from an email later. The account, key and balance apply only to redditapigateway.com. Any allocation of 100 trial credits depends on network-wide anti-abuse eligibility; do not treat it as guaranteed funding.
Register with email and a password of 12–72 UTF-8 bytes. Some characters use several bytes, so byte length is not character count. Google login is not available. No wallet connection or wallet address is required for signup. The archive key appears once immediately after successful signup, before any payment. Save it securely at that moment; it is not emailed later and cannot simply be redisplayed after login.
Hand the credential to the server, not the product user
Place the saved key in protected backend configuration and identify the process that will use it for the SaaS onboarding check. Keep it out of screenshots, copied diagnostics and client bundles. Account ownership and permission to use your product remain separate: granting a teammate access to results need not grant access to the retrieval secret.
Choose one supported header for the HTTP client that performs the onboarding job: X-API-Key: <key> or Authorization: Bearer <key>. Both carry this archive account’s key, not a Reddit OAuth token. Add the value from protected backend configuration only after your application has accepted the product user’s job. Keep it out of browser storage, frontend bundles and public logs. Signing into the account page uses a separate Secure HttpOnly session cookie; that session neither supplies the retrieval header to your backend nor decides which product user may spend credits. Check those two boundaries separately when testing the first SaaS sample.
Fund the first retrieval only when ready
Before funding the onboarding feature, distinguish the account balance from the allowance your backend gives one product job. Buying the minimum $50 adds 50000 paid credits at $1 per 1000 successful retrievals; those credits do not expire and there is no subscription. Sign in and create the server invoice before sending funds. Choose USDT on TRON TRC20 or USDC on Ethereum mainnet ERC20, then use that invoice’s current recipient and exact amount. After the transfer, submit its transaction hash for verification: credit requires a genuine, confirmed transfer matching the invoice. Check the actual account balance before starting the next SaaS sample; creating a key or planning three attempts does not reserve credits for that job.
The invoice lasts one hour; settlement time is not guaranteed and provider outages can leave verification pending. Pending does not mean pay again. When credits are available, try the homepage onboarding search in SaaS and account for each successful page before expanding the product workflow. Each successful retrieval, including empty data, costs one credit. HTTP 401 concerns credentials, 402 the balance and 429 rate limits. Public /v1/status does not validate your key or search availability.
Replace a key as an operational change
If the credential is lost or exposed, sign in and confirm the password to regenerate it. The old key becomes invalid immediately. Pause new jobs in your own application, update affected server processes, then resume a bounded check; do not assume both keys will work during a rollout. There is no emailed key or password-reset feature. Changing the key does not reverse previous retrieval charges.
